[Couto]

This reminds me of the server that Zoom used to have. Accepting connections only from 127.0.0.1, alone, isn't enough, since any request from the browser would match that IP, even if the request was being made through a XSS attack.

I'm sure someone with more knowledge in security would better chime in.

[jjnoakes]

What I do is generate a random token, pass it to the browser I spawn, and only accept requests that include the token.

[Per_Bothner]

What is a good secure way to pass a random token to the browser? If the token is part of the URL, which is in the command-line, then it appears other users can see the token. What I do for DomTerm (https://domterm.org) is create a small only-user-readable html file which sets the secret token, and then does a 'location.replace(newkey)' where newkey to an http url to localhost and includes the secret token. I spawn the browser file a file: url, so teh browser can only read the file if it is running as the same user. Better suggestions?

[dmurray]

Pgadmin does something like this. And also makes it easy for you to get another URL with that token, in case you want to open the same page in a different browser.

[cjonas]

Wouldn't proper CORS be enough? I guess you would have to avoid putting any sensitive data in GET requests

[feanaro]

No, because CORS can only restrict which origins (scheme, domain, port combinations) are able to access the site's data. But you're not even connecting from a web origin but from localhost and you're trying to defend from all access except by your frontends. For this, you need a shared secret between the server and the frontend.

A further limitation of CORS is that certain requests are allowed even if they are not from an allowed origin.

To conclude, you definitely need a secret.

[galaxyLogic]

IKs there a good simple way to keep it secret?

I assume someone could have a look at the JavaScript on the browser and see hey this must be the secret stored here because it is passed to the server on every request. Then write there XSS attack to use that.

[feanaro]

The secret would have to be non-static (not baked into the code).

[chrisweekly]

I'm so fuzzy on the details but isn't this what client certs are for?

[cjonas]

The cert couldn't obviously couldn't be static in this case (otherwise it would be trivial to get the private key).

Creating a cert during "install" probably adds a good bit of complexity (especially if the map has multiple env targets)

[feanaro]

You could accomplish this with client certs too, sure. A random secret is a simpler solution in many ways and accomplishes the same goal, though.

[z3t4]

One problem is that we developers are lazy and use Access-Control-Allow-Origin: * (wild star) instead of actual hostname. (eg. allowing all origins to access the backend)

No modern browser allows access to localhost without that header.

But it's still possible to forge a request using curl or whatever to bypass CORS. So as the parent post suggest - use a token of some sort.

I also recommend using a strict Content-Security-Policy to stop X-site injection attacks. (eg someone adding an image to your page/app with src="/api/cmd=rm -rf /"

[galaxyLogic]

That's a good trick. Thanks for the tip.