CORS Is Stupid
kevincox.ca
kevincox.ca
* The author first describes a mildly convoluted cookie-stripping middleware under "Actually Solving The Problem" and includes the much simpler `SameSite=Lax` cookie under "Defense in Depth" later on.
* The author neglects to mention that `SameSite=Lax` is the default on all major browsers (still good to set it, though), which basically blows up the premise of the article, that all your cookies are one cross-origin form away from being mis-used
* The author recommends _loosening_ the default CORS protections, which I guess makes sense if you think "CORS Is Stupid", but definitely makes your server less secure for basically no reason.
The best way to deal with the Cross-Origin Resource Sharing restrictions is to simply set up your site so that it doesn't need to make cross-origin requests: serve your site from the same domain that it makes requests to, and make sure you set your cookies with `SameSite=Lax`, `Secure`, and `HttpOnly`. I outline this approach in more detail here: https://htmx.org/essays/web-security-basics-with-htmx/
Also, while I still think that existing browser controls basically solve this problem, it's true that POST forms have some sneaky vulnerabilities due to backwards compatibility concerns. One way to help fix that is by introducing PUT, PATCH, and DELETE to HTML forms—methods which don't have the same CORS exceptions: https://alexanderpetros.com/triptych/form-http-methods
This seems like the central premise of the article. Is the author just wrong about this? I'm confused. As I understand it, if the remote site sets Access-Control-Allow-Origin to a wildcard, and doesn't explicitly name the origin, then by default the browser will not send credentials with a request. Isn't that CORS working as intended? Was there some time in the past when browsers defaulted cookies to `SameSite=None`?
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...
If you can be sure that you application doesn't do any writes on "simple requests" then your job gets a lot easier and you can mostly rely on `Access-Control-Allow-Origin: *` omitting credentials. But if you have endpoints that accept form-posts or don't check the request's Content-Type header than you need to be extra careful.
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-coo...
This does actually make it pretty robust, although it does become an issue if you actually want to support cross-site form posts. But that is a pretty niche use case.
> includes the much simpler `SameSite=Lax` cookie under "Defense in Depth" later on.
The reason that I put the cookie-ignoring solution first is that it is robust and flexible. If you do want to support some cross-domain interaction with a logged in user you need something other than `SameSite=Lax`. The "ignore auth unless explicitly handled" provides a simple and effective baseline while being much more flexible. I also don't think ignoring cookies across you app is any more "mildly convoluted" that ensure that all cookies have a specific set of attributes. Both basically require a common layer to implement, but it seems more likely that someone adds a cookie somewhere without the approved helper than that they somehow accept a request that bypasses the middleware.
> `SameSite=Lax` is the default on all major browsers
It isn't. For some reason Firefox has had it prefed off since forever: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...
But it is well supported if you set it explicitly.
> loosening the default CORS protections ... but definitely makes your server less secure for basically no reason.
Can you elaborate? The "loosening" described is equivalent to what can be accomplished via a CORS proxy (other than possible network perspective concerns if they apply to your use case). So it isn't really loosening it. How does this make your server less secure?
This is explained here: https://kevincox.ca/2024/08/24/cors/#shouldnt-i-be-more-spec...
> One way to help fix that is by introducing PUT, PATCH, and DELETE to HTML forms—methods which don't have the same CORS exceptions
This would be nice, but it seems to mostly be a workaround, you can choose a different verb just to get CORS protection but now you can't use POST even if it is appropriate.
I'm not sure this is correct. I use Firefox, I have the setting off (by default), but even still I get the more secure SameSite=Lax secure by default even with the setting off, according to the sandbox they link to: https://samesite-sandbox.glitch.me/
For me the setting they mention makes no difference to the behaviour whether it is off or on.
EDIT: It seems like it's because of enhanced tracking protection that I get the more secure behaviour. With that off, I get the less secure behaviour.
> This does actually make it pretty robust, although it does become an issue if you actually want to support cross-site form posts. But that is a pretty niche use case.
In my opinion, the dominant security message for web applications should be: unless you are a specialist you should not be supporting cross-domain credentialed interactions. It's a simple rule that lets the browser do most of the security work for you.
The premise of your article that I most disagree with is "the automatically provided cross-origin protections are completely broken. Every single site that uses cookies needs to explicitly handle it." That's a scary line and it's simply not true for single-origin sites which is a) most sites and b) what should be encouraged.
> The reason that I put the cookie-ignoring solution first is that it is robust and flexible.
The robustness and flexibility of the solution are also add to the complexity of it (I did say "mildly"). Are the couple lines of python terribly complex? No. But middleware is a relatively big jump in complexity from just setting the `SameSite` property. If you said "in the situations where you need to support cross-origin requests, you'll have to do some extra work here" I'd have no problem with it.
> I also don't think ignoring cookies across you app is any more "mildly convoluted" that ensure that all cookies have a specific set of attributes.
Agree to disagree here, I guess, but setting cookie properties definitely easier (it's one line!) than filtering all your request cookies at runtime. The latter also involves a bunch of unnecessary computation.
> Can you elaborate? The "loosening" described is equivalent to what can be accomplished via a CORS proxy (other than possible network perspective concerns if they apply to your use case). So it isn't really loosening it. How does this make your server less secure?
Well, you're setting a header that says to allow a bunch of stuff that the browser would otherwise block (for instance, cross-origin PUT and DELETE methods). The point of CORS isn't that bad actors can't proxy it—you can always just send a curl—it's to make the median web client (i.e. your less tech-savy relative) more secure. In effect, you're disabling a chunk of CORS because it's annoying and replacing it with your own security mechanism. I don't think most people should do that, and there's better, easier advice we can give them.
> This would be nice, but it seems to mostly be a workaround, you can choose a different verb just to get CORS protection but now you can't use POST even if it is appropriate.
True, I'd also like to see them add a CREATE method with the same semantics as POST but with with CORS protections. But there's only so much you can accomplish in one proposal :P
But it is. Even if you consider your site single-origin "simple requests" including form posts are allowed by default on some browsers. This requires some sort of solution. There are a handful of possible solutions, but something needs to be done.
Example solutions:
1. Use SameSite cookies.
2. Ensure that you don't respond dangerously to all simple requests.
3. Ignore credentials or block cross site requests.
So that's all well and good, except for the part where even requests without cookies still need an explicit Access-Control-Allow-Origin in the response. As far as I am aware, the only attack vector this protects against is when the destination decides to release sensitive information solely based on the IP address of the source, and not based on its cookies or any other information not already accessible to JS. (Obviously, the biggest instance of this is in the case of local network addresses, but there are efforts to further restrict cross-origin requests to such addresses, using a separate header, Access-Control-Allow-Private-Network [0].)
I find this a shame, since it means that it's impossible to download most public data in a web app without proxying it through your own server, just because of this one edge case.
Maybe with a subdomain that points to the target website IP? If it supports HTTP and doesn't check the host header it should be fine. That's pretty exceptional these days though.
Edit: I just checked and a subdomain won't do it, it needs CORS as well.
If your company hosts content on https://company-news.corp.internal/ it’s very important that some random malicious site on the internet can’t use fetch() or XMLHttpRequest to read that page and exfiltrate that information, just from one of your employees being tricked into visiting that site.
So it’s about more than just cookies.
There is a case to make for old protocols and stuff Microsoft just won't fix (it's always Microsoft). But segmenting a web intranet because you expect the information not to escape is doubly stupid. It not only will escape through an infinity of exploits that exist everywhere; you have exactly 2 groups of people to make access control over, what it certainly insufficient; and finally, you constraint the capacity of people to work physically to inside your office.
It's one layer in the security stack. It's not sufficient on it's own but there's no reason to get rid of it because it's not 100% effective.
> you constraint the capacity of people to work physically to inside your office.
Or, you know, just have a VPN.
Or perhaps the client can tell the server what webpage it's fetching from and the security check can be done server-side?
It is just strange to me that this security check has to be done on client-side (in the browser) as opposed to on the web server actually responsible for distributing the content.
Because people are lazy or they may forget to implement the security checks, or simply be unaware about them.
Ex., when you hacked up a super simple script to display a number of today's users of your startup to display on the big screen in your office. You would probably want something as simple as possible. This page is just 3-5 lines of code. Maybe one-liner even. No authorization or other security, as it's for the office intranet.
Without CORS any website that is visited by people from your office could fetch that number on screen.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...
These days, pretty much everything requires a non-simple request in order to invoke an action, regardless of whether the client can read the result.
Agree'd in spirit though that CORS is annoying to use, and it's always worth consulting the manual.
> pretty much everything requires a non-simple request in order to invoke an action
Except for POST request such as in forms. They may be a little out of fashion with JS-based frontends and JSON APIs but I would consider it a pretty gaping hole. If the list could be reduced to just HEAD and GET requests I would consider it a pretty complete protection. But POST seems like too big of a hole. (Although if you can block all requests that are POST with a "simple" Content-Type then you unlock a pretty robust protection.)
Note on all major browsers unfortunately: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...
A real shame, because it would be a pretty robust solution for sites that don't require any cross-origin interactions at all. That being said it is well supported if set explicitly. So if you can ensure that all cookies that your app sets have the attribute you should be good to go.
nitpick, I guess, but CORS is about CSRF (Cross Site Request Forgery) and not XSS (Cross Site Scripting). If you have an XSS bug, CORS can't save you since they can make requests from your origin.
CORS is an afterthought that never carefully integrated into the ecosystem, which resulted in bad DX. It’s so blunt that applying CORS always feels like a hack.
> Server bound to an inaccessible network interface
This is a niche use case. Most sites don't have this problem.
> Distributed client-side brute-force attack against login
This is pretty easy to solve by adding checks on your login endpoint. But really you should have more robust solutions against login rate limit whether or not they can be triggered by clients on different sites.
It's similar to the Authorization header technique, except you would normally submit it as a parameter in the POST request instead of headers. Explicit credentials are good but has some drawbacks, by being in the headers, you must submit it using fetch(), making it difficult to use in forms or <a>-tags, there the implicit credentials work smoother.
It took a CORS expert from W3C to answer this convoluted CORS question.
https://stackoverflow.com/questions/62289103/same-origin-req...
Better idea than "using Content-Security-Policy to block untrusted scripts": don't link against untrusted scripts.
Seriously though, I think, like this guy suggests, if you avoid cookies on your site or use same site, your fine and cors is mostly a waste.
The main premise of this post is false.
The mentioned request can’t succeed without first completing a preflight check.
Read about 'simple' requests to see what you can and cannot do before a preflight is required: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...
Put simply if I make cross origin POST request that’s JSON type it cannot be a simple request.
There are no ways around this
It doesn’t seem the author was aware of content type once you see their solution.
Normally I would give the benefit of the doubt, but the “fix” is pretty damming here.