4 ms·

Web security noob here. Why does CORS even exist? The fact that a website can’t make a request to another website unless that domain likes it is kind of insane

Web security noob here. Why does CORS even exist? The fact that a website can’t make a request to another website unless that domain likes it is kind of insane to me. Everyone in the comments here is going on about how maybe the user’s API key gets leaked by a malicious application or whatever but, like, when I write software that isn’t in the browser I can just send a request to anyone without restrictions and as far as I can tell the world has not ended. Why is the browser any different?

barrkel 2y ago
CORS - or specifically, not permitting cross-origin requests by default - is for preventing CSRF, cross-site request forgery. In particular if the user's credentials (cookies) are passed along with a request to a third party site, then the first party site can act as the user with the user's authority. In other words, evil.com could e.g. send emails on your behalf by making direct requests to your email provider's web interface.
- saagarjha 2y ago
  Ok but like why would you pass cookies along
  - easton 2y ago
    Because in the 90s/early 2000s someone thought it was a good idea to send cookies for the given site along with all requests (probably a good move, since it would stink to have to tell the browser somehow to explicitly send a cookie for every request, even ones initiated outside of JS). 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.
    - joquarky 2y ago
      We used to rewrite the session ID into all link href and form action URLs for browsers that didn't enable/support cookies. If any link or form did not contain the SID, the app broke. It was tedious.
  - dceddia 2y ago
    Just to add to the sibling comment - you don’t get a choice to pass cookies or not, the browser just includes them automatically.
- Thorrez 2y ago
  That's not really correct. 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.
tommica 2y ago
Simple, if you have an iframe pointing to http://foo.test/deletesite.php http://foo.test/deletesite.php, without cors that request will be done, with cookies and everything, without the user being aware of it.
- EE84M3i 2y ago
  AFAIKR you don't need CORS for framing, or making cross origin GET or POST. You only need it to read the response of a cross origin request and setting certain request header and body etc. 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.
  - Thorrez 2y ago
    You're correct.
- Thorrez 2y ago
  That attack you mention is a CSRF attack. CORS doesn't really protect against that. That exact attack you mention is possible if foo.test doesn't implement CSRF protection. CORS doesn't automatically provide CSRF protection.
eejjjj82 2y ago
CORS is designed to protect the server data. It's a tool that gives servers a control mechanism to tell browsers "who can access my data". 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. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
- notpushkin 2y ago
  > When a request to `fetch` or XMLHTTPRequest is made from ANY site, the browser will still populate cookies for 3rd party sites. 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.)
  - diggan 2y ago
    > I think this is the problem here? Just send the request without cookies if CORS doesn't allow it. 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).
  - 2y ago
BrandoElFollito 2y ago
There is a good explanation here: https://stackoverflow.com/a/29167709/903011 https://stackoverflow.com/a/29167709/903011
breck 2y ago
A soldier gets back from the front and gets a job in IT moderating internet comments. 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."
- TeMPOraL 2y ago
  You get downvoted, but that's pretty much spot on. I've wasted many days of my life trying to navigate around security in the browser and HTTPS everything, mostly unsuccessfully, and I only see increasingly insane lock-downs appearing as time goes on. 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.
Thorrez 2y ago
>The fact that a website can’t make a request to another website unless that domain like it 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.)
kevincox 2y ago
CORS is basically a backwards compatible hack to "fix" the bug that cookies are sent on third party requests by default. 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 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#simple_requests 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)
- Thorrez 2y ago
  I agree with how you describe the behavior, but the terminology you use differs from how I understand things. 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).
simonw 2y ago
Lots of replies here talking about cookies and CSRF, but a bigger concern in my opinion is intranets. If you work somewhere with a network access based intranet you might have eg a private wiki at https://wiki.internal-corp/ 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()
apitman 2y ago
CORS exists to keep us humble. The first time you think you understand it, your journey has only just begun.
thiht 2y ago
There are always some mild arguments that CORS is better that nothing, but honestly your intuition is right, CORS is absolute nonsense.

barrkel 2y ago

CORS - or specifically, not permitting cross-origin requests by default - is for preventing CSRF, cross-site request forgery. In particular if the user's credentials (cookies) are passed along with a request to a third party site, then the first party site can act as the user with the user's authority. In other words, evil.com could e.g. send emails on your behalf by making direct requests to your email provider's web interface.

saagarjha 2y ago
Ok but like why would you pass cookies along
- easton 2y ago
  Because in the 90s/early 2000s someone thought it was a good idea to send cookies for the given site along with all requests (probably a good move, since it would stink to have to tell the browser somehow to explicitly send a cookie for every request, even ones initiated outside of JS). 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.
  - joquarky 2y ago
    We used to rewrite the session ID into all link href and form action URLs for browsers that didn't enable/support cookies. If any link or form did not contain the SID, the app broke. It was tedious.
- dceddia 2y ago
  Just to add to the sibling comment - you don’t get a choice to pass cookies or not, the browser just includes them automatically.
Thorrez 2y ago
That's not really correct. 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.

tommica 2y ago

Simple, if you have an iframe pointing to http://foo.test/deletesite.php http://foo.test/deletesite.php, without cors that request will be done, with cookies and everything, without the user being aware of it.

EE84M3i 2y ago
AFAIKR you don't need CORS for framing, or making cross origin GET or POST. You only need it to read the response of a cross origin request and setting certain request header and body etc. 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.
- Thorrez 2y ago
  You're correct.
Thorrez 2y ago
That attack you mention is a CSRF attack. CORS doesn't really protect against that. That exact attack you mention is possible if foo.test doesn't implement CSRF protection. CORS doesn't automatically provide CSRF protection.

eejjjj82 2y ago

CORS is designed to protect the server data. It's a tool that gives servers a control mechanism to tell browsers "who can access my data". 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. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

notpushkin 2y ago
> When a request to `fetch` or XMLHTTPRequest is made from ANY site, the browser will still populate cookies for 3rd party sites. 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.)
- diggan 2y ago
  > I think this is the problem here? Just send the request without cookies if CORS doesn't allow it. 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).
- 2y ago

BrandoElFollito 2y ago

There is a good explanation here: https://stackoverflow.com/a/29167709/903011 https://stackoverflow.com/a/29167709/903011

breck 2y ago

A soldier gets back from the front and gets a job in IT moderating internet comments. 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."

TeMPOraL 2y ago
You get downvoted, but that's pretty much spot on. I've wasted many days of my life trying to navigate around security in the browser and HTTPS everything, mostly unsuccessfully, and I only see increasingly insane lock-downs appearing as time goes on. 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.

Thorrez 2y ago

>The fact that a website can’t make a request to another website unless that domain like it 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.)

kevincox 2y ago

CORS is basically a backwards compatible hack to "fix" the bug that cookies are sent on third party requests by default. 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 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#simple_requests 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)

Thorrez 2y ago
I agree with how you describe the behavior, but the terminology you use differs from how I understand things. 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).

simonw 2y ago

Lots of replies here talking about cookies and CSRF, but a bigger concern in my opinion is intranets. If you work somewhere with a network access based intranet you might have eg a private wiki at https://wiki.internal-corp/ 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()

apitman 2y ago

CORS exists to keep us humble. The first time you think you understand it, your journey has only just begun.

thiht 2y ago

There are always some mild arguments that CORS is better that nothing, but honestly your intuition is right, CORS is absolute nonsense.