CORS is not meant to secure an API endpoint

Re:CORS is not meant to secure an API endpoint by jrockway on Sunday February 13, 2022 @05:48AM (#30320831)

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 protected] 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@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 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.

[ Parent | on HN ]

Re:CORS is not meant to secure an API endpoint by dividuum on Sunday February 13, 2022 @05:55AM (#30320849)

> My browser doesn't care.

It soon will https://web.dev/cors-rfc1918-feedback/

[ Parent | on HN ]

Re:CORS is not meant to secure an API endpoint by JanSt on Sunday February 13, 2022 @06:28AM (#30320983)

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

[ Parent | on HN ]

Re:CORS is not meant to secure an API endpoint by Mavvie on Sunday February 13, 2022 @10:52AM (#30322542)

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.

[ Parent | on HN ]

Re:CORS is not meant to secure an API endpoint by accept-apply on Sunday February 13, 2022 @06:04AM (#30320888)

Isn't this a CSRF issue?

[ Parent | on HN ]