[HN Gopher] Deep dive in CORS: History, how it works, and best p...
___________________________________________________________________
Deep dive in CORS: History, how it works, and best practices
Author : todsacerdoti
Score : 80 points
Date : 2021-04-13 20:05 UTC (2 hours ago)
(HTM) web link (ieftimov.com)
(TXT) w3m dump (ieftimov.com)
| hansvm wrote:
| Overall this was great. One bit stood out as odd though:
|
| > In such cases, our API is public, but we don't want any website
| to send data to our analytics API. In fact, we are interested
| only in requests that originate from browsers that have our
| website rendered - that is all.
|
| CORS doesn't seem like the right tool for this. Anyone can spam
| your analytics endpoints without a browser; do you gain anything
| meaningful by restricting the browser as well?
| mattacular wrote:
| It's the right tool for preventing WEBSITES from using your
| endpoints - they might be able to take your JS, reverse
| engineer and run it, but you can mitigate how useful this is by
| preventing calls to CORS-protected resources. This does not
| protect your endpoints from attackers in general though, so to
| your point, it depends what they're trying to accomplish.
| airza wrote:
| One surprising thing to keep an eye out for is that many web
| servers do not use the content-type headers when receiving json
| data; they simply parse the text as json regardless of its stated
| type and go from there. This means that requests encoded and
| mime-typed as form data that _also_ parse as json can be sent to
| servers without triggering a pre-flight request. This can result
| in CSRF where it 's not expected.
| dexwiz wrote:
| I think the issue most developers have with CORS is how late in
| the dev cycle you encounter it. When everything in localhost/http
| you don't see any issues. It only crops up once you deploy to
| staging/production environments that are actually on the web.
| Worst case is when it works fine in staging, and only has issues
| in production and someone else controls the allow list.
|
| It usually bites you once, and then you look out for it. But
| about every web developer I know hits it at some point. There
| used to be footguns of being able to disable CORS, and devs would
| provide this as a work around. Thankfully browsers have pretty
| much disabled these settings without intensive investment.
| ncpa-cpl wrote:
| Or when an IT audit shows it as a missing best practice.
| helloguillecl wrote:
| You just reminded me that the project I am about to deploy and
| ship with a simple `kubectl -f apply` will not ship as fast as
| I expected. It will feel familiar, and I will not know why :)
|
| Or worst, because I'm somewhat not such a careful programmer
| sometimes, sometimes the API call will still point to
| localhost:3000, and I will only notice next day when I want to
| show my shiny new creation to my significant other from my
| mobile.
|
| After running back to my laptop so I can fix it, my SO will
| wonder why am I taking so long and whether am I any good at my
| "job". I will wonder why the code hasn't updated since the
| requests are still failing, but the fix was so "simple".
|
| AHA moments later, I'll rush to just copy and paste the first
| line I find on stackoverflow.
|
| I'll ask myself: Why I still haven't properly learn CORS!? :D
| dcow wrote:
| I'm relatively new to the world of browser CORS concerns. But let
| me get this straight:
|
| > Such a configuration has to be carefully considered. Yet,
| putting relaxed CORS headers is almost always safe. One rule of
| thumb is: if you open the URL in an incognito tab, and you are
| happy with the information you are exposing, then you can set a
| permissive (*) CORS policy on said URL.
|
| > A dangerous prospect of such configuration is when it comes to
| content served on private networks (i.e. behind firewall or VPN).
| When you are connected via a VPN, you have access to the files on
| the company's network
|
| So the entire CORS dance exists because people thought VPNs were
| a good solution to protecting resources on the internet? That's
| mildly infuriating...
| lostcolony wrote:
| No. That's one potential risk, but hardly the only one.
|
| The entire CORS dance is to work around the pre-existing
| browser based security model. It was specifically to create a
| backwards compatible model that would enable requests across
| origins, without compromising the existing security model.
|
| This is a little overly simplified, but, consider how 'helpful'
| the browser is; when you make a request to a backend, any
| related cookie gets sent along with it. So, a danger realized
| early on was (by example), if someone was logged into their
| bank, and then accessed a malicious site, the malicious site
| could make a request to the bank to, say, transfer money.
| Because the bank used cookies for authentication, the transfer
| would be authorized and go through.
|
| VPN is a similar risk, but even authenticated resources might
| be available, depending on the type of authentication (and,
| certainly, unauthenticated ones are exposed).
|
| To prevent that, early on, they decided to block cross origin
| requests entirely. Well, almost; due to the nature of the web,
| GET requests had to be able to be made cross origin (it's why
| you can link to other websites/content), so they just prevented
| scripts from having access to the data. This was fine from a
| security standpoint, but it had a major usability issue. A lot
| of terrible workarounds were implemented (I'm looking at you,
| JSONP), with CORS being the official "this is how we'll allow
| you to, intentionally, relax this requirement, while still
| keeping the security decisions in place, and allow everything
| to be backwards compatible".
| dcow wrote:
| I thought origin policies could be applied at the cookie
| level such that the browser would only send the relevant
| cookies to your bank if the request originated from active
| user navigation to bank.com or from content served by the
| response received thereafter:
| https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Headers/Se...? That way instead of service X
| saying "only requests from these origins are allowed",
| bank.com is saying "these cookies are sensitive please
| restrict them to requests that happen when the user has
| actually navigated to our website". In the bank scenario you
| presented, does CORS provide any additional benefit beyond
| cookie-level access control policies? Is there another
| scenario I'm missing in general?
| astockwell wrote:
| Sadly, many MANY people in high places _still think_ VPNs are
| the best solution (and the only solution you need) to
| protecting resources.
| [deleted]
| math-dev wrote:
| This topic always trips me up, thanks for the guide
___________________________________________________________________
(page generated 2021-04-13 23:00 UTC)