6 ms·

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 ba

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

Thorrez 2y ago
>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. 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).
treve 2y ago
This is mostly correct, but one thing that's worth pointing out is that CORS doesn't protect anything, but it 'loosens' the protection that the browser has by default. The S in CORS stands for sharing, not security.
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.)
- Thorrez 2y ago
  >Just send the request without cookies if CORS doesn't allow it. 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.
  - notpushkin 2y ago
    Simple requests could still work without preflight. What I suggest is, complex requests (e.g. fetch()) that don't require cookies (e. g. using credentials: "omit" [1]) shouldn't preflight either. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#including_credentials 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#simple_requests 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).

Thorrez 2y ago

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

treve 2y ago

This is mostly correct, but one thing that's worth pointing out is that CORS doesn't protect anything, but it 'loosens' the protection that the browser has by default. The S in CORS stands for sharing, not security.

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

Thorrez 2y ago
>Just send the request without cookies if CORS doesn't allow it. 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.
- notpushkin 2y ago
  Simple requests could still work without preflight. What I suggest is, complex requests (e.g. fetch()) that don't require cookies (e. g. using credentials: "omit" [1]) shouldn't preflight either. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#including_credentials 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#simple_requests 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).