Hacker News

I don't understand why this is the most upvoted comment. OP is right, and you are wrong.

> 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.

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?

My understanding was that "preventing otherwise disallowed HTTP requests" was the entire point of the preflight OPTIONS request, and that CORS will do nothing if the request would otherwise be allowed.

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.)

> 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.

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.

> (ignoring preflight requests for now and assuming we're talking just about "safe" Methods)

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.

Importantly it only prevents clients that actually cares about the cors headers. Like ohh I'm from hacker.org and the http headers says it only allows zoom.us ohh nooooo. Like it's just a http header! Now if you use a mainstream browsers and you accidentally visits hacker.org in a iframe at some shady site - then the cors header will prevent your browser from accessing it.

“Can still talk to, but cant read the response” is a bit too simplied. You can’t post a json payload for example, which is how a JavaScript client would usually talk to a backend. You can only post using form data encoding, since this is already possible using a plain html form without any JavaScript. Anything beyound that, like json/xml payloads or methods other than post and get are blocked by default.

>> This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.

> 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.

Exactly this. I can only upvote you once, but this is one article that should answer all the questions. Not just the simple origin case, but also how a preflight works.

I think perhaps it’s generational.

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.

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).

Depressing.

While CORS is not intuitive, it is understandable by RTFM.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...

Guidelines say to edit out swipes, so your comment can be edited to just:

""

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.

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.

> Many (most?) developers don't really understand the threat model.

It’s because CORS builds on a very odd base permission model. So if you use multipart form data, okay. But application JavaScript bad.

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?).

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'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.

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 love this, easy intuitive explanation

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

I feel the same. Unfortunately, I've had to deal with CORS in a few situations where the request is "we need to get this thing from this server, but we can't change the servers CORS or CSP", which, in technical security speak is "we have this security system in place, we need to circumvent it".

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.

> 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 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.

Nah the clowns at standard board just decide to fuck shit up every few years and add some new mess to CORS that breaks in some subtle edge case on existing setup

It really is architecture dependent. There are many valid reasons why would not want to route all API requests through your frontend infra, or vice-versa.

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.

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...

CORS relaxes the rules about what requests the browser can make.

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 :)

Your cookies are sent.

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.

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.

That describes pretty much every server I've ever written lol.

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.

> 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!

> it’s meant to protect the users from themselves

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.

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.

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?

the browser security model is quite efficient and heavily tested tho.

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.

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.

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

> 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.

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?