Live data from Hacker News

CORS is not meant to secure an API endpoint

nikofischer.com

91–100 of 162 posts

Re: CORS is not meant to secure an API endpoint

#91
post #64

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

> 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 that CORS relaxes the Same-Origin Policy.

Re: CORS is not meant to secure an API endpoint

#92
post #74
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's a non-starter; the door has no purpose. You'd be better off sealing the entrance with bricks. If you offer a website with an API then CORS is an enhancement in that you're helping protect users from getting owned or hijacked. Alternatively if you can't stomach the risk, you could take down your API, which is about as useful as solving a math equation by multiplying both sides by…

"Lock with no keys" isn't particularly uncommon. They exist in the real world as one-way devices.

Re: CORS is not meant to secure an API endpoint

#93
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 hard you try. You can’t generate a “screenshot” you can print, and so forth.

If this was just about protecting the relying party website, that website would have a way to get around this “protection” to get something done.

Sure, people can try to get at the intellectual property directly, but they’d have to have an authenticated account first. If they do it on the site where it’s hosted, they are subject to its rules. If they are coming from some random site, eg loading it in bulk, the resulting info they get can’t be analyzed by the Javascript.

Yes CORS is just a relaxation of SOP, which makes it impossible to get sensitive data that would have otherwise been revealed to the relying party. Again — SOP is protecting the user’s data loaded from the ORIGIN. Its main job is’t “protecting the receiving site”, that’s a pretty disingenuous characterization.

Re: CORS is not meant to secure an API endpoint

#94
post #64

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

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

The set of all requests possible with CORS is a superset of all requests possible without CORS. The entire purpose of CORS is to allow more requests. By definition, it removes security barriers and opens things up.

> So, without CORS, you have a all-or-nothing security model, where the needle would always pend to the "nothing" side. With CORS, that needle can point "all that matters"

Yes, and a policy that permits nothing is more secure than a policy that permits some things. Although “nothing” is not accurate, some requests are still permitted in either case.

> You simply cannot claim that allowing only requests to the origins you explicitly allow is an erosion of a security model.

I didn't claim that. “Allowing only requests to the origins you explicitly allow” implies that you are enforcing a restriction, when in fact the opposite is happening – you are permitting more by removing restrictions. Tightly scoping what you open up with CORS is still removing restrictions, not adding them.

Re: CORS is not meant to secure an API endpoint

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

You and OP make a good point. In that most people I’ve come across don’t understand how the Same-Origin Policy and Cross-Origin Resource Sharing differ and relate.

I believe it’s important developers learn the nuances, otherwise we will likely see more faulty implementations.

Re: CORS is not meant to secure an API endpoint

#96
post #74
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's a non-starter; the door has no purpose. You'd be better off sealing the entrance with bricks. If you offer a website with an API then CORS is an enhancement in that you're helping protect users from getting owned or hijacked. Alternatively if you can't stomach the risk, you could take down your API, which is about as useful as solving a math equation by multiplying both sides by…

There's a while saying dedicated to it, "lock them up and throw away the key".

Re: CORS is not meant to secure an API endpoint

#97
This is why I think it's smart to discourage most developers from rolling their own authentication. Auth has gotten a bit more complex with the rise of SPAs plus API backends (like the setup in the original article), and mistakes you make with auth will bite you much harder. I'm not saying you should never do it, just that we all make mistakes and I'd rather those mistakes happen in a less security-critical context.

Re: CORS is not meant to secure an API endpoint

#98
The comments in this thread accurately reflect my own personal journey with CORS. Like waves on the shore, my confidence in my understanding of the protocol ebbs and flows with the orbit of the Moon.

Getting CORS right involves a couple days of forgetting what I think I know, closely reading how it works (again), writing up a custom middleware for whatever web framework I’m using that time because the OOTB middlewares always have subtle bugs (usually with the Origin header), and then essentially forgetting about it for the next few years.

Re: CORS is not meant to secure an API endpoint

#99

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

Of course. Author just missed how CORS works :).

Re: CORS is not meant to secure an API endpoint

#100
post #96
post #74

Earlier quoted context omitted.

If you have a lock with no keys, it's a non-starter; the door has no purpose. You'd be better off sealing the entrance with bricks. If you offer a website with an API then CORS is an enhancement in that you're helping protect users from getting owned or hijacked. Alternatively if you can't stomach the risk, you could take down your API, which is about as useful as solving a math equation by multiplying both sides by…

There's a while saying dedicated to it, "lock them up and throw away the key".

Hahah, alright. I'll grant you that. The lock:CORS metaphor was tenuous at inception, and now it is truly vaporized.
Post reply on HN