CORS is not meant to secure an API endpoint • Hacker News Board

Re: CORS is not meant to secure an API endpoint

#41

Post by jrockway » Sun, Feb 13, 2022, 10:48 AM UTC

iancarroll wrote: post #33

goto11 wrote: post #27

Earlier quoted context omitted.

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.

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

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

Re: CORS is not meant to secure an API endpoint

#42

Post by dividuum » Sun, Feb 13, 2022, 10:55 AM UTC

jrockway wrote: post #41

iancarroll wrote: post #33

Earlier quoted context omitted.

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

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 http://localhost:1234/email-debug-info?address=example@examp... ">. CORS doesn't care…

> My browser doesn't care.

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

Re: CORS is not meant to secure an API endpoint

#43

Post by [deleted] » Sun, Feb 13, 2022, 10:57 AM UTC

jrockway wrote: post #41

iancarroll wrote: post #33

Earlier quoted context omitted.

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

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 http://localhost:1234/email-debug-info?address=example@examp... ">. CORS doesn't care…

[deleted]

Re: CORS is not meant to secure an API endpoint

#44

Post by accept-apply » Sun, Feb 13, 2022, 11:04 AM UTC

jrockway wrote: post #41

iancarroll wrote: post #33

Earlier quoted context omitted.

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

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 http://localhost:1234/email-debug-info?address=example@examp... ">. CORS doesn't care…

Isn't this a CSRF issue?

Re: CORS is not meant to secure an API endpoint

#45

Post by JanSt » Sun, Feb 13, 2022, 11:11 AM UTC

pictur wrote: post #38

isn't CORS already technology for browsers? it does not promise anything for situations other than browsers. why is everyone saying it's insecure except for browsers?

Because most people don't understand what CORS is nor what it does. As I said, even the author of the article that is linked does not seem to fully understand it.

Re: CORS is not meant to secure an API endpoint

#46

Post by winwiz » Sun, Feb 13, 2022, 11:13 AM UTC

JimDabell wrote: post #21

> CORS is an implementation in the browser and is designed to protect the user from malicious applications by ensuring that the resource in the browser is only allowed to access specific endpoints. > This browser implementation can be bypassed at any time. First, it is up to the browser itself: if CORS is not integrated, or not integrated cleanly, then it will not work. > An attacker can access the API key via the so…

I agree, the author doesn't seem to grasp the fact that CORS always waters down security. That is, CORS is the way of security weakening. Although the author correctly notes that only browsers respect CORS, there is no mention that this happens because CORS relaxes security built into browsers.

Re: CORS is not meant to secure an API endpoint

#47

Post by goto11 » Sun, Feb 13, 2022, 11:22 AM UTC

JanSt wrote: post #15

goto11 wrote: post #9

CORS is confusing to understand because the kind of attack it protects against is confusing. CORS does not protect endpoints against malicious clients, since you can always just make the same request outside of a browser. And it doesn't protect any site from making or receiving cross-site requests, since CORS can always be disabled on the server side. CORS protect against the scenario where a malicious site tricks an…

Again, CORS does not protect, the SOP does :-)

You can consider CORS a relaxation on top of SOP (same-origin policy), since CORS allows you to opt-in to certain cross-site requests which are not allowed under SOP. Then again, SOP allows certain requests like 'PUT' and 'DELETE' requests back to the origin server which was not allowed before SOP, so in that sense SOP is also a relaxation.

Bit it is a good point that CORS enables more forms of cross-site requests than what is allowed under the same-origin policy. But the requests are enabled under certain confusing restrictions which is better understood if you understand the scenarios they are designed to protect against.

Re: CORS is not meant to secure an API endpoint

#48

Post by hoppla » Sun, Feb 13, 2022, 11:26 AM UTC

iancarroll wrote: post #33

goto11 wrote: post #27

Earlier quoted context omitted.

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.

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

Form Posts are limited to few content types, and application/json is not one of them. I have however found some CSRFs against POST endpoints that did not care that the request was text/plain

Re: CORS is not meant to secure an API endpoint

#49

Post by JanSt » Sun, Feb 13, 2022, 11:28 AM UTC

jrockway wrote: post #41

iancarroll wrote: post #33

Earlier quoted context omitted.

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

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 http://localhost:1234/email-debug-info?address=example@examp... ">. CORS doesn't care…

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

Re: CORS is not meant to secure an API endpoint

#50

Post by djm_ » Sun, Feb 13, 2022, 11:29 AM UTC

JimDabell wrote: post #21

> CORS is an implementation in the browser and is designed to protect the user from malicious applications by ensuring that the resource in the browser is only allowed to access specific endpoints. > This browser implementation can be bypassed at any time. First, it is up to the browser itself: if CORS is not integrated, or not integrated cleanly, then it will not work. > An attacker can access the API key via the so…

From experience, I can tell you that many people simply refer to this entire domain as CORS despite that S standing for Sharing. The Same Origin Policy is treated verbally more like the default state of CORS in some circles.

It is very confusing and I’m not entirely sure how it ended up like that.