Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

CORS - localhost as allowed origin in production

Occasionally when troubleshooting bugs in production, it would be convenient to be able to hit our production REST server from my local dev environment. But i'm concerned that adding localhost to allowed origins would be a security risk. Searches have yielded conflicting information. Are my concerns valid? Why or why not?

like image 274
Devon Sams Avatar asked Aug 19 '16 15:08

Devon Sams


People also ask

Is it safe to allow CORS from localhost?

Having given the concept that CORS does not provide any additional security when talking about API access, this means that that allowing a particular domain like localhost does not make your API less secure.

How do I fix Access-Control allow Origin CORS origins?

Since the header is currently set to allow access only from https://yoursite.com , the browser will block access to the resource and you will see an error in your console. Now, to fix this, change the headers to this: res. setHeader("Access-Control-Allow-Origin", "*");

How do I get rid of CORS error?

Cross-Origin Resource Sharing (CORS) errors occur when a server doesn't return the HTTP headers required by the CORS standard. To resolve a CORS error from an API Gateway REST API or HTTP API, you must reconfigure the API to meet the CORS standard.


2 Answers

I'm assuming you have

Access-Control-Allow-Credentials: true Access-Control-Allow-Origin: https://localhost 

The risk is that any services running on a user's machine could effectively bypass the Same Origin Policy for your site.

So if you have a REST URL such as

https://example.com/User/GetUserDetails 

A malicious or compromised service running on the user's computer could make that request via the user's browser and then grab details about the user, because their authentication cookie will be passed with the request.

Now, you could argue that a malicious service running on the user's computer could just grab the authentication cookie from their browser directly and then make the request itself. However, if the service has some flaws of its own (say XSS), this could allow another site to compromise the user via your REST service (evil.example.org --XSS-> localhost -CORS-> example.com/User/GetUserDetails).

Another scenario that could put you at risk if the user is running a local reverse proxy to access something. This would enable the target site to compromise the user through yours, should that target site be malicious or be compromised. This is because the user would be accessing the target site with a domain of localhost.

If you really need to do this I suggest you have a special developer account for your REST service that when accessed adds the Access-Control-Allow-Origin: https://localhost header to your requests only. That way, you are not putting other users at risk because you know you are only running the front-end server only at https://localhost so you cannot be compromised by your open CORS setting.

Another way may be to use something like noonewouldusethis2859282.localhost for your local copy of the front-end. Then you can safely add the Access-Control-Allow-Origin: https://noonewouldusethis2859282.localhost header because nobody else would use this and would be safe from CORS attacks.

like image 83
SilverlightFox Avatar answered Sep 23 '22 17:09

SilverlightFox


There is no security concern with adding localhost to your CORS setup in production.

By adding something like:

Access-Control-Allow-Credentials: true Access-Control-Allow-Origin: http://localhost:3000 

The browser is now allowed to make calls from localhost:3000 to your service, bypassing Same Origin Policy. Any web developer can now create a webpage running from their local machine to make a call to your API, which is useful for your team. However, localhost is not a publicly routable address - You can't share a link to http://localhost:3000. Remember, CORS is only a security measure for web browsers making calls to your site. Anyone can still call your endpoint via server to server calls (or a script). However, you should avoid:

Access-Control-Allow-Credentials: true Access-Control-Allow-Origin: * 

This will make your site available to every website. Instead, lock down your Access-Control-Allow-Origin to the sites that need it. Unfortunately, Access-Control-Allow-Origin only takes a single value, so you have to process HOST request server side and return valid ones (more info).

Authentication when calling a CORS endpoint

When you make a CORS request which requires authentication, you should be adding an Authorization header to the call, and not passing cookies - fetch does this by default. Thus any calls made to a CORs end point would be made via javascript adding a token to the header that it only has for that session. If you do store the token via a cookie or localstorage, note that its only accessible from that domain (more info). Your production endpoint and localhost will not have the same cookies and shared localstorage.

Disabling CORS in Chrome

Lastly, you can make CORS request from Chrome to any site by starting Chrome with --disable-web-security (more info).

Lastly, Google Chrome only allows service workers to run on secure websites and http://localhost. If you choose to create a local.example.com for development, you'll need to create an SSL cert and do all the configuration on your local machine to get that running. I recommend just using http://localhost:XXXX.

like image 21
Chris Lorenzo Avatar answered Sep 23 '22 17:09

Chris Lorenzo