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

21–30 of 162 posts

Re: CORS is not meant to secure an API endpoint

#21

Post by JimDabell »

> 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 source code of the web app and use it, for example, via a cURL request to directly access the API resources of the backend. With cURL, no CORS takes effect, so the attacker has direct access with the full rights of the user.

All of this is completely wrong.

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.

If CORS is not integrated, the same-origin policy is in full effect and code from one site cannot read resources from your site. It starts off as secure, and stays secure.

If you use cURL, then the same-origin policy doesn’t apply, and you can of course read any resource.

The same-origin policy is not a generic access barrier, and shouldn’t be used as such. It stops one site from abusing the user’s authenticated state with other sites, and that’s it.

Re: CORS is not meant to secure an API endpoint

#22

Post by JanSt »

tshaddox wrote: post #13
JanSt wrote: 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.

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

Re: CORS is not meant to secure an API endpoint

#23

Post by sercanov »

If the API key has some certain permissions I don't see any exploitation risk. In the end, Vue.js or any other HTML is basically a GUI for REST API. You should always limit your REST API operations on server-side and don't trust frontend validations. Power users are always able to access your sessions,cookies,tokens and can use them freely with API.

Re: CORS is not meant to secure an API endpoint

#25

Post by rhdunn »

The thing that makes CORS annoying for me is when trying to get a local development environment up and running, or trying to get a standalone web page (e.g. game) running locally. For the latter, you can run a simple web server but its another added impedance that reduces usability in favour of security, like not being able to render an XML file with an xsl preprocessing statement to a local XSLT file.

Re: CORS is not meant to secure an API endpoint

#27

Post by goto11 »

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…

It is more complex than that, because certain kinds of cross-site requests has always been allowed. GET and POST requests are allowed, but PUT and DELETE is not. For POST requests you can send the request but not access the result. So CORS can be used to increase protection, by disabling cross-site POST requests, but it can also be used to decrease protection for other requests.

Re: CORS is not meant to secure an API endpoint

#28

Post by awill88 »

outsidein wrote: post #2

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)

Agreed. This is a good article, written well for the intended audience—which I would qualify as occupying that ambiguous space between junior and senior developer knowledge. Perhaps the author hasn’t really arrived at the “right” answer for themselves. You hit the nail on the head, the solution is to login (authenticate).

Maybe the author is being careful not to offer an abstract use case as that might ironically be misinterpreted and be counterproductive? I feel security blogging is just one of those subjects where it’s more useful and prudent to express what shouldn’t be done then should. Maybe it’s okay it doesn’t include the solution, that’s left up to the reader to infer.

Re: CORS is not meant to secure an API endpoint

#29

Post by shankr »

ricardo81 wrote: post #26

TLDR don't share a private api key on the client side and also, don't conflate CORS with keeping secure information secure.

Sorry bit of noob here with all these web security element.

What does it mean to share API key on client side? Is it same as passing the header based authorization for client? API keys are something like JWT?

Re: CORS is not meant to secure an API endpoint

#30

Post by ricardo81 »

shankr wrote: post #29
ricardo81 wrote: post #26

TLDR don't share a private api key on the client side and also, don't conflate CORS with keeping secure information secure.

Sorry bit of noob here with all these web security element. What does it mean to share API key on client side? Is it same as passing the header based authorization for client? API keys are something like JWT?

You don't want to share security credentials in source code on a web page, that is effectively sharing the credentials with the rest of the world.
Post reply on HN