Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CORS is not meant to secure an API endpoint

nikofischer.com

Post reply on HN
Print view View original

111–120 of 162 posts

Re: CORS is not meant to secure an API endpoint

#111

Post by icedchai »

jefftk wrote: post #79
egberts1 wrote: post #65

CORS is about making the web browser behave in a certain manner, and not the web site, and not the end-user. Once fully understood, it is useless mechanism of security theater.

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.

Re: CORS is not meant to secure an API endpoint

#112

Post by lolinder »

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 :-)

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.

Re: CORS is not meant to secure an API endpoint

#113

Post by feanaro »

goto11 wrote: post #63
JanSt wrote: post #55

Earlier quoted context omitted.

That doesn't matter at all in a security context. POST can (and is used) for everything DELETE and PUT are used. Adding DELETE and PUT did not relax anything. The only question is whether requests are restricted (i.e. in terms of sending resources like cookies).

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.

Re: CORS is not meant to secure an API endpoint

#114

Post by feanaro »

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.

To explain your error a bit less facetiously, the point my sibling is making is that SOP is the default policy, which is maximally restrictive. CORS is a technology used to relax SOP, to make it less restrictive.

So it is not CORS that protects, since it restricts nothing, but SOP (potentially relaxed by CORS).

Re: CORS is not meant to secure an API endpoint

#115

Post by [deleted] »

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…

[deleted]

Re: CORS is not meant to secure an API endpoint

#116

Post by aobdev »

goto11 wrote: post #75
JanSt wrote: post #31

Earlier quoted context omitted.

The request does not send resource/cookie data if CORS does not explicitly relax the SOP. CORS does not protect!

A cross-origin POST request can be initiated using a HTML form and does send cookies. CORS provides a safer alternative.

Can you elaborate on how CORS provides an alternative? Responding with a CORS policy to your own client’s preflight requests is not going to do anything for a malicious client’s form POST.

Re: CORS is not meant to secure an API endpoint

#117

Post by brazzy »

nerdponx wrote: post #88
HL33tibCe7 wrote: post #34

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.

Concernting this particular article, there is not actually much to learn. Ignore everyone bickering about CORS, that's beside the point (as is the title, which was very badly chosen).

The point is that in a client-server architecture, you can never trust the client to play by your rules, and anything you put into the client becomes public knowledge.

The big mistake in a previous article which this one criticizes is this: it put an API key hardcoded into the client, which let everyone who looks at the client code do whatever the REST API lets you do. At that point, rules like "you need an account, you have to log in, you can only change your own stuff" can simply be ignored by accessing the REST API directly instead of running the client code.

The correct way to do it is to require an authentication token sent along with requests and which the server checks. The difference between the insecure API key and the authentication token is that the client gets the token only after the user logs in, it is unique to that user, possibly valid for a limited time, and the server will only only allow viewing or modifying things which the user for which that token was generated is allowed to view or modify.

Re: CORS is not meant to secure an API endpoint

#118

Post by Aeolun »

layer8 wrote: post #109

Since, according to the article, the API key is user-specific, and presumably only a logged-in user would receive the key in the JS source, how would an attacker get hold of it? Just trying to understand the attack vector.

The author of the original article exported their personal key, and is now using it for everyone on their Vue website.

Presuming that only a logged in uses sees it is the problem. Everybody and their dog sees it, and can impersonate the person whose key it was.

Re: CORS is not meant to secure an API endpoint

#119

Post by patrickthebold »

fivea wrote: post #64
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…

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

I think the confusing is in "adding CORS". I think you mean "Adding CORS to the browser standards", and gp means "Adding some kind of CORS interceptor thing in my backend".

It's great that CORS is a thing in browsers, and you can use it if you need. But each person who uses it is allowing more origins, and so allows more requests.

Personally I always avoid CORS and just server every thing I need from the same origin, but that's just because of the kinds of things I've worked on.

Post reply on HN