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

Re: CORS is not meant to secure an API endpoint

#121

Post by blurker » Sun, Feb 13, 2022, 5:54 PM UTC

hn_throwaway_99 wrote: post #91

fivea wrote: post #64

Earlier quoted context omitted.

> CORS does not protect anything from anyone. The same-origin policy stops code from one site reading resources from another site. CORS selectively removes that protection – it decreases security. This comment comes off as either disingenuous or needlessly contrarian, and in the process tries to make points that fall somewhere between completely wrong and miopic. Your personal assertion that CORS somehow decreases se…

> This comment comes off as either disingenuous or needlessly contrarian, and in the process tries to make points that fall somewhere between completely wrong and miopic. Bluntly, your response is the one coming off as needlessly argumentative, and the parent comment made plenty of sense to me. I don't think it's disingenuous to clearly explain the difference between the Same-Origin Policy and CORS, and to emphasize…

Actually, I agree with OP. Grandparent's phrasing:

> All of this is completely wrong.

Is not only needlessly argumentative but also wrong itself. The 3rd point they include as "completely wrong" is not wrong, and they end up just rephrasing it later in their correction.

Re: CORS is not meant to secure an API endpoint

#122

Post by unclebucknasty » Sun, Feb 13, 2022, 5:59 PM UTC

pshc wrote: post #104

hn_throwaway_99 wrote: post #91

Earlier quoted context omitted.

> This comment comes off as either disingenuous or needlessly contrarian, and in the process tries to make points that fall somewhere between completely wrong and miopic. Bluntly, your response is the one coming off as needlessly argumentative, and the parent comment made plenty of sense to me. I don't think it's disingenuous to clearly explain the difference between the Same-Origin Policy and CORS, and to emphasize…

Regardless of their tone, fivea is correct to point this out as myopic. The grandparent comment argues about semantics and provides information that is technically correct, but not in a useful sense. To say that "CORS decreases security" because it opens up cross origin communication is perhaps not disingenuous (who can say?) but certainly misleading. All browser users would be worse off without CORS. I think we are…

>All browser users would be worse off without CORS.

You and fivea are conflating functionality with security.

Yes, it may be functionally desirable for an app to allow cross-origin requests, as enabled by CORS. But, you're granting permissions, and that is opening things up, possibly making them less secure.

I think great-grandparent's point highlighting this is worth making, given that there is so much confusion around CORS.

Re: CORS is not meant to secure an API endpoint

#123

Post by blurker » Sun, Feb 13, 2022, 6:01 PM UTC

hsbauauvhabzb wrote: post #57

Why the hell does CORS only support exactly one origin domain or wildcard? Such a silly decision to not allow comma separated values or wildcard subdomains.

I get why you think it's silly. I'm pretty sure I thought that too when I first encountered it. But I think it makes sense and there is actually a way to support more than one but not wildcard. Multiple origin domains are supported by using the pre-flight request to change the one domain returned based on what is in the pre-flight request.

I don't know what the actual reason was, but I would guess the design decision was made so the multiple domains use case would be infinitely scalable. Otherwise you would run into header length limitations. Imagine trying to fit 10,000 domains into the header! Eventually you'd need something like this implementation anyways.

Re: CORS is not meant to secure an API endpoint

#124

Post by JanSt » Sun, Feb 13, 2022, 6:03 PM UTC

pshc wrote: post #104

hn_throwaway_99 wrote: post #91

Earlier quoted context omitted.

> This comment comes off as either disingenuous or needlessly contrarian, and in the process tries to make points that fall somewhere between completely wrong and miopic. Bluntly, your response is the one coming off as needlessly argumentative, and the parent comment made plenty of sense to me. I don't think it's disingenuous to clearly explain the difference between the Same-Origin Policy and CORS, and to emphasize…

