It's not just CORS that's hard to understand. Many (most?) developers don't really understand the threat model. And even when it's explained it hard to see why it's a big deal. Part of this is that backend developers usually have to configure CORS and it's not an access privilege protection. From the point of view of the backend it doesn't seem to matter. Bad guys can't get it. From the point of view of the front-end it's often seen as a nuisance.
The article does a nice job giving a concrete example.
> in the cors threat model an attacker gets one your users to take an action on your site by visiting their site
This is really oversimplifying things, incorrectly IMO, and that sentence makes it sound like you're confusing a CSRF vulnerability with CORS protections. Normally when you write a backend server you implement some sort of authentication and access control, and in that scenario the threat model that lets "an attacker gets one your users to take an action on your site by visiting their site" is a CSRF vulnerability, unrelated to CORS.
The scenario presented in TFA is actually a very special case, because the bug is with a webserver running on localhost that doesn't (apparently) implement access control - not something most web apps entail.
In fact, one of the parts that confuses a lot of people is that CORS rules only prevent the JavaScript web client from reading the response from a remote endpoint - if the endpoint is available on the public Internet then anyone can still make a request to it.
The other thing that is confusing about CORS is that browsers already let you load lots of resources from cross origin servers - you can load images (as TFA points out that Zoom did as a workaround), scripts, stylesheets, form submissions, etc. The one thing you can't do, unless the server implements the appropriate CORS headers, is make a cross origin fetch request from JavaScript.
All CORS does is allow for selective loosening of anti-CSRF controls. CORS is a mechanism for a service to tell a client “I’m CSRF-resistant” so that that the client doesn’t need to protect its user as tightly when interacting with that service.
It’s easy to understand but most people don’t naturally think of ways people try to break in. Without thinking about that, the importance of security is low.
It isn’t a knowledge thing (though it could be), or a capability thing, or intelligence. It’s pure mindset.
Ask yourself: is the average person noticing holes in fences and trying random doorknobs… probably not.
But on the other hand, most security people don’t think of product or UX (but some might) so that’s why you have roles.
On top of that, it's a threat model that doesn't make really sense from an attacker vs defender perspective. Because it's optional, and all kinds of other libraries and tools can just blatantly ignore it anyways.
CORS literally exists only against XSS and CSRF for actively logged in human users. Anything else in CORS is absolutely pointless because every other attack scenario uses scripts or programs that fake HTTP headers anyways. It's just as useless as the Sec-CH (client hint) headers because some Browser made by a company that starts with Micro and ends with Slop decided that the User Agent always needs to be Windows 10 for compatibility reasons.
That is why you see everyone just enabling every CORS option anyways, even though that is literally the worst case that allows XSS and CSRF. And a lot of websites have user edited content at some place, at the very least in images that aren't filtered for embedded scripts (PNGs, anyone?).
What else is there in CORS? It’s all basically a way for an origin to communicate to the browser which other origins it can share data with. Of course if there’s no browser involved then there’s no need for it.
Client hints are useful for all the shitty “responsive” websites that don’t know how to use media queries. And for ad tracking. Mostly the latter
I wish more people read the CORS article on MDN[1] which helped me a lot at the time when I was trying to understand it. I knew some people had trouble with CORS but had no idea it was this bad, going by the comments here.
- cors docs are written either from solution or implementation point of view, not the "why this exists, and how we successively deal with bad actors trying to game cors", cors RFC is terse
- protocol itself is quite nuanced, like iirc requests with Authorization (or some other) headers don't obide by usual rules, and again for developer it's just an arbitrary convoluted set of rules, if they don't grasp the problematics
- backend and frontend should work in unison to have correctly configured cors, but as we know, devs hate communicating with each other
The only thing I remember about CORS is that it takes way longer than expected to debug, by design the error messages sent to the browser are intentionally gutted, and CORS error scenarios are hard to tell from other failure modes atfirst glance.
> by design the error messages sent to the browser are intentionally gutted
A CORS error is not "an error message sent to the browser", it is an error generated by the browser, because the browser has decided it cannot permit the request. (Though certainly a server can not understand a CORS request as such, and returned a weird response, which would then end up getting translated to a CORS failure.)
I think what the person you're replying to is trying to say is that the web-accessible error message (i.e., the one that JavaScript running in the sending page can read) is intentionally opaque and somewhat misleading, because a more helpful error message would leak information about the response that the sending origin isn't supposed to have. There's typically a more helpful error message in the dev tools (which JavaScript running in a page can't access), but you have to know where to find it.
Sometimes I'm not even sure what I truly 'understand.'
When even senior engineers working on products used by hundreds of millions of people, like Zoom, have had these kinds of issues, it makes me wonder. So I usually just write code the way it was left by my seniors, out of inertia. But I realize that the area I work in is actually incredibly abstracted.
From my experience, the reason CORS is hard to understand is that it's somehow inverted from the default "shape" of security in web dev.
We easily form the intuition of the client being a by-default untrusted entity, and checking whether it has the privilege of accessing this data, where the server is the arbiter of that access.
CORS is so inherently different to that, and while the information is easily available, it requires a short but careful read to grok the idea -- which a dev tunnel-visioning towards getting their application code written may not wish to slow down for.
CORS sucks since Cross-Origin-Embedder-Policy: credentialless was never made standard across all browsers. It's a browser client restriction you can't turn off. If you want to do anything interesting with WWW content you have to run your own browser or run an out-of-box one off a proxy server that breaks everything.
By default cookies are sent for cross-origin requests. The SameSite cookie flag that lets sites control this was only shipped in Safari the year before this blog post was written so it would have been hard to depend on it yet.
Cookies will be sent if SameSite=None. Because a lot of the web's security features were implemented well after the tech was popular it's a patch-work with lots of overlap.
Wait, isnt it implemented because of the sheer number of broswers that could be used at the Zoom’s scale?
They could’ve used jsonp too it they wanted to bypass CORS.
Using image with different dimensions sounds like the most bulletproof way across multiple devices/OSes/browsers
I'm saying this as someone who has learned about CORS protections many times, implemented the solutions with care they deserved, but forgot most of it soon after - each time. So I'd be very happy to invest even 15 minutes to break this cycle.
As somebody who has spent a lot more than 10 minutes trying to figure out why CORS was blocking what seemed legitimate, I sympathize with people doing the wrong thing, and disagree with your assertion that it’s not that complicated. Maybe I’m just slow. But objectively I know I’m not.
Because, like many things in web, it's a patchwork of compromises due to legacy issues, rampant inconcistencies and trying to be too clever.
You get results where it's really difficult intuitively understand it because at that point you're not really meant to. Realistically, people just follow a guide, or some lib, and move on.
Generally when I'm debugging these, I need/want to know what was the preflight (if applicable), and was the preflight what was expected? When I help others debug these, generally I find there is little expectation of what the preflight "should" be, and instead just a bunch of stochastic attempts to adjust the server's response headers to get the browser to capitulate — regardless of whether that makes any sense at all.
I would also say I think Firefox's network inspector is better in this area. (But I'm often having to ask others to "no, don't send the failing request, send the CORS preflight", we need to understand what happened with it.)
> Anecdotally, lots of developers I’ve talked with don’t understand well how CORS works.
Yeah, most FE devs I've worked with seem to not understand CORS.
> Is the CORS API too complex and confusing
I think it can be hard if you don't understand why the exceptions to preflights are what they are, but the moment you internalize "because the browser can already emit that request in other cases" then it becomes obvious what categories are what & why.
I bet there's an awful lot of servers out there that will happily take CORS requests from any host because someone didn't understand why their second domain couldn't talk to the same API.
everything browser is about still allowing The Bad Thing Ad Companies need.
cors et al is a freaking mess because those things are designed by a comitee choke full of people who last promotion was their cool idea about how to monetize referrer, or how do cookie match across domains, or profile you with millisecond it takes to list your usb audio devices, or etc etc etc
I honestly just can’t be arsed. I write the code to do the thing I want, and if CORS throws a wrench into things, I make Claude fix it for me. I’m tired boss.
It's not just CORS that's hard to understand. Many (most?) developers don't really understand the threat model. And even when it's explained it hard to see why it's a big deal. Part of this is that backend developers usually have to configure CORS and it's not an access privilege protection. From the point of view of the backend it doesn't seem to matter. Bad guys can't get it. From the point of view of the front-end it's often seen as a nuisance.
The article does a nice job giving a concrete example.
It’s not that hard to understand… in the cors threat model an attacker gets one your users to take an action on your site by visiting their site.
> in the cors threat model an attacker gets one your users to take an action on your site by visiting their site
This is really oversimplifying things, incorrectly IMO, and that sentence makes it sound like you're confusing a CSRF vulnerability with CORS protections. Normally when you write a backend server you implement some sort of authentication and access control, and in that scenario the threat model that lets "an attacker gets one your users to take an action on your site by visiting their site" is a CSRF vulnerability, unrelated to CORS.
The scenario presented in TFA is actually a very special case, because the bug is with a webserver running on localhost that doesn't (apparently) implement access control - not something most web apps entail.
In fact, one of the parts that confuses a lot of people is that CORS rules only prevent the JavaScript web client from reading the response from a remote endpoint - if the endpoint is available on the public Internet then anyone can still make a request to it.
The other thing that is confusing about CORS is that browsers already let you load lots of resources from cross origin servers - you can load images (as TFA points out that Zoom did as a workaround), scripts, stylesheets, form submissions, etc. The one thing you can't do, unless the server implements the appropriate CORS headers, is make a cross origin fetch request from JavaScript.
All CORS does is allow for selective loosening of anti-CSRF controls. CORS is a mechanism for a service to tell a client “I’m CSRF-resistant” so that that the client doesn’t need to protect its user as tightly when interacting with that service.
It’s easy to understand but most people don’t naturally think of ways people try to break in. Without thinking about that, the importance of security is low.
It isn’t a knowledge thing (though it could be), or a capability thing, or intelligence. It’s pure mindset.
Ask yourself: is the average person noticing holes in fences and trying random doorknobs… probably not.
But on the other hand, most security people don’t think of product or UX (but some might) so that’s why you have roles.
On top of that, it's a threat model that doesn't make really sense from an attacker vs defender perspective. Because it's optional, and all kinds of other libraries and tools can just blatantly ignore it anyways.
CORS literally exists only against XSS and CSRF for actively logged in human users. Anything else in CORS is absolutely pointless because every other attack scenario uses scripts or programs that fake HTTP headers anyways. It's just as useless as the Sec-CH (client hint) headers because some Browser made by a company that starts with Micro and ends with Slop decided that the User Agent always needs to be Windows 10 for compatibility reasons.
That is why you see everyone just enabling every CORS option anyways, even though that is literally the worst case that allows XSS and CSRF. And a lot of websites have user edited content at some place, at the very least in images that aren't filtered for embedded scripts (PNGs, anyone?).
What else is there in CORS? It’s all basically a way for an origin to communicate to the browser which other origins it can share data with. Of course if there’s no browser involved then there’s no need for it.
Client hints are useful for all the shitty “responsive” websites that don’t know how to use media queries. And for ad tracking. Mostly the latter
I wish more people read the CORS article on MDN[1] which helped me a lot at the time when I was trying to understand it. I knew some people had trouble with CORS but had no idea it was this bad, going by the comments here.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
- cors docs are written either from solution or implementation point of view, not the "why this exists, and how we successively deal with bad actors trying to game cors", cors RFC is terse
- protocol itself is quite nuanced, like iirc requests with Authorization (or some other) headers don't obide by usual rules, and again for developer it's just an arbitrary convoluted set of rules, if they don't grasp the problematics
- backend and frontend should work in unison to have correctly configured cors, but as we know, devs hate communicating with each other
The only thing I remember about CORS is that it takes way longer than expected to debug, by design the error messages sent to the browser are intentionally gutted, and CORS error scenarios are hard to tell from other failure modes atfirst glance.
> by design the error messages sent to the browser are intentionally gutted
A CORS error is not "an error message sent to the browser", it is an error generated by the browser, because the browser has decided it cannot permit the request. (Though certainly a server can not understand a CORS request as such, and returned a weird response, which would then end up getting translated to a CORS failure.)
I think what the person you're replying to is trying to say is that the web-accessible error message (i.e., the one that JavaScript running in the sending page can read) is intentionally opaque and somewhat misleading, because a more helpful error message would leak information about the response that the sending origin isn't supposed to have. There's typically a more helpful error message in the dev tools (which JavaScript running in a page can't access), but you have to know where to find it.
Sometimes I'm not even sure what I truly 'understand.' When even senior engineers working on products used by hundreds of millions of people, like Zoom, have had these kinds of issues, it makes me wonder. So I usually just write code the way it was left by my seniors, out of inertia. But I realize that the area I work in is actually incredibly abstracted.
> Developer's don't understand CORS
Count me in!
From my experience, the reason CORS is hard to understand is that it's somehow inverted from the default "shape" of security in web dev.
We easily form the intuition of the client being a by-default untrusted entity, and checking whether it has the privilege of accessing this data, where the server is the arbiter of that access.
CORS is so inherently different to that, and while the information is easily available, it requires a short but careful read to grok the idea -- which a dev tunnel-visioning towards getting their application code written may not wish to slow down for.
CORS sucks since Cross-Origin-Embedder-Policy: credentialless was never made standard across all browsers. It's a browser client restriction you can't turn off. If you want to do anything interesting with WWW content you have to run your own browser or run an out-of-box one off a proxy server that breaks everything.
I still don't understand the threat model and, obviously, it's not explained here either.
I log in to social.net. I click on scam.org and change sites. I'm on scam.org and it triggers a request to social.net/friends.
No cookies are sent, no JWT. I'm not logged in and get a "Needs login" HTTP error. Nothing bad happens.
I thought that's how it works without CORS already.
By default cookies are sent for cross-origin requests. The SameSite cookie flag that lets sites control this was only shipped in Safari the year before this blog post was written so it would have been hard to depend on it yet.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Coo...
Cookies will be sent if SameSite=None. Because a lot of the web's security features were implemented well after the tech was popular it's a patch-work with lots of overlap.
Wait, isnt it implemented because of the sheer number of broswers that could be used at the Zoom’s scale? They could’ve used jsonp too it they wanted to bypass CORS. Using image with different dimensions sounds like the most bulletproof way across multiple devices/OSes/browsers
the amount of code i've seen either allowing * when it shouldn't because someone was desperately trying to make their code work is astounding.
contractors, "specialists", etc. who never took the time to read how CORS works and how simply you can handle a list of allowable sites, etc.
it's only complicated until you take the 5-10 minutes to properly understand what happens where. if you don't know, go do it now.
5-10 minutes? I'm sold. Any link you can share?
I'm saying this as someone who has learned about CORS protections many times, implemented the solutions with care they deserved, but forgot most of it soon after - each time. So I'd be very happy to invest even 15 minutes to break this cycle.
As somebody who has spent a lot more than 10 minutes trying to figure out why CORS was blocking what seemed legitimate, I sympathize with people doing the wrong thing, and disagree with your assertion that it’s not that complicated. Maybe I’m just slow. But objectively I know I’m not.
“Objectively”
Because, like many things in web, it's a patchwork of compromises due to legacy issues, rampant inconcistencies and trying to be too clever.
You get results where it's really difficult intuitively understand it because at that point you're not really meant to. Realistically, people just follow a guide, or some lib, and move on.
Generally when I'm debugging these, I need/want to know what was the preflight (if applicable), and was the preflight what was expected? When I help others debug these, generally I find there is little expectation of what the preflight "should" be, and instead just a bunch of stochastic attempts to adjust the server's response headers to get the browser to capitulate — regardless of whether that makes any sense at all.
I would also say I think Firefox's network inspector is better in this area. (But I'm often having to ask others to "no, don't send the failing request, send the CORS preflight", we need to understand what happened with it.)
> Anecdotally, lots of developers I’ve talked with don’t understand well how CORS works.
Yeah, most FE devs I've worked with seem to not understand CORS.
> Is the CORS API too complex and confusing
I think it can be hard if you don't understand why the exceptions to preflights are what they are, but the moment you internalize "because the browser can already emit that request in other cases" then it becomes obvious what categories are what & why.
Correct. Where are some good explanations?
I bet there's an awful lot of servers out there that will happily take CORS requests from any host because someone didn't understand why their second domain couldn't talk to the same API.
That describes pretty much every server I've ever written lol.
The only thing to understand is that it does nothing useful today.
Doesn't it help protect clients from malicious 3P JS?
At least so long as they don't have malicious extensions or a non-CORS browser?
everything browser is about still allowing The Bad Thing Ad Companies need.
cors et al is a freaking mess because those things are designed by a comitee choke full of people who last promotion was their cool idea about how to monetize referrer, or how do cookie match across domains, or profile you with millisecond it takes to list your usb audio devices, or etc etc etc
I honestly just can’t be arsed. I write the code to do the thing I want, and if CORS throws a wrench into things, I make Claude fix it for me. I’m tired boss.
Good for you. It's the responsibility of the boss to hire someone to type "claude pls check if prorgam not safe"