Live data from Hacker News

CORS is not meant to secure an API endpoint

nikofischer.com

131–140 of 162 posts

Re: CORS is not meant to secure an API endpoint

#131

Having read the original article ( https://designkojo.com/post-drupal-using-jsonapi-vuejs-front... ), it’s quite clear that the author doesn’t know enough about what he’s talking about to write these kinds of posts. I wouldn’t usually say this, but on security-critical topics like this, winging it just isn’t good enough. People will be misled by this article.

Where can I learn/read about this topic? It seems like mysterious magic to me, and everyone is always saying everyone else is wrong.

> Where can I learn/read about this topic?

It's not this specific topic, it's any topic and a general mindset.

Thinking about possible attack vectors on your own application is a mindset, and to be able to do that properly you need to deeply understand the technology you are using.

There's no exhaustive list of security issues to avoid, just as there is no exhaustive list of every function you'll ever need to write. Security means preventing the wrong kind of people to do the wrong kind of things. What that means is entirely dependent on your application.

In the current webpack world where your code is mangled through 18 different tools before turning into an opaque JavaScript blob somewhere in your angular app that was automatically set up for you, many people lack an understanding of what's actually happening.

You cannot make a boat sink-proof if you don't understand why a boat floats. Sure someone could make a list of things to watch out for and rules to abide by, but that's probably not gonna cut it in the long run.

Re: CORS is not meant to secure an API endpoint

#132
post #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…

> I know the official line is that CORS “protects” the relying party (the website that initiates requests)

You're getting that wrong. It doesn't protect the website that initiates the requests. It protects the user from the website initiating the requests.

SOP is to stop website A from doing shady things to the user using their session from website B.

It does protect you in the sense that protecting your users is also protecting you, but it requires voluntary cooperation from the user, so it doesn't do anything to protect you from malicious users.

In the "hotlinking" example you're giving, CORS is only protection from the absolute laziest of attackers, since you can get around that with about 5 minutes of setting up nginx to proxy from your domain to the resources you want to re-use. You can also get the same protection without CORS by blocking requests based on the Referer header

Re: CORS is not meant to secure an API endpoint

#133

Having read the original article ( https://designkojo.com/post-drupal-using-jsonapi-vuejs-front... ), it’s quite clear that the author doesn’t know enough about what he’s talking about to write these kinds of posts. I wouldn’t usually say this, but on security-critical topics like this, winging it just isn’t good enough. People will be misled by this article.

[deleted]

Re: CORS is not meant to secure an API endpoint

#134
post #104

Earlier quoted context omitted.

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

The three pillars of security are confidentiality, integrity and availability.

Letting people have access to things that they are supposed to have access to is part of security. You don't get perfect security just by denying everyone access to everything.

Re: CORS is not meant to secure an API endpoint

#135
Ah, CORS. One of those rare topics to fall under the category of: "I have no idea how it works. I run into an issue with it. I spend all day researching, reading documentation, blog posts, etc, explaining it. I finally come to some understanding. Three weeks later, start the process again."

To my weak-minded brain, the sticking point always comes down to: CORS/SOP is a policy enforced by the browser, correct? The client. The endpoint tells the client what origins should and should not be allowed to make the request. It is up to the client (browser) to decide whether to enforce this policy or not. Is that at least somewhat correct?

Re: CORS is not meant to secure an API endpoint

#136
post #22

Earlier quoted context omitted.

That’s oversimplified to the point of being extremely misleading. Under SOP, the way you loaded third-party data (not code) was JSONP, where (oops!) you’re actually loading third-party code but you just cross your fingers and hope the third party doesn’t deliver you any nefarious code.

CORS does allow to share, not disallow! The default under SOP is not to share.

You're ignoring their point. There are still ways to share across origins even with SOP and without CORS, for example JSONP[1]. Using CORS is more secure than the pre-CORS way of sharing things across domains.

[1] https://en.wikipedia.org/wiki/JSONP

Re: CORS is not meant to secure an API endpoint

#137
post #79

Earlier quoted context omitted.

It is not useless, because there is information that the browser has and that it is trusted to protect. Consider a server that returns JSON in response to a POST request, and what JSON it returns depends on the user's cookie. Properly configured CORS headers allow the JSON to be read by some origins and not others. An attacker with curl will not have the user's cookie and an attacker with a malicious website will not…

In your scenario, the attacker with the web site could simply proxy requests to that CORS "protected" end point (through their own web site, on the back end.) That would allow them to read the JSON response, and deliver it to the browser with alternate headers.

In that case, the attacker's endpoint will be on a different domain than your endpoint, so the cookie from your domain won't be included in the request.

Re: CORS is not meant to secure an API endpoint

#138

Ah, CORS. One of those rare topics to fall under the category of: "I have no idea how it works. I run into an issue with it. I spend all day researching, reading documentation, blog posts, etc, explaining it. I finally come to some understanding. Three weeks later, start the process again." To my weak-minded brain, the sticking point always comes down to: CORS/SOP is a policy enforced by the browser , correct? The cl…

Yes. The other confusing thing about CORS is that CORS is not a protection against anything, but rather a way to UN-protect (in a restricted fashion) the browser's "same origin policy". Same Origin Policy is the protection, and CORS is the way to allow the browser to poke a hole through that in a limited fashion (only for the domains that the original site you visited say it should allow).

Re: CORS is not meant to secure an API endpoint

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

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

> Yes, and a policy that permits nothing is

You're reading that backwards. "nothing" is "no security".

Re: CORS is not meant to secure an API endpoint

#140
post #104

Earlier quoted context omitted.

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

> You and fivea are conflating functionality with security.

fivea wasn't conflating functionality and security. They were saying that a world without CORS would be a world where those rights are always granted.

Post reply on HN