In the good old days, you made server-side websites using PHP or something like that, now we have modern web apps divided into front-end and back-end (usually API Rest), you can't rely on CORS because some clients like postman don't care about it.

How can you protect confidential info? picture this:

You have an API let's call it "Secure API", it uses OAuth2 grant flows, and has confidential data.

You have the resource owner client (Single Page Application with a backend (API Rest) to proxy the requests to "Secure API" and take charge of auth), but as I said before, anyone can hit the backend from something like postman and impersonate the client (I do not know if "impersonate" is the correct term).

How do you protect the communication between the backend and front-end?

Should we back to the good old days when dealing with sensitive data?

What alternatives do I have to connect with "Secure API" from the resource owner client?

EDIT: this graph explains the case I mentioned above

enter image description here

The thing is that I don't want to allow every authenticated client to get the info, just the Resource Owner Client, is there a way to do that?

I haven't designed the API it's just a hypothetic case, but here is an example

enter image description here

Backend proxy access token has all the permissions, because its intended to be used only by the resource owner client

  • 1
    What do you mean with "I can't rely on CORS" - rely on it for what?
    – user163495
    Commented Nov 19, 2021 at 5:17
  • 1
    Also, you essentially complain that you provide an API and that people can use that API. What is the issue here?
    – user163495
    Commented Nov 19, 2021 at 5:56
  • 1
    If you think CORS is a protection of some kind, your understanding is so far off base that I really recommend you start by reading what Same-Origin Policy is (CORS is a method, used with the Fetch/XHR APIs, for deliberately punching holes in SOP; it's a way to let browser-based clients do things they otherwise aren't allowed to, and that's it). Beyond that, what are you actually afraid of? Postman won't have your auth token (unless the caller is actually authenticated), so it can't impersonate anything except an anonymous client.
    – CBHacking
    Commented Nov 19, 2021 at 6:09
  • I think there is quite a lot of misunderstandings and incorrect assumptions in your question. So much that it will be difficult to answer because we would first have to correct, well, nearly every point you've made.
    – schroeder
    Commented Nov 19, 2021 at 8:19
  • @MechMK1, I don't want to allow every authenticated client to get the info, just the Resource Owner Client
    – Ger
    Commented Nov 19, 2021 at 12:39

1 Answer 1


Things didn't changed much since them. Servers would render the entire page on their side and send it to the client, and bad designed authentication would mean someone accessing things not intended to. Today it's basically the same, but instead of sending the entire page, the server sends only the information needed for the client to render the page.

CORS does not protect anything on the server: it's intended to protect the client, not the server. It prevents a malicious actor from loading foreign resources in the context of a site and stealing information.

Impersonating the client: this is not possible if you have authentication in place. You should have an endpoint on the API side that receives a login and password, and return a token. The client them sends this token on every other request.

Should we back to the good old days when dealing with sensitive data?

You don't need to. Have a proper authentication endpoint handling authentication tokens, send the token on every sensitive request, and you are done. Having the server send a sensitive json, HTML, pdf or mp4 file does not make any difference at all.

  • Do you think that the example I made above is a good way to handle auth?, is it more secure to change from SPA to an Isomorphic app?
    – Ger
    Commented Nov 24, 2021 at 17:09
  • But the tokens are public on each request, can someone copy and paste the tokens into their application and get sensitive information?
    – Ger
    Commented Nov 24, 2021 at 17:15
  • It makes no difference if it's a SPA or not. The token is public but cannot be leaked unless the client willingly shares it. TLS will protect the token in transit.
    – ThoriumBR
    Commented Nov 24, 2021 at 17:16
  • For example, when someone is using Google Maps API from a SPA, someone gets your credentials and you get billed, how do you prevent that in this API?
    – Ger
    Commented Nov 24, 2021 at 17:33
  • You don't send Google API credentials to the client, they are stored on the server, the server queries Google API and sends the results to the client. The server generates a credential to the client, and uses it to validate the client and block abusive clients.
    – ThoriumBR
    Commented Nov 24, 2021 at 17:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .