3 ms·

It is more complex than that, because certain kinds of cross-site requests has always been allowed. GET and POST requests are allowed, but PUT and DELETE is not

by goto11 5y ago

It is more complex than that, because certain kinds of cross-site requests has always been allowed. GET and POST requests are allowed, but PUT and DELETE is not. For POST requests you can send the request but not access the result. So CORS can be used to increase protection, by disabling cross-site POST requests, but it can also be used to decrease protection for other requests.

JanSt 5y ago
The request does not send resource/cookie data if CORS does not explicitly relax the SOP. CORS does not protect!
- goto11 5y ago
  A cross-origin POST request can be initiated using a HTML form and does send cookies. CORS provides a safer alternative.
  - aobdev 5y ago
    Can you elaborate on how CORS provides an alternative? Responding with a CORS policy to your own client’s preflight requests is not going to do anything for a malicious client’s form POST.
iancarroll 5y ago
This isn't fully accurate -- you can never prevent cross-site POST requests from being initiated, with or without CORS. For example, CORS is never involved in requests from <form> submissions (which can be triggered via JavaScript). Really CORS cannot be used to lock anything down. The behavior of a server not implementing CORS has the same end result as a server trying to be as restrictive as possible. Both would not send any CORS headers in responses and would simply ignore pre-flight requests.
- jrockway 5y ago
  Yup. CORS has so many loopholes that you should pretend like it doesn't exist. My favorite is... imagine I routinely port-forward an app's debug port to my workstation for debugging. It has a useful /email-debug-info?address=example@example.com endpoint. You can then call that over the Internet by serving me a web page that contains <img src="http://localhost:1234/email-debug-info?address=example@example.com http://localhost:1234/email-debug-info?address=example@examp...">. CORS doesn't care. My browser doesn't care. It will just silently leak information. (Also great for other things on your network. Log into your router at 192.168.1.1 recently? Someone can make a web page with a form that submits to http://192.168.1.1/enable-port-forwarding http://192.168.1.1/enable-port-forwarding or whatever, and you can forward whatever ports you want.) What's hilarious to me is that CORS seems burdensome in the opposite direction too. It breaks peoples applications somehow! While writing this comment, I did a search to see if I could remember the standards-track proposal for fixing the two "bugs" I mention above... but all the search results are people asking how to disable CORS rules because their app is broken. Sigh! The web is a mess.
  - dividuum 5y ago
    > My browser doesn't care. It soon will https://web.dev/cors-rfc1918-feedback/ https://web.dev/cors-rfc1918-feedback/
  - deleted 5y ago
    [deleted]
  - accept-apply 5y ago
    Isn't this a CSRF issue?
  - JanSt 5y ago
    Apart from the misunderstanding that CORS protects you, you are describing two scenarios. I don't really understand the first one or why you think SOP should protect you in that case. Could you restate that problem? The second one is a CSRF issue, as noted by another user. The third thing you describe is not people who disable CORS but actually use CORS to the max (usally things like Access-Control-Allow-Origin: *), because they don't understand what it does. It's a huge problem...
masklinn 5y ago
> It is more complex than that, because certain kinds of cross-site requests has always been allowed. GET and POST requests are allowed Request headers and body content-type are also a factor for POST, anything which couldn't be set through a FORM is forbidden. The most common issue is that the request is only simple if its content-type is `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain`. JSON POST requests usually run afoul that. The second big issue is setting bespoke headers as only Accept, Accept-Language, Content-Language, and Content-Type (restricted to the above list) are simple. There common sticking points are headers like Authorization.

by goto11 5y ago

JanSt 5y ago

The request does not send resource/cookie data if CORS does not explicitly relax the SOP. CORS does not protect!

goto11 5y ago
A cross-origin POST request can be initiated using a HTML form and does send cookies. CORS provides a safer alternative.
- aobdev 5y ago
  Can you elaborate on how CORS provides an alternative? Responding with a CORS policy to your own client’s preflight requests is not going to do anything for a malicious client’s form POST.

iancarroll 5y ago

This isn't fully accurate -- you can never prevent cross-site POST requests from being initiated, with or without CORS. For example, CORS is never involved in requests from <form> submissions (which can be triggered via JavaScript). Really CORS cannot be used to lock anything down. The behavior of a server not implementing CORS has the same end result as a server trying to be as restrictive as possible. Both would not send any CORS headers in responses and would simply ignore pre-flight requests.

jrockway 5y ago
Yup. CORS has so many loopholes that you should pretend like it doesn't exist. My favorite is... imagine I routinely port-forward an app's debug port to my workstation for debugging. It has a useful /email-debug-info?address=example@example.com endpoint. You can then call that over the Internet by serving me a web page that contains <img src="http://localhost:1234/email-debug-info?address=example@example.com http://localhost:1234/email-debug-info?address=example@examp...">. CORS doesn't care. My browser doesn't care. It will just silently leak information. (Also great for other things on your network. Log into your router at 192.168.1.1 recently? Someone can make a web page with a form that submits to http://192.168.1.1/enable-port-forwarding http://192.168.1.1/enable-port-forwarding or whatever, and you can forward whatever ports you want.) What's hilarious to me is that CORS seems burdensome in the opposite direction too. It breaks peoples applications somehow! While writing this comment, I did a search to see if I could remember the standards-track proposal for fixing the two "bugs" I mention above... but all the search results are people asking how to disable CORS rules because their app is broken. Sigh! The web is a mess.
- dividuum 5y ago
  > My browser doesn't care. It soon will https://web.dev/cors-rfc1918-feedback/ https://web.dev/cors-rfc1918-feedback/
- deleted 5y ago
  [deleted]
- accept-apply 5y ago
  Isn't this a CSRF issue?
- JanSt 5y ago
  Apart from the misunderstanding that CORS protects you, you are describing two scenarios. I don't really understand the first one or why you think SOP should protect you in that case. Could you restate that problem? The second one is a CSRF issue, as noted by another user. The third thing you describe is not people who disable CORS but actually use CORS to the max (usally things like Access-Control-Allow-Origin: *), because they don't understand what it does. It's a huge problem...

masklinn 5y ago

> It is more complex than that, because certain kinds of cross-site requests has always been allowed. GET and POST requests are allowed Request headers and body content-type are also a factor for POST, anything which couldn't be set through a FORM is forbidden. The most common issue is that the request is only simple if its content-type is `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain`. JSON POST requests usually run afoul that. The second big issue is setting bespoke headers as only Accept, Accept-Language, Content-Language, and Content-Type (restricted to the above list) are simple. There common sticking points are headers like Authorization.