Regardless of their tone, fivea is correct to point this out as myopic. The grandparent comment argues about semantics and provides information that is technically correct, but not in a useful sense. To say that "CORS decreases security" because it opens up cross origin communication is perhaps not disingenuous (who can say?) but certainly misleading. All browser users would be worse off without CORS. I think we are…

I disagree. Just read the article „cors protects us“ - things like these come from misunderstandings like this one.

Re: CORS is not meant to secure an API endpoint

#125

Post by JanSt » Sun, Feb 13, 2022, 6:09 PM UTC

lolinder wrote: post #112

JanSt wrote: post #15

Earlier quoted context omitted.

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

Strictly speaking you are correct, but is there any actual harm in people using the word CORS as a shorthand for the whole system of Same Origin Policy + Cross Origin Resource Sharing? If there's some kind of dangerous misunderstanding that stems from this, I can understand emphasizing it, but otherwise it just feels pedantic.

There are misunderstandings arising - reading this thread or the articles makes it clear for me…

Re: CORS is not meant to secure an API endpoint

#126

Post by JanSt » Sun, Feb 13, 2022, 6:10 PM UTC

fivea wrote: post #70

JanSt wrote: post #15

Earlier quoted context omitted.

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

> Again, CORS does not protect, the SOP does :-) This is simply false. You are somehow wrongly assuming that only same-origin requests exist or are needed. This scenario never existed in the real world beyond the scope of small personal projects.

How am I assuming that? How exactly does CORS add security?

Re: CORS is not meant to secure an API endpoint

#127

Post by JanSt » Sun, Feb 13, 2022, 6:14 PM UTC

EGreg wrote: post #93

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…

I know the official line is that CORS “protects” the relying party (the website that initiates requests) but in practice I have found it to be quite the opposite. From having to deal with CORS over the years, to me is just a tool to protect one thing… the intellectual property of whatever site we are loading resources from. For example, images arrive “tainted” and you can’t get their pixels on a canvas no matter how…

CORS does not protect the website at all…

Re: CORS is not meant to secure an API endpoint

#128

Post by JanSt » Sun, Feb 13, 2022, 6:18 PM UTC

fivea wrote: post #72

iqanq wrote: post #69

Earlier quoted context omitted.

If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened.

> If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened. No, not really. Your simplistic example fails to acknowledge that your same-site "lock with no keys" model rendered same-origin-policy completely unusable in projects that fall beyond the scope of a personal hobby project, which left the whole world with…

We are not arguing about the usefulness of CORS, of course it is useful. It does not protect you though.

Re: CORS is not meant to secure an API endpoint

#129

Post by SahAssar » Sun, Feb 13, 2022, 6:25 PM UTC

feanaro wrote: post #113

goto11 wrote: post #63

Earlier quoted context omitted.

If that is the case, then SOP does not restrict anything either, since you can still send cross-origin POST requests under single-origin-policy. I don't think this is a useful way to look at things.

SOP should primarily be understood as a restriction on reading responses , not making requests.

SOP certainly does make restrictions on making requests, like setting any non-default headers (including content-type). It is one of the reasons that validating content-type to not be one of the normal form values used to be a valid way to handle CSRF for APIs.

Re: CORS is not meant to secure an API endpoint

#130

Post by JanSt » Sun, Feb 13, 2022, 6:32 PM UTC

Mavvie wrote: post #103

jesstaa wrote: post #76

Earlier quoted context omitted.

If you have any unauthenticated routes that you don't want arbitrary websites calling. > using JWT in a typical SPA API scenario. Is this typical? It's a pretty horrible setup. Cookies have a lot of great features that 'store a JWT in LocalStorage' just doesn't have.

This doesn't actually prevent arbitrary websites from calling them, it just makes it a tiny bit hard. They could always just proxy your endpoint and add the CORS headers. I'm still interested in the original question: if you use localstorage for auth tokens and you have proper CSRF protection, what does allowing all CORS actually make you vulnerable to?

You don't even need CSRF protection if you use localstorage for the tokens