> 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.
> The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects.
GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests.
For non-idempotent requests however (the only ones that are supposed to be able to have side effects), a preflight OPTION request will be sent in cross-origin context instead of sending the request itself. And unless the right headers are set in the OPTION response, the request won't be sent at all.
This is not correct. Safety and idempotency are two different concepts. Safety is when a request does not result in a state change. Idempotency is when the outcome is the same whether you make the request once or several times.
GET is defined to be both safe and idempotent. Clients can make GET requests without explicit human intent driving them because they are safe, not because they are idempotent.
DELETE is not defined to be safe but it is defined to be idempotent. This means you need human intent to drive it, but clients can retry as much as they like because whether you ask to delete a resource one time or a hundred times, the result is still the same – the resource is deleted. Obviously making DELETE requests can result in adverse effects even though it is idempotent.
POST is neither safe nor idempotent, however it’s subject to some unintuitive rules when it comes to things like cross-origin requests for historical reasons.
> DELETE is not defined to be safe but it is defined to be idempotent
This one puzzles me though. How can DELETE be idempotent? If the first request works then the second one should return a 404, as the key to delete doesn't exist anymore.
Idempotency just means no state mutation on subsequent request.
Then you'd return 202 on a request to delete any invalid element, which really doesn't sound right.
> 200 with some sort of response to distinguish (e.g. { changed: boolean }).
Sounds even worse, and much like APIs that returns 200 with a payload saying {error:"not found"}
But CORS affect all other requests, e.g POST using JSON or XML content type, and all other methods like PUT, DELETE, PATCH.
So you can do an unsafe POST using form-encoded data, but if a server supports this, they hopefully mitigate CSRF, since this has always been a risk.
Just my first thought as a security engineer, but sounds like a perfect opportunity to execute a timing attack to me. For example, vheck which users exist (by measuring response time for /api/users?name=john) etc
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?
So there is only one end of the system that is confused - the servers - but at least the other end - the browsers - can mostly be trusted to implement it correctly.
(*) unless you're implementing an open proxy, but then you have bigger problems.
I think OPs point is that many of those rule sets probably don’t do what the author intended.
I would second that, because CORS questions are common and “turn on the allow all pattern” is almost always in the top 3 suggestions.
Semi-related tangent, it annoys the hell out of me that create-react-app (and the newer incarnation) don’t come with an “allow all” CORS rule. Don’t force me to figure out which arcane setting configures CORS headers, I’m the one writing the code, I’m okay with wherever the HTTP requests are going, I’ll set up real CORS headers on nginx for prod.
Back in the day, I was using Cloudhopper, a Twitter-developed library for the SMPP protocol (not to be confused with SMTP!). Protocols being protocols, there are strict limits on field sizes, defined on the actual protocol spec. I noticed that Cloudhopper didn't impose those limits, however.
Long story short, it turns out they just left out strictly imposing field limits because other implementations didn't care either. De facto has overruled de jura and the inmates are running the asylum!
Including me TBH.
Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this opens up a whole host of issues, so browsers started limiting websites to just being allowed to make requests to the same Origin. But sometimes we want to be able to make requests from pages to other Origins, so CORS (Cross-Origin Resource Sharing) lets you configure your server to tell browsers that "You're allowed to make requests to me, even if you're on a different origin".
This is basically the simplified version of the why and how behind CORS.
I think that’s overstating it a bit. JavaScript was introduced in Netscape 2.0 and the SOP was introduced pretty much straight away – Netscape 2.0.2 I believe. Almost 20 years passed and then CORS was created. So while it’s technically true, the timeframe in which JavaScript could make any cross-origin requests was basically the blink of an eye, and for all intents and purposes, the SOP has been around since the beginning and definitely many, many years before Ajax came around.
Before XMLHTTPRequest there was also a time we were doing requests via ActiveX as well, but I did it so briefly I barely remember how it worked by now, and I'm 99% sure this was exclusively in IE as well, maybe IE4 or IE5. I'm not sure if the issue mentioned earlier with cross-origin requests may have been exclusive to IE as well, but I think there was a larger window than "blink of an eye" that it was a issue.
But again, this is all long time ago, and it was in the beginning of my career, I might misremember and you may very well be right.
It’s a mechanism to allow pages to access servers that they can’t by default - with the permission of the server operator.
Cross-Origin Resource Sharing (https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) is one way to relax the Same-Origin Policy, so you essentially whitelist what actually can be shared across Origins. To be used when the default Same-Origin Policy is too strict.
Overall I think it's a really simple concept, but libraries/frameworks/docs seems to constantly over-complicate it with their explanations.
A strong security measure without a reliable way to do the things you want to do induces people to bypass the security altogether.
Security designers generally are ok with this because they consider usability or user behaviour to be not their responsibility.
For example, a POST request with a Content-Type of "text/json" would not be allowed to be sent to third-party hosts without an OPTIONS preflight, but one with a Content-Type of "multipart/form-data" would be allowed and wouldn't be stopped by CORS at all, even to third-party hosts.
(And, of course, if your endpoint just assumes JSON without strictly checking the Content-Type, then congratulations, you've just allowed any website to POST to you, with no user action required.)
Is that so? Neither urlencoded forms nor multipart/form-data are valid JSON on the wire, so while other websites could send requests, wouldn't they just hit a parse error?
Source: I've done that successfully in multiple pentests.
Edit: lazy LLM generated example:
<form action="https://example.com/api" method="POST" enctype="text/plain">
<input name='{"key":"value", "ignore":"' value='"}'>
</form>
{"key":"value", "ignore":"="}
For adhoc dev tools, you could also just disable CORS: https://berkkaraal.com/notes/other/chrome-disable-cors/
Unless I'm misunderstanding the claim, that's not "vulnerable configuration", but extreme lunacy - basically treating parsing outcome as access control. "Did the payload parse correctly as JSON? No -> go away; Yes -> oh that must mean you're supposed to be here". I'm at a loss of words that this is even a problem in practice.
> For adhoc dev tools
There's a whole space between "adhoc" and "dev" tools, though, and this is what interests me the most. Yes, when I'm in full dev mode, I can make my computer do anything I need to. But more often than that, I'm just a user that wants to exercise some basic freedom of computing - to remove some toil or frustration from daily computing experience - without switching my hat from "user" to "developer". That's what CORS has been successfully defeating, by forcing any ad-hoc non-dev tool I could make for myself to require being in "developer mode" to use it.
This case gets more and more complicated with browser defenses such as SameSite cookies or fetch headers you can use to mitigate this case, but let's ignore that for now.
To drive my point home, similar to how ensuring the content-type is set correctly on your JSON endpoint prevents CSRF, it's actually also a very real defense to require a custom header to be set, e.g.
I-Promise-To-Not-Be-Malicious: true
I've seen a web application that did, in fact, check the Content-Type header to make sure that "application/json" was there - but it didn't check that the header value started with that. That meant that setting the header to "multipart/form-data; boundary=application/json" was enough to bypass a CORS preflight!
An attacker might use JavaScript to set a "multipart/form-data" Content-Type (thereby bypassing the otherwise required OPTIONS preflight), but send JSON in the request body. Unless your web application specifically parses the body based on the Content-Type (web servers don't do this for you), then you wouldn't detect that.
(But I was wrong, there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format, as the sibling comment demonstrated)
The browser basically never forces you into a particular format. You don't even need to do the trick with the form stuff that the sibling was talking about. Consider the following JavaScript:
var xhr = new XMLHttpRequest();
var url = "http://localhost:12345/endpoint";
xhr.open("POST", url, true);
xhr.setRequestHeader('Content-Type', 'multipart/form-data');
xhr.send('{"hello":"world"}');
[Edited to illustrate my point better.]
If that's the case, then yes, the forms method would be 'better'.
Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"?
My apps speak only JSON, so one of the first things I do is create a middleware that requires any POST/PUT/PATCH request to be application/json and reject everything else with a 415 error. That's so I can turn off the CSRF protection mechanics in the framework completely, but the two concerns are related.
I guess the same trick might work with urlencoded forms, but it wouldn't work with multipart/form-data
> Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"?
For better or worse, yes, or at least as one layer. That's one of the rationales behind the "safe" requests AFAIK.
And this wouldn't be the first time, protocols are made intentionally incompatible on the wire, so an attacker can't smuggle one inside the other. That's the entire reason for WebSocket's weird handshake dance and the "xor encoding" it applies to messages from the client.
Until now, I wasn't aware of that either. My response is about the fact you can massage the plaintext part to contain valid JSON somehow being a problem, one that apparently is a security issue in practice.
We're not talking about some clever polyglot quine like those COM executables that are somehow also valid Bash and C code and PDF files or something. text/plain is a superset of everything that can be represented by plain text, which includes approximately all code and data formats, JSON and XML included.
> And this wouldn't be the first time, protocols are made intentionally incompatible on the wire, so an attacker can't smuggle one inside the other.
I need to learn more about it, thanks for pointing it out.
Though at the surface, it reads to me like removing a feature. "Smuggling a protocol inside the other" sounds to me like an important feature, or perhaps more accurately, I find myself being part of the "attacker" population much more often than not. "Tunnel $whatever through HTTPS because corporate/ISP firewalls" is both a meme and success story for plenty a SaaS at this point.
Not in the context of web forms.
Just checked the spec and "text/plain" just seems to be an alias for "application/x-www-form-urlencoded" [1] - i.e. stuff that looks like
key=value&anotherkey=anothervalue
Apparently though, keys and values can contain arbitrary characters and arent percent-encoded, so you can do a "quine" where the "key" is
{"foo": "bar", "ignore": "
"}
{"foo": "bar", "ignore": "="}
[1] https://html.spec.whatwg.org/multipage/form-control-infrastr...
It does, though. See my reply at https://news.ycombinator.com/item?id=48618539 .
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.
> 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...).
> 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.
You can't ignore those because they constitute the bulk of CORS' security model.
Yes, you're technically right that CORS cannot prevent other websites from making any request to your server - this would be impossible, since the browser somehow has to get the CORS headers in the first place.
However what CORS absolutely lets you do is prevent requests to particular endpoints - and you can then design your API in such a way that the dangerous actions are only available behind those endpoints and thus make it safe.
I.e. what's missing in the TFA quote is that the server must also change the endpoint from GET to POST (in addition to setting the CORS headers) and remove the GET endpoint. Other websites would still be able to send a GET or a preflight OPTIONS request, but they wouldn't be able to send the actual POST request.
As such, Zoom's workaround had two problems: They didn't set any CORS headers, which prompted the browsers to only allow "safe", i.e. GET requests - and then put an unsafe action behind the endpoint, therefore violating the "safe" assumption. Moral of the story: Don't put actions that do something else than returning a result behind a GET request.
If a browser does not implement CORS protections (but allows cross-origin requests), then its users must have non-standard expectations about security.
> No, that does not do that.
It restricts non-zoom.us domains to CORS-safe operations.
Which sometimes includes making the request, sometimes includes reading the response content or headers.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along and CORS was created to bypass this security. Therefore to do the thing you want to do, you need to enable CORS. No problem, that’s pretty easy.
If you only picked up web development after CORS existed, then you try to make a cross-origin request; the browser understands that it isn’t allowed; the browser tries to do a CORS preflight request; the preflight request fails; and the browser reports a CORS error in the console.
So if you don’t understand what’s going on, don’t RTFM, and just guess, you’re going to guess that CORS is the thing that is blocking the request and that you need to disable CORS. And that leads you directly into a confusing mess because you are trying to do the exact opposite of what you need to do. CORS is the solution to your problem, not the cause of it.
It doesn’t help matters that a whole bunch of people with the same misunderstanding will confidently repeat that misunderstanding in tutorials and online discussions.
Great explanation. The name is quite obvious actually, Cross-Origin Resource Sharing. People should understand if they read it.
While CORS is not intuitive, it is understandable by RTFM.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
""
The article does a nice job giving a concrete example.
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.
Why would that be strange? Someone who is bad at thing A is likely also bab at closely related thing B.
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?
You can keep all the "bad guys" out by putting a brick wall in place of every entrance and window. That will achieve 100% of the security goal, and even ops people might breathe a sigh of relief - until the stakeholders who commissioned the buildings get wind of it, that is.
Beyond that, locks aren't about "keeping bad guys out", but about giving owners a degree of control over who can access what and when. "Keeping bad guys out" is a subset of it, possibly a small one, unless you're happy defining "bad guys" as "people whose goals are at odds with the owner's business model".
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.
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.
The browser enforces the same-origin policy by preventing read on non-mutating (i.e. “simple”) request responses and preventing sending of mutating requests (i.e. non-“simple”). CORS provides a protocol for a service to loosen these controls.
It does block ALL requests for certain content types.
In the common cross origin case of a JSON API, CSRF beyond CORS is unnecessary.
To nitpick, it’s the same origin policy that does that.
Assuming the web client plays nicely. I commonly bypass CORS for playwright unit/E2E testing.
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.
Yes. Especially kids, and by extension, parents of kids. Also teenagers. And people without means. And clever competition. And people with above-average levels of curiosity. And yes, criminals too.
I'd describe it from a different perspective: most people assume their problems are obviously solvable through an available service, and if they aren't, then either they need to delegate it to specialists or the problem itself is invalid. The minority of people who are into solving problems themselves are, at a high level, hard to distinguish from small kids, teenagers, and criminals, because they all share the characteristic of straying from the journey down the sales funnel, as they're pursuing their own goals and are not interested in getting to the bottom of that funnel.
It’s because CORS builds on a very odd base permission model. So if you use multipart form data, okay. But application JavaScript bad.
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?).
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
Exactly what I need. My API is public I just don’t want someone other than my own website to consume it. Is it that hard to understand?
They just want to prevent hotlinking/leeching.
What I still don't understand is what purpose the Access-Control-Allow-Headers header serves. It doesn't seem like it improves security for the browser (and definitely not for the server). Was it included "just for completeness" by the protocol designers? See also https://stackoverflow.com/questions/17992042
If you find CORS difficult to understand, particularly the question of "why do we need this?", I suggest starting here: https://developer.mozilla.org/en-US/docs/Web/Security/Defens...
I've tried using the Same Origin Policy as an interview question in the past, but it's not a good question because the majority of candidates aren't familiar with it, so you learn very little by bringing it up.
For hiring frontend developers, I've found it to be an excellent question, as surely if you've been developing web apps, you essentially must have come across it at some point. If you haven't, I'd be asking more questions about how typically you'd communicate with a backend and so on. Some people have hit the issues related to CORS, worked around it the quickest possible way then forgot all about it, rather than understanding what's going on, also a useful signal for some roles.
Bit less good for backend roles, as not everyone has worked closely with a frontend team which tends to be the people hitting issues around CORS.
There are a few examples of that in this HN thread!
But that's exactly the kind of thing you want to surface in the hiring process with that question :) I guess it depends on if you're hiring juniors to be trained, or seniors to elevate your current team, but personally I'd skip very quickly on people who don't know the basics of their jobs, unless of course the point is to hire them to train them.
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.
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)Ultimately, it almost always depends on the server only being accessed via an untampered browser request.
The Zoom exploit was able to happen because CORS and CSP are so easy to get around on the client side, so Zoom did it. Sure, Zoom were bad/lazy/silly for doing it, but I feel we're bad as a community for still having this model.
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.)
You have to already know from experience that these strange devoid-of-information requests have been blocked by CORS, then find the preflight request, and there you will find a bit more information, but still much less than would be possible to show.
Showing more information would, AFAIK, not circumvent the layer of security that CORS (or actually origin isolation, which CORS makes an exemption from) adds. My best guess is that this just had very low priority when building the dev tools.
> 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).
Developers don't understand CORS - https://news.ycombinator.com/item?id=20404578 - July 2019 (355 comments)
Most of us I think just "expose a set of whitelisted origins and be done with it".
Here is where I landed for how to specify your server's CORS policy:
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.
- 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
I wonder if much of that misunderstanding comes from the threat model being quite unusual and not always easy to understand.
For starters, there are three parties, which all don't trust each other: The server, the browser and the JavaScript running inside the browser.
The browser is supposed to protect the server against requests from unauthorized JavaScript applications. CORS is there to mark certain requests as "authorized", while keeping the protection active for the rest.
But the entire system only works if those three components exist in the first place, as enforcement is solely relying on the browser.
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.
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.
Once you understand that it's onlying to solve problems that happen in a user's compliant browser, and not some wider issue of resource authorisation, it does get a bit easier to understand.
Though in a way CORS seems too simple for what it achieves.
Yes
Count me in!
It's stunning and makes me wonder whether CORS is a bad solution, or if it's solving a hard problem.
- It has a name. That name was allowed to become more recognizable than that of the actual security mechanism (SOP).
- Once you use its name and start thinking of CORS as "the thing", most of DX is about CORS standing between you and perfectly reasonable, legitimate functionality you need to support.
- It does seem to put control in a weird place (backend telling a browser what it is or isn't allowed to do), and people seem to miss that this relies entirely on the browser itself being a compliant party you cannot control.
- I have my own, rather negative, opinions on the whole security model of the browser, that's strongly countercurrent (mostly about how it disenfranchises users), so let's just say here that this is indeed a hard problem being solved - so it doesn't help when people think of an exception policy as a security measure.
If you can run arbitrary code that can connect to other sites and make requests there someone will do that. And those calls can do exactly what they would on site. Only place to control this is the browser. Thus moving this decision to browser. One piece we probably trust way too much.
Live is simple when you directly communicate with one "server"(address) for one thing. Communicate with more. Well you never know if those others intended you to be able to do this.
And then when also all the authentication information lives in the browser too the mess is ready... So whole thing should have been build differently from start.
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 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.
By default such cross-domain requests from JavaScript are disallowed, but CORS allows it if the server specifically opt-in. But the check happen in the browser, since the purpose is to protect the user of the browser.
There are some weird exceptions to this, for example a client can always GET and POST data to another domain under certain constraints, since this have always been possible using HTML forms. So it is not obvious what is possible and what isnt.
Isn't that what CSRF protections are for, not CORS? There are other (very old) ways to trick a user into doing a POST that wouldn't be blocked by CORS -- and as you say, GET and some POST requests can always be sent but you don't see the response.
My understanding is that the actual protection that it gives in this scenario is that the "fungame.com" JavaScript cannot read your friends list or your list of private messages (basically, blocking GET data that should not be shared to random sites, as it would violate user privacy). You still need CSRF protections regardless of CORS.
But cross-domain post is only allowed if the payload is form data encoded. A Json payload from JavaScript would be blocked by default, as would other methods beyond get and post. Therefore you usually don’t have to worry about CSRF for a JavaScript API.
CORS is a a way to enable cross-domain calls from JavaScript without introducing the CSRF issue.
Without the same origin policy CSRF protections would be trivial to circumvent, since you’d be able to read the CSRF token from any page.
Servers certainly can (and probably should) check request origin. But it is not something they usually do, since cross-domain requests from JavaScript wasn’t possible before CORS.
If support for cross-domain request were introduced in browsers without requiring opt-in from servers, most sites would not be prepared against this new risk. It would open massive security issues across the web.
HN is supposed to be full of people who need to know, use and depend on CORS and CSP. We might all just be idiots, but we're the idiots who are supposed to use this tool, and we can't explain it or agree on it.
If a tool can't be used or understood by the primary users, IMO it's by definition a bad tool/solution. It's easy to see why - it's security that depends on a browser, something we're traditionally told never to depend on for security.
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.
https://news.ycombinator.com/item?id=48616086
The whole thread shows that It seems even highly technical people that supposedly know a lot about this shit get it wrong. Because the mechanics are so complex, nobody really knows how they really work. Or it is a freaking mess or chore to achieve something.
Similar to just making a website HTTPS... even with let's encrypt and certbot , why does making a site https have to be so hard? (Try it on a service within a vpn).
Who decided this was a developer's responsibility?
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 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.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Coo...
The server doesn't get to stop the browser making calls that it didn't want, so it's a browser security feature, to stop the browser sending cookies where it shouldn't, or more precisely, to only send authentication and other info where it should.
It relaxes the same origin policy.
Usually a browser will not load resources from another origin based on the HTML it receives. If the page is from example.com, it won't allow you to load a page from example.org.
That stops things like authentication and cookies etc from example.com being transmitted to example.org if someone hacks the webpage.
CORS allows the server to relax those rules so that it can say "You can load resources from me, or from these other servers."
So it can say "I'm example.com but you can load resources from example.org and that's OK."
At least, that's how I think it works :)
If we’d known then how the web is used now then a few things might have been done differently.
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.
Its one of those situations where you need to think like an attacker to see the whole picture.
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.
It's necessary that the defaults are secure. More so, not less, if the problem is hard.
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.
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.
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.
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!
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
This is false. It is meant to protect users from a confused-deputy attack made by malicious websites, where that website makes a request to a "serious" API but the user has never asked for, or approved, that request.
Blaming the user for everything that happens serves nobody.
A CORS header in the response tells your browser to relax CORS restrictions.
At least so long as they don't have malicious extensions or a non-CORS browser?
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."
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).
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.
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
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.
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
"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.
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.
This is usually a sign you don't really understand what you're doing.
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.
That's the thing. If you're logged in to good.com (with a session cookie), then go to evil.com and it has an AJAX call to good.com, it'll carry your cookie. Thus - authentication. Suddenly evil.com can remote control good.com. (at least it used to be this way at the time we got CORS; the situation has changed a bit with newer web platform features like SameSite cookie params.)
> The only freedom I want is being able to wget content no differently than from a terminal.
I see your point, I really do. But the Venn diagram overlap of "sites that need to download arbitrary websites", "sites that need to only fetch content client-side in the browser, not via their backend", and "sites that do this for non-nefarious purposes" is infinitesimally small. I'm pretty sure your use case is missing at least one of these three criteria.
…………………