Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly:
> The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.
No, that does not do that. JavaScript from any other website can still talk to localhost:19421 just the same. CORS doesn't restrict anything, it loosens the default set of restrictions (ignoring preflight requests for now and assuming we're talking just about "safe" Methods). That Access-Control-Allow-Origin header just allows JavaScript running on zoom.us to read the responses when it queries localhost:19421. The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects.
> Further, native apps can generate a unique self-signed certificate.
Just creating a certificate will not work, unless it's installed as root CA certificates in all browser trust-stores on the machine. And if the private key of the root CA is not secured correctly, one could MitM any websites. So at least you want it name constrained (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....), but at least in Chrome until 2023 (v112) that did not work on root CA's (https://alexsci.com/blog/name-non-constraint/), so you had to add an intermediate CA and add the constrain there. Of course, you should also just throw away the key of the root CA.
I will admit I once added basic constrains in some project with a local root CA (2020-2022), but 'incorrectly' to the root CA, and did not test it in all browsers.
The degree to which CORS is poorly understood (I have read numerous (often contradictory) documentation and I don't really understand it.) means that you can't rely on it being implemented properly by an unknown party,
If a protocol reaches this level of widespread confusion, I think all bets are off. Even if one end of a system performs correctly, who's to say that the other will. If people adapt their code until it works with another implementation, were they mistaken, or the other end?
> assuming we're talking just about "safe" Methods
That's a pretty big assumption. Any decent webdev should not let GET/HEAD/OPTIONS modify state (joining a meeting is changing state) and additionally PUT/DELETE should also be idempotent.
POST with JSON (or other non-form formats) api's should also have it's content-type header checked (text/plain forms can send a JSON body but the content-type will be text/plain). PUT/PATCH/DELETE and POST with a non-form content-type (application/x-www-form-urlencoded, multipart/form-data, or text/plain) will trigger a preflight so that CORS is properly checked before the actual request reaches the server.
100% - although it is stunning to see since most LLMs get CORS questions right (which is surprising since they trained on all sorts of incorrect data).
Maybe it’s like that trick where if a thousand people guess the amount of beans in a jar almost all of them will be wrong but their average will be very close to, if not, correct.
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.
We had a project were the same developer wrote the frontend and backend and still managed to get CORS wrong. As the operations people we rewrote them correctly in the load balancer... well I assume correctly, at least the application now works.
CORS is really hard to wrap your head around, but sadly there's also a ton of developers that not only fail understand the threat model that CORS guards against, they also don't understand webdevelopment in general, especially the http protocol. I find that somewhat strange, because they also can't do native application.
> 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.
Isn't CSRF about forging mutating requests? CORS doesn't block the underlying GET/POST request, the request still goes through and the server still needs to properly implement CSRF prevention. CORS just prevents javascript from reading the response.
CORS _additionally_ requires OPTIONS pre-flight to succeed, before allowing any kind of request outside of what can be achieved with a HTML form submit action. So it blocks PUT/PATCH/DELETE, specifying most Content-Type, and specifying nearly all other headers. But this is just blocking "non-standard complex requests that might confuse badly programmed pre-javascript-era servers".
It passes all standard requests that you could have made by: embedding the url as an image src, the target of a HTML form, endpoint for csp reports, etc. All still need to be checked methodically by the server for CSRF if it's going to take any mutating action due to the request.
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
CORS is amazing for when you want to prevent people from (easily) stealing your bandwidth and hosting resources. Thieves have to stand up their own proxies, which makes them very easily blocked.
It was pretty amusing reading the comment section so I'll chime in: SOP protects you (the browser) from leaking information to websites that should not be able to access that information and CORS allows you to weaken it.
Example: SOP stops example.com from fetching the list of subscriptions on youtube.com. But CORS allows example.com to access youtube.com/public/*.
This is also not the sole use-case, it also stops your backend api being up under a different frontend which would allow data theft since you could log into real services on google.com, but you're actually on g00gle.com enabling data exfiltration because now every request can be MitM'd.
No, it's exactly the other way around. The SOP protects you from these security issues. CORS is a feature that can be used to loosen up the SOP, to allow more complex inter-application behaviour.
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.
> So what would a secure implementation of this feature look like? The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.
First of all, its not CORS that protects. CORS is an anti-security feature. What does protect is the SOP (same origin policy). The SOP (or SOPs rather, it's not really one feature but more of a paradigm in the standards) blocks documents from one origin, from reading data that belongs to another origin. This is the reason why `let w = window.open("https://example.com"); console.dir(w.document.body);` will work when it is ran from example.com, but not wikipedia.org. Only when protocol, host and port match, can documents access each others data (there is an interesting differential with cookies here, their SOP only looks at protocol and host, not port).
Importantly, the SOP only blocks reading data from other origins, not writing! So while example.com won't be able to read the response of a post request it sends to wikipedia.org, the request is sent and processed nontheless!
CORS now is a feature that allows sites to loosen up the SOP. This allows documents to read cross origin data nontheless. Namely, HTTP responses. (Standards for reading other kinds of data cross origin exist, but are not related to CORS).
This is really a self inflicted problem. If you host your backend on the same origin as your frontend (using a reverse proxy) you don’t need CORS at all and you can use the vanilla SOP, and strengthen it further with a strict CSP.
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.
I'm one of them. CORS is THE topic that I have to get a refresher for periodically. It's like I forget about it, it never sticks. I'm a backend developer so I never encounter any cors issues. Maybe that's why? I seem to forget things that I don't use on a day to day basis, so.
The DX for CORS and CSP is horrible because none of the browsers point out where the problem is coming from. In a sane world they would all write "response header" or "meta tag" somewhere in the message but the Riddler, Jigsaw, the Cheshire Cat were each hired by the major browser vendors to write the error messages. Chrome is the closest with "requested resource" but that's still downright cryptic. But on the other hand I'm glad all three of them still agree on something.
Edit: I realize that this is a fairly non-constructive comment, so to fix that, my suggested replacements are:
Resource https://bank.com doesn't allow cross-origin requests due to lack of CORS headers. (Link to preflight request in Network tab) CORS protects against unaffiliated sites requesting data from your server. (Link to MDN)
Resource https://bank.com doesn't allow cross-origin requests because this origin isn't in its CORS allowlist. (Link to preflight request in Network tab) ...
Resource https://... can't be fetched due to CSP headers in this page. (Link to page request headers or meta tags in inspector) CSP prevents unauthorized scripts from executing on your page. (Link to MDN)
The biggest problem with CORS is precisely that most CORS errors show up as a frontend problem - specifically, a browser problem - but it needs to be fixed on the backend
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.
I think that once you understand that CORS is about protecting the visitor not the server you're halfway there.
Also, if you have everything set up properly, the fact that you're haveing any CORS issues at all means you're probably trying to do something stupid and you need to ask someone smarter how to solve your problem.
- 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
CORS is counter intuitive. I don’t think there is a better way to solve the problem, it is just a difficult to understand problem.
CORS errors occur when JavaScript in the browser attempts to call a server which is not configured to allow it. But the check is purely client-side. You can easily disable it in code and you can circumvent it entirely by using curl or whatever outside the browser.
For example the server sends a header indicating which domains it allows requests from, but it does not actually check if requests are from those domains. It is the responsibility of the client to check its domain is allowed.
All this make it seem like a pretty useless security feature, unless you understand the very specific kind of attack this protects aginst.
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.
I think some sort of gui to help write the cors headers would help tbh.
it's quite difficult to get your stack to work for local dev, CI, and prod since each most likely needs different cors headers. Especially if you use tunnels and proxies like we do.
What made it click for me though was understanding what problem it solved.
Issue is that for most projects CORS is set and forget. You don’t run into it once a month or even once a year - you run into it when setting up new project from scratch.
Many or most developers work on existing projects that have all kinds of security defaults set somewhere in the past and no one bothers reviewing those.
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.
Sometimes it's a good thing when I try to use someone else's backend in my web app. For example map tile server or route builder, which are session-less and have no authentication.
The idea that HTTP servers are restricted to requests from a single domain by default is strange, wonder if CORS world be better off opt-in rather than opt-out.
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.
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.
access is provided under condition you respect these restrictions
You are not obliged to honour this. It is not enforceable so it seems strange.
Browsers enforce it, but it can be turned off and nobody expects it to be implemented by a simple REST client application.
It’s a gentleman’s agreement. It’s a statement of expectation to the browser. On the one hand it may be for the protection of the browser user, from cross site attacks, and from malicious code on the web.
But crucially it provides little protection for the endpoints themselves bar accidental misuse.
It is very unusual and rare example of “cooperative” security in a web that’s frequently so adversarial.
> Browsers enforce it, but it can be turned off and nobody expects it to be implemented by a simple REST client application.
No, you're missing the point. Normal people using normal browsers with default settings have CORS enabled. That's the vast majority of your users; everyone who disables it stupidly opts into a risk themselves without any reason to.
So the expectation that CORS is enabled on your user's devices holds. This means it's not a gentleman's agreement!
A CORS protected endpoint tells YOUR BROWSER not to let YOU access its content if the website you’re browsing from is not whitelisted.
It’s confusing because unlike most security features, it’s meant to protect the users from themselves. The risk comes from a combination of users being allowed to visit malevolent sites and browsers letting all websites do a lot of random stuff, including making 3rd party requests with cookies and private stuff
TL;DR: It's a restriction your browser gives itself. If it's on Domain A and it sees a request going out to Domain B, unless Domain B responds saying that it's expecting traffic from Domain A, the browser prevents itself from making the call.
I think the part about it that is off/silly to most people is that it's not a normal security threat model, because a malicious client could simply just...not impose that restriction on itself. You're perfectly capable of going and curling that same request to that backend, or calling it from an app, or any number of other things. So it's not really protecting your protected resource, the backend, from malicious clients.
All of that is where I feel like I understand clearly. The part I fail to retain is the exact scenarios it does protect against, which IIRC, are basically about attempting to protect your users from being misguided on other clients that are acting as your client, something like that (but again, this literally only applies to browsers). It's just kind of a weird niche problem that I often find myself thinking "I mean why is the user on another client and have allowed themselves to authenticate on that client with my server...this sounds like the user's fault."
The part you may be missing is that cookies exist.
User visits A.com, types in their username and password, and a cookie is set in their browser. The browser will send that cookie back to A.com with all subsequent requests, and A.com's server will use it to enable access to the user's account.
Now the user visits B.com, which makes a request to A.com/private_user_data. The user's cookie is sent with this request, so A.com will respond with (and B.com will receive) the user's private data without the user consenting to this at all (not even in a "misguided" way).
> […] the browser prevents itself from making the call.
That's not strictly correct, by the way. The request is made, but the JavaScript code on Domain A is not allowed to read the response. This matters when a request is destructive on its own, for example.
To go even deeper into the weeds: this is only true of "simple" requests[0]. Requests that aren't "simple" always require preflight approval. This is based on which requests a <form> or link could already create without approval; since the dawn of time, <form method="post"> could submit a potentially-destructive request, and sites needed to protect themselves against that via XSRF tokens; so CORS could allow submiting the same class of requests without preflight approval, and not introduce any new attacks. But there's no <form method="delete">, for example, so CORS would have created attacks against previously-secure sites if it had allowed DELETE requests without preflight approval.
What do you mean? It's a way to mitigate a certain attack vector and as far as I can tell, it works as intended given the circumstances it was designed under.
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.
Yes, many developers give nothing about even basic security.
That's why we still have every basic security issue like hardcoded passwords, SQL or other injections, XSRF and so on repeated on an endless loop. Even if they are trivial to avoid.
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
It's me, CORS was the stupidest thing I encountered in a long line of stupid when trying to put together a simple web app for the first time.
"So let me get this straight. We tell the client whether the application we gave them can or cannot make requests to our servers. And none of this actually prevents the client from making the requests if they want to?... Pull the other one it has bells on."
It took a good sleep and a long shower to under stand it. "Oh... it is for if I want to do a self injection attack and allow random untrusted malicious code in my application. In other words, ads"
Basically the threat model is inverted from any other threat model, that is why it looks so stupid. CORS is threat model used for when you can't trust your self.
Well, it's easy to "not trust yourself" when you have user-submittable content that you display for other users. Sure, one should absolutely sanitize it, but layered security is important.
> CORS is threat model used for when you can't trust your self.
No. But many lack basic understanding of web technologies or facts like that a browser can be used to access more than a single site. This leads to not understanding what problems cross-site requests can cause and thus the impossibility of understanding what CORS is 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.
Its not? Remember the 90s? There was a beautiful time before CORS and DRM in the browser. Browsers used to be something that actually cared about allowing full client control.
But it isn't the 90s anymore. Billions of people are using the internet, doing everything from voting to shopping to managing their stock portfolio. There are valid reasons why we have security protocols.
And aside from that - it's not like CORS is preventing you from anything. The only requirement is to read up on it, understand it, and configure your web server accordingly. If you're unable to do that, or you'd rather create your own browser, then the only conclusion I can draw is that you're either unwilling or unable to take proper care of the security of your users.
I don't care about my server. It has everything to do with what it is preventing my browser client from doing. The whole point is using content from the whole web not my server.
I agree that CORS is hard to understand and fix. I was the CTO at an auth company and SO many of our users used to run into various CORS issues and asked questions on our support. However, I'd now argue that developers don't need to understand CORS anymore.. cause claude / gpt does! Just throw in the error in claude code / codex and it would fix it.
The second part of this comment is not what I expected. I also don’t think it is true. I got bit by a CORS error at work recently that passed by Claude, copilot, and another senior engineer.
It's astounding how willingly people give up their agency. Dystopic sci-fi novels turn out to be bogus, because nobody will rebel against the machines if it prints funny progress indicator words to the terminal
Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly:
> The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.
No, that does not do that. JavaScript from any other website can still talk to localhost:19421 just the same. CORS doesn't restrict anything, it loosens the default set of restrictions (ignoring preflight requests for now and assuming we're talking just about "safe" Methods). That Access-Control-Allow-Origin header just allows JavaScript running on zoom.us to read the responses when it queries localhost:19421. The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects.
Another quote from the article:
> Further, native apps can generate a unique self-signed certificate.
Just creating a certificate will not work, unless it's installed as root CA certificates in all browser trust-stores on the machine. And if the private key of the root CA is not secured correctly, one could MitM any websites. So at least you want it name constrained (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....), but at least in Chrome until 2023 (v112) that did not work on root CA's (https://alexsci.com/blog/name-non-constraint/), so you had to add an intermediate CA and add the constrain there. Of course, you should also just throw away the key of the root CA.
I will admit I once added basic constrains in some project with a local root CA (2020-2022), but 'incorrectly' to the root CA, and did not test it in all browsers.
I don't think you can even say CORS does that.
The degree to which CORS is poorly understood (I have read numerous (often contradictory) documentation and I don't really understand it.) means that you can't rely on it being implemented properly by an unknown party,
If a protocol reaches this level of widespread confusion, I think all bets are off. Even if one end of a system performs correctly, who's to say that the other will. If people adapt their code until it works with another implementation, were they mistaken, or the other end?
It seems like nobody understands CORS.
Including me TBH.
> assuming we're talking just about "safe" Methods
That's a pretty big assumption. Any decent webdev should not let GET/HEAD/OPTIONS modify state (joining a meeting is changing state) and additionally PUT/DELETE should also be idempotent.
POST with JSON (or other non-form formats) api's should also have it's content-type header checked (text/plain forms can send a JSON body but the content-type will be text/plain). PUT/PATCH/DELETE and POST with a non-form content-type (application/x-www-form-urlencoded, multipart/form-data, or text/plain) will trigger a preflight so that CORS is properly checked before the actual request reaches the server.
> Any decent webdev should not let GET/HEAD/OPTIONS modify state
> additionally PUT/DELETE should also be idempotent
Yes, but I think the majority of large web applications are not fully correct in terms of 'Safe and Idempotent Methods' (https://datatracker.ietf.org/doc/html/rfc9110#name-common-me...).
I think this is legitimately the least informed HN comment section I've ever seen. Entirely proving the author's point.
100% - although it is stunning to see since most LLMs get CORS questions right (which is surprising since they trained on all sorts of incorrect data).
Maybe it’s like that trick where if a thousand people guess the amount of beans in a jar almost all of them will be wrong but their average will be very close to, if not, correct.
Guidelines say to edit out swipes, so your comment can be edited to just:
""
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.
We had a project were the same developer wrote the frontend and backend and still managed to get CORS wrong. As the operations people we rewrote them correctly in the load balancer... well I assume correctly, at least the application now works.
CORS is really hard to wrap your head around, but sadly there's also a ton of developers that not only fail understand the threat model that CORS guards against, they also don't understand webdevelopment in general, especially the http protocol. I find that somewhat strange, because they also can't do native application.
> I assume correctly, at least the application now works.
That's like saying the lock works because people can enter the building. What about keeping the bad guys out, which is the whole point?
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.
Isn't CSRF about forging mutating requests? CORS doesn't block the underlying GET/POST request, the request still goes through and the server still needs to properly implement CSRF prevention. CORS just prevents javascript from reading the response.
CORS _additionally_ requires OPTIONS pre-flight to succeed, before allowing any kind of request outside of what can be achieved with a HTML form submit action. So it blocks PUT/PATCH/DELETE, specifying most Content-Type, and specifying nearly all other headers. But this is just blocking "non-standard complex requests that might confuse badly programmed pre-javascript-era servers".
It passes all standard requests that you could have made by: embedding the url as an image src, the target of a HTML form, endpoint for csp reports, etc. All still need to be checked methodically by the server for CSRF if it's going to take any mutating action due to the request.
> CORS rules only prevent the JavaScript web client from reading the response from a remote endpoint
Assuming the web client plays nicely. I commonly bypass CORS for playwright unit/E2E testing.
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
CORS is amazing for when you want to prevent people from (easily) stealing your bandwidth and hosting resources. Thieves have to stand up their own proxies, which makes them very easily blocked.
I think you're confused. The only thing blocked would be client side fetch. You need to find another way to protect everything else.
How's it going with AI scrapers for you
It was pretty amusing reading the comment section so I'll chime in: SOP protects you (the browser) from leaking information to websites that should not be able to access that information and CORS allows you to weaken it.
Example: SOP stops example.com from fetching the list of subscriptions on youtube.com. But CORS allows example.com to access youtube.com/public/*.
This is also not the sole use-case, it also stops your backend api being up under a different frontend which would allow data theft since you could log into real services on google.com, but you're actually on g00gle.com enabling data exfiltration because now every request can be MitM'd.
No, it's exactly the other way around. The SOP protects you from these security issues. CORS is a feature that can be used to loosen up the SOP, to allow more complex inter-application behaviour.
ah right, my own brain got jumbled from reading all the comments forgetting that cors: '*' is not the default.
I love this, easy intuitive explanation
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...
This blog post is very misleading.
> So what would a secure implementation of this feature look like? The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.
First of all, its not CORS that protects. CORS is an anti-security feature. What does protect is the SOP (same origin policy). The SOP (or SOPs rather, it's not really one feature but more of a paradigm in the standards) blocks documents from one origin, from reading data that belongs to another origin. This is the reason why `let w = window.open("https://example.com"); console.dir(w.document.body);` will work when it is ran from example.com, but not wikipedia.org. Only when protocol, host and port match, can documents access each others data (there is an interesting differential with cookies here, their SOP only looks at protocol and host, not port).
Importantly, the SOP only blocks reading data from other origins, not writing! So while example.com won't be able to read the response of a post request it sends to wikipedia.org, the request is sent and processed nontheless!
CORS now is a feature that allows sites to loosen up the SOP. This allows documents to read cross origin data nontheless. Namely, HTTP responses. (Standards for reading other kinds of data cross origin exist, but are not related to CORS).
This is really a self inflicted problem. If you host your backend on the same origin as your frontend (using a reverse proxy) you don’t need CORS at all and you can use the vanilla SOP, and strengthen it further with a strict CSP.
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.
People hating on web developers and/or saying application developers are better and then everyone bombs the RFC challenge.
I'm one of them. CORS is THE topic that I have to get a refresher for periodically. It's like I forget about it, it never sticks. I'm a backend developer so I never encounter any cors issues. Maybe that's why? I seem to forget things that I don't use on a day to day basis, so.
The DX for CORS and CSP is horrible because none of the browsers point out where the problem is coming from. In a sane world they would all write "response header" or "meta tag" somewhere in the message but the Riddler, Jigsaw, the Cheshire Cat were each hired by the major browser vendors to write the error messages. Chrome is the closest with "requested resource" but that's still downright cryptic. But on the other hand I'm glad all three of them still agree on something.
Edit: I realize that this is a fairly non-constructive comment, so to fix that, my suggested replacements are:
The biggest problem with CORS is precisely that most CORS errors show up as a frontend problem - specifically, a browser problem - but it needs to be fixed on the backend
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.
CORS, CSRF and CSP get the job done;)
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.
I think that once you understand that CORS is about protecting the visitor not the server you're halfway there.
Also, if you have everything set up properly, the fact that you're haveing any CORS issues at all means you're probably trying to do something stupid and you need to ask someone smarter how to solve your problem.
I don't fully understand CORS and was hoping he'd explain how it works. :(
- 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
> Developer's don't understand CORS
Count me in!
Even the HN comments here are a sea of confusion and contradiction.
It's stunning and makes me wonder whether CORS is a bad solution, or if it's solving a hard problem.
CORS is counter intuitive. I don’t think there is a better way to solve the problem, it is just a difficult to understand problem.
CORS errors occur when JavaScript in the browser attempts to call a server which is not configured to allow it. But the check is purely client-side. You can easily disable it in code and you can circumvent it entirely by using curl or whatever outside the browser.
For example the server sends a header indicating which domains it allows requests from, but it does not actually check if requests are from those domains. It is the responsibility of the client to check its domain is allowed.
All this make it seem like a pretty useless security feature, unless you understand the very specific kind of attack this protects aginst.
Could you go the full mile and explain that very specific kind of attack?
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.
I think some sort of gui to help write the cors headers would help tbh.
it's quite difficult to get your stack to work for local dev, CI, and prod since each most likely needs different cors headers. Especially if you use tunnels and proxies like we do.
What made it click for me though was understanding what problem it solved.
I understand CORS each time I need to fix or to avoid them ;)
Issue is that for most projects CORS is set and forget. You don’t run into it once a month or even once a year - you run into it when setting up new project from scratch.
Many or most developers work on existing projects that have all kinds of security defaults set somewhere in the past and no one bothers reviewing those.
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.
Sometimes it's a good thing when I try to use someone else's backend in my web app. For example map tile server or route builder, which are session-less and have no authentication.
The idea that HTTP servers are restricted to requests from a single domain by default is strange, wonder if CORS world be better off opt-in rather than opt-out.
> wonder if CORS world be better off opt-in rather than opt-out.
It's necessary that the defaults are secure. More so, not less, if the problem is hard.
That describes pretty much every server I've ever written lol.
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...
Your cookies are sent.
Then why wasn't credentialless a simple fix to solve that. Not sending cookies isn't hard.
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”
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?
It’s TOS for using ebdpoint. It says:
access is provided under condition you respect these restrictions
You are not obliged to honour this. It is not enforceable so it seems strange.
Browsers enforce it, but it can be turned off and nobody expects it to be implemented by a simple REST client application.
It’s a gentleman’s agreement. It’s a statement of expectation to the browser. On the one hand it may be for the protection of the browser user, from cross site attacks, and from malicious code on the web.
But crucially it provides little protection for the endpoints themselves bar accidental misuse.
It is very unusual and rare example of “cooperative” security in a web that’s frequently so adversarial.
And that’s what makes it hard to grasp.
> Browsers enforce it, but it can be turned off and nobody expects it to be implemented by a simple REST client application.
No, you're missing the point. Normal people using normal browsers with default settings have CORS enabled. That's the vast majority of your users; everyone who disables it stupidly opts into a risk themselves without any reason to.
So the expectation that CORS is enabled on your user's devices holds. This means it's not a gentleman's agreement!
A CORS protected endpoint tells YOUR BROWSER not to let YOU access its content if the website you’re browsing from is not whitelisted.
It’s confusing because unlike most security features, it’s meant to protect the users from themselves. The risk comes from a combination of users being allowed to visit malevolent sites and browsers letting all websites do a lot of random stuff, including making 3rd party requests with cookies and private stuff
Isn't it arguably the opposite?
A CORS header in the response tells your browser to relax CORS restrictions.
Like the sibling said: CORS is the relaxation of default security features. It's even in the name: Cross-Origin Resource Sharing.
'No Sharing' is a policy on sharing. Being literal about the name misses their point.
I understand CORS and I don't.
TL;DR: It's a restriction your browser gives itself. If it's on Domain A and it sees a request going out to Domain B, unless Domain B responds saying that it's expecting traffic from Domain A, the browser prevents itself from making the call.
I think the part about it that is off/silly to most people is that it's not a normal security threat model, because a malicious client could simply just...not impose that restriction on itself. You're perfectly capable of going and curling that same request to that backend, or calling it from an app, or any number of other things. So it's not really protecting your protected resource, the backend, from malicious clients.
All of that is where I feel like I understand clearly. The part I fail to retain is the exact scenarios it does protect against, which IIRC, are basically about attempting to protect your users from being misguided on other clients that are acting as your client, something like that (but again, this literally only applies to browsers). It's just kind of a weird niche problem that I often find myself thinking "I mean why is the user on another client and have allowed themselves to authenticate on that client with my server...this sounds like the user's fault."
The part you may be missing is that cookies exist.
User visits A.com, types in their username and password, and a cookie is set in their browser. The browser will send that cookie back to A.com with all subsequent requests, and A.com's server will use it to enable access to the user's account.
Now the user visits B.com, which makes a request to A.com/private_user_data. The user's cookie is sent with this request, so A.com will respond with (and B.com will receive) the user's private data without the user consenting to this at all (not even in a "misguided" way).
> […] the browser prevents itself from making the call.
That's not strictly correct, by the way. The request is made, but the JavaScript code on Domain A is not allowed to read the response. This matters when a request is destructive on its own, for example.
To go even deeper into the weeds: this is only true of "simple" requests[0]. Requests that aren't "simple" always require preflight approval. This is based on which requests a <form> or link could already create without approval; since the dawn of time, <form method="post"> could submit a potentially-destructive request, and sites needed to protect themselves against that via XSRF tokens; so CORS could allow submiting the same class of requests without preflight approval, and not introduce any new attacks. But there's no <form method="delete">, for example, so CORS would have created attacks against previously-secure sites if it had allowed DELETE requests without preflight approval.
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
The only thing to understand is that it does nothing useful today.
What do you mean? It's a way to mitigate a certain attack vector and as far as I can tell, it works as intended given the circumstances it was designed under.
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?
I definitely understand CORS in theory, then when it's time to solve a CORS related error, anything goes. /s
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"
Yes, many developers give nothing about even basic security.
That's why we still have every basic security issue like hardcoded passwords, SQL or other injections, XSRF and so on repeated on an endless loop. Even if they are trivial to avoid.
, claude fixes it by doing insecure shit, your secrets end up exposed, you end up running a $10,000 api bill, you wonder how you got there.
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
It's me, CORS was the stupidest thing I encountered in a long line of stupid when trying to put together a simple web app for the first time.
"So let me get this straight. We tell the client whether the application we gave them can or cannot make requests to our servers. And none of this actually prevents the client from making the requests if they want to?... Pull the other one it has bells on."
It took a good sleep and a long shower to under stand it. "Oh... it is for if I want to do a self injection attack and allow random untrusted malicious code in my application. In other words, ads"
Basically the threat model is inverted from any other threat model, that is why it looks so stupid. CORS is threat model used for when you can't trust your self.
Well, it's easy to "not trust yourself" when you have user-submittable content that you display for other users. Sure, one should absolutely sanitize it, but layered security is important.
> CORS is threat model used for when you can't trust your self.
No. But many lack basic understanding of web technologies or facts like that a browser can be used to access more than a single site. This leads to not understanding what problems cross-site requests can cause and thus the impossibility of understanding what CORS is for.
Eh, or maybe you landed on a malicious site or clicked on a malicious phishing link which opened your browser
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.
> If you want to do anything interesting […] you have to run your own browser
This is usually a sign you don't really understand what you're doing.
Its not? Remember the 90s? There was a beautiful time before CORS and DRM in the browser. Browsers used to be something that actually cared about allowing full client control.
But it isn't the 90s anymore. Billions of people are using the internet, doing everything from voting to shopping to managing their stock portfolio. There are valid reasons why we have security protocols.
And aside from that - it's not like CORS is preventing you from anything. The only requirement is to read up on it, understand it, and configure your web server accordingly. If you're unable to do that, or you'd rather create your own browser, then the only conclusion I can draw is that you're either unwilling or unable to take proper care of the security of your users.
I don't care about my server. It has everything to do with what it is preventing my browser client from doing. The whole point is using content from the whole web not my server.
I agree that CORS is hard to understand and fix. I was the CTO at an auth company and SO many of our users used to run into various CORS issues and asked questions on our support. However, I'd now argue that developers don't need to understand CORS anymore.. cause claude / gpt does! Just throw in the error in claude code / codex and it would fix it.
The second part of this comment is not what I expected. I also don’t think it is true. I got bit by a CORS error at work recently that passed by Claude, copilot, and another senior engineer.
> developers don’t need to understand X … cause claude does!
…………………
damn where are we heading?
It's astounding how willingly people give up their agency. Dystopic sci-fi novels turn out to be bogus, because nobody will rebel against the machines if it prints funny progress indicator words to the terminal