3 ms·

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 wo

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...
Mavvie 5y ago
As mentioned, CORS isn't designed to protect against requests where the response isn't read by another origin's JS. Even with fetch I think you could "bypass" CORS to the same extent as this example by passing the "no-cors" mode. This is just a CSRF issue, which is well understood and easily fixed with a CSRF/authenticity token. Also, GET requests should not have side effects like sending an email. A reasonable default seen in some frameworks is GET requests have no side effects and don't require CSRF tokens, while all other verbs do.

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

Mavvie 5y ago

As mentioned, CORS isn't designed to protect against requests where the response isn't read by another origin's JS. Even with fetch I think you could "bypass" CORS to the same extent as this example by passing the "no-cors" mode. This is just a CSRF issue, which is well understood and easily fixed with a CSRF/authenticity token. Also, GET requests should not have side effects like sending an email. A reasonable default seen in some frameworks is GET requests have no side effects and don't require CSRF tokens, while all other verbs do.