Imagine that your banking website used a standard JSON+REST API with cookie based authentication to trigger & validate a transaction request.
When a request to `fetch` or XMLHTTPRequest is made from ANY site, the browser will still populate cookies for 3rd party sites.
So without CORS, then someone might be able to create a landing page, which in the background triggers a `fetch` or `ajax` request to your bank's transaction endpoint. For 99.999% of people this wouldn't be effective because they are probably not a customer of this bank and are not logged in at the time of the request. But for some very tiny fraction of users, the browser would be tricked into populating the Cookie header from a previously created session in a different tab and would send this request.
The Origin header in the CORS preflight is a signal from the server to the browser that 'yes, this request is safe for you to construct'. This way the browser doesn't let the malicious web page "trick it" in the first place to send the bad request.
I think this is the problem here? Just send the request without cookies if CORS doesn't allow it.
(I also think third-party cookies were a mistake in general, and it would be a good thing if they were removed. There were some plans but well, Google.)
Yup, very obviously a problem and it's why we got CORS :) But just because it's a problem, doesn't mean we can remove it from all browsers and call it a day, it'll break huge parts of the internet.
So in true internet engineering fashion we do what we always do, pile yet another layer on top of the stack to fix some issues from the previous layer (and add some more complications for the next (future) layer).
The problem is how will the browser know whether CORS would allow it or not? It could send a preflight, yes. In the current rules that's only done for complex requests, not simple requests. You seem to be suggesting preflights be sent for all requests. That would balloon the number of requests, adding RTTs, slowing down page loads.
E.g. if example.com embeds an image from imgur.com and the browser happens to have a cookie in the imgur.com cookie jar, should the browser send a preflight request first to decide whether to attach cookies to the request or not? That preflight would slow down the page load. In the current rules, the cookies are simply attached, with no preflight required for that type (simple) of request.
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
By the way, the default fetch `credentials` value ("same-origin") doesn't send cookies to third-party websites either. Why CORS still applies here is a mystery to me.
Edit: some requests can work without preflight, but there are some absurd limitations (GET/POST only, and request body can't be a JSON): https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...
And to clarify, my point here is: I think CORS is a security theater. The only part that really helps is Access-Control-Allow-Credentials (and that's only because third-party cookies are still a thing).
There are other types of authentication besides cookies. E.g. TLS client certs. Does the browser not send a TLS client cert for fetch requests that don't send credentials? In some cases that could double the number of TLS sockets: one socket with a client cert and one socket without a client cert.
Another type of authentication is sites that only allow requests from certain source IP ranges. Or similarly, services run on a local LAN that aren't exposed to the public internet (e.g. a router's admin panel that's only accessible to devices on the LAN) or a service running locally on your machine serving on localhost. Someone might want to run a service locally and allow foo.com to make requests to it and read their responses, but block evil.com from making requests to it and reading the responses. And there might be no cookies involved with that local service, because it's running locally on the user's machine and thus doesn't need cookies to know who the user is. Of course we also need to consider DNS rebinding attacks. Those can be protected by Host header checks or Origin header checks, but Origin header checks only work for requests that send an Origin header, which aren't all requests.
>I think CORS is a security theater.
The same origin policy and CORS have 2 aspects:
1. Preventing evil.com from reading the content of email.com . I don't think this is security theater. This is very useful for security and doesn't have a bunch of confusing caveats. CORS headers can be used to allow good.com to read the content of email.com if email.com wants to allow that. That's useful for certain functionality.
2. Preventing evil.com from sending certain types of requests to email.com . This has a bunch of confusing caveats about which type of requests are allowed and which types are blocked. So this isn't super useful. However I don't think I'd call it security theater. Here's how I think this restriction was created: As browsers added more and more ways to send requests, they wanted to avoid introducing vulnerabilities to websites that were created in the past before those types of requests could be sent and that relied for security on the assumption that those types of requests couldn't be sent. So the browsers implemented preflights to make sure that these new types of requests they were creating wouldn't introduce vulnerabilities to old websites.
I think it doesn't. From MDN: “Credentials are cookies, TLS client certificates, or authentication headers containing a username and password.”
> Another type of authentication is sites that only allow requests from certain source IP ranges.
This one can be tricky, yeah. Ideally such devices would check Origin header, but that ship has sailed I guess.
---
But I think it should be pretty safe to allow cross-origin requests that:
- don't use credentials and
- don't go to a private network.
This means that evil.com can GET https://email.com/ without CORS, but the response won't be personalized to user (so they can read the landing page but not your messages). They can also POST https://email.com/api/send, but that wouldn't do anything as again we don't include credentials.
good.com will send a request with credentials and in this case CORS should be checked indeed.
If evil.com tries to POST https://192.168.0.1/reboot we require CORS too since it's in a private net. If evil.com tries to GET https://192.168.0.1/config we don't send preflight but check CORS headers on the response before allowing to read it.
If your site is on public net and you authorize users solely by IP – that's on you.
Are you talking about an attack where the attacker tries to control the victim's bank account by initiating a transfer? That's a CSRF attack. CORS and the same origin policy don't prevent that attack by default. The browser will still send the request the request populating the cookie. The same origin policy will prevent the evil site from reading the response, not from making the request. To protect against this attack the bank needs to implement CSRF protection (e.g. checking the Origin header).
You could say that sites instead must prescribe a "send-cookies-when-requests-are-from-this-site" header, but that's kind of the same thing as CORS.
It was tedious.
CORS and the same origin policy don't protect against CSRF attacks by default, at least if we're using the standard definition of CSRF attacks.
An attacker can still "send emails on your behalf by making direct requests to your email provider's" HTTP API even with CORS and the same origin policy in their default settings, as long as your email provider doesn't implement CSRF protection (e.g. anti-CSRF token or Origin header checks). That's why all state-changing HTTP handlers need to implement CSRF protection.
For example you can make a cross origin GET with an img tag, and a cross-origin POST with a form tag and some JavaScript.
A few months later he calls his CO and asks to be sent back to the front.
The CO asks "why would you want to do that?"
He replies, "there's a lot less fear over there."
It feels like that the only mode of use of a computer that's allowed by security-minded folks is being a company selling shit on-line, or a customer of one. Try anything like making a simple browser UI to use some internal API, even on localhost, and you quickly end up running your own certificate authority, CORS proxy and having to buy a domain.
I mean, the very concept that the only right way to do HTTPS for internal tools is to have a public certificate on a public Internet domain, thus having to pay third parties and leaking information via certificate transparency logs, is insane when you're just doing your own stuff on your own LAN, and need to use a browser (entirely locally) or touch anything on the Internet.
That's wrong. Any website can make a request to any other website. The same origin policy will prevent READING the response, not making the request. This is to prevent evil.com from making a request to email.com and reading all your emails.
CORS was invented as a way to partially disable the same origin policy for websites that want to allow their responses to be read by other sites. Note that CORS is a way to disable blocking. Most people think CORS blocks things, but that's a misconception. The same origin policy blocks things, and CORS can partially disable it. CORS = Cross Origin Resource Sharing. The Sharing refers to how it disables blocking.
(This is a slight simplification, because I'm ignoring complex CORS.)
The canonical issue that CORS solves is:
1. I log into my bank. 2. I load an untrusted site. 3. That site does `POST https://mybank.example/transfer` to transfer my money to them.
This works because of the braindead decision to include the cookies obtained in step 1 in the request made in step 3.
But to avoid breaking the web they had to do this "gently". So they did the following:
1. Add the Origin: header so that sites could check for this problem. (opt-in protection) 2. Add CORS for as much as they could without breaking too many existing sites (opt-out protection).
If you are designing a site what you probably want to do is check the Origin header and just set `Access-Control-Allow-Origin: *` (which is better than mirroring the origin as it blocks automatically-added credentials like cookies).
This doesn't fully solve the problem due to the legacy compatibility carve-out in 2 (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...). But was unfortunately necessary to help hotfix existing sites that were vulnerable while avoiding breaking too much (in which case it would never ship). Notably this carve-out includes HTML <form> POSTs! So if you use regular HTML forms on your site you still need to opt-in to proper protection.
These days most browser partition cookies by top-level origin anyways, so CORS is mostly obsolete. But you can't rely on that.
People will often tell you that CORS is about controlling which origins can see your content. That is mostly false. Because you can easily run a CORS proxy to access any publicly available content. What CORS does is simply prevent implicitly added authentication such as cookies and basic auth from being sent cross-domain by default (except for the carve out)
The canonical example you give for something CORS and the same origin policy protect against isn't even protected against by default (as you mention), because it requires additional opt-in protection from mybank.example . Why not use a canonical example that is protected against by default? Like evil.com reading all my emails by making a request to email.com ?
You describe CORS as blocking things. I think it's the same origin policy that blocks things, and CORS (Cross Origin Resource Sharing) unblocks things ("sharing"=unblocking).
> Why not use a canonical example that is protected against by default?
I think demonstrating how full of holes the default policy is is a great way to emphasis that you should not rely on the default protections. It is a huge hack and you should put into place proper protections if your site uses any form of implicit credentials.
> You describe CORS as blocking things. I think it's the same origin policy that blocks things
CORS and the same origin policy are the same thing, two sides of the same coin. They express what is allow and what isn't. CORS is a configuration layer for the same origin policy, allowing you to change the default policy.
Only if the server checks that the Content-Type header is JSON. If the server ignores the Content-Type header and simply decodes it as JSON, it's not protected. I think there are probably a lot of servers that simply decode the body as JSON without first checking the Content-Type header and thus the same origin policy doesn't protect them from CSRF.
>The point is still that this is the target problem that it is trying to address.
It doesn't seem that way to me. The same origin policy successfully prevents one website from reading the content of another website. It's fully addressed. It seems to me that's the primary problem it's trying to address. The problem of one website sending requests to another website is only partially addressed, so it seems to me that's considered a secondary problem.
>I think demonstrating how full of holes the default policy is is a great way to emphasis that you should not rely on the default protections.
The default policy is full of holes for sending requests, but not for reading the response. I agree you shouldn't rely on the default protections for sending requests, and should implement your own CSRF protection for all state-changing handlers. But I think it's fine to rely on the default protection for reading responses, and thus I don't think it's necessary to recommend CSRF protection for non-state-changing handlers.
The reason I always first describe the same origin policy and CORS in terms of reading responses is that I think it leads to less confusion. If I first explain about sending requests, I have to explain that it doesn't really work, and people thus are confused about what the purpose of the same origin policy and CORS is if it doesn't even protect against the thing it was designed to protect against. Either that or they mistakenly think it does protect against sending requests, and implement sites with CSRF vulnerabilities erroneously thinking the same origin policy and CORS will protect them. By explaining first about reading responses, people quickly understand that. I then explain that it doesn't protect against sending requests, and thus state-changing handlers need CSRF protection to be implemented.
>CORS and the same origin policy are the same thing, two sides of the same coin. They express what is allow and what isn't. CORS is a configuration layer for the same origin policy, allowing you to change the default policy.
I guess I can see that, but the names of them don't really lend themselves to that understanding. The same origin policy is about same origins. If it starts allowing cross-origin communication, then it's no longer living up to its name. So I see that as it being disabled. Similarly CORS is about cross-origin sharing. If it starts blocking things, then it's not doing sharing, and thus not living up to its name.
According to Wikipedia the history backs up my understanding. It says the same origin policy was created in 1995, and CORS came later, first proposed in 2004.
If you work somewhere with a network access based intranet you might have eg a private wiki at https://wiki.internal-corp/
Without CORS, anyone from your company visiting a malicious external website could have data stolen from that “private” intranet site using fetch()