[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 /"