-1

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

Ger
  • 143
  • 6
  • 1
    What do you mean with "I can't rely on CORS" - rely on it for what? –  Nov 19 '21 at 05:17
  • 1
    Also, you essentially complain that you provide an API and that people can use that API. What is the issue here? –  Nov 19 '21 at 05: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 Nov 19 '21 at 06: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 Nov 19 '21 at 08:19
  • @MechMK1, I don't want to allow every authenticated client to get the info, just the Resource Owner Client – Ger Nov 19 '21 at 12:39
  • Sorry, @MechMK1 I misunderstand CORS, what I want is to avoid requests to the backend proxy API from different URLs – Ger Nov 19 '21 at 12:45
  • @Ger Then you have to make decisions on who to serve which information based on authentication info and not just "is authenticated" and "is not authenticated". But if possible, please give an example of what your API looks like and what you expect the user to see or not to see. –  Nov 19 '21 at 12:46
  • @MechMK1 I haven't designed the API it's just a hypothetic case, but I made a graph and added it to the question – Ger Nov 19 '21 at 13:02
  • @schroeder can you elaborate more on the misunderstandings and incorrect assumptions that I have? this will help other people with the same misunderstandings – Ger Nov 19 '21 at 13:12
  • @Ger I still don't understand the actual issue here - why do you *care* if a customer can access their own info with the API you provide? –  Nov 19 '21 at 13:12
  • Ok, I understand @MechMK1, I shouldn't care about where they are going to display the info or from where they are going to modify it. just if they have the user and password they can do what they are allowed to, from where they want, right? – Ger Nov 19 '21 at 13:19
  • @Ger Exactly - that's the whole point of an API after all. –  Nov 19 '21 at 13:32
  • @MechMK1 But how about other flows like Client Credentials Flow, everyone who hits backend proxy will get authenticated and can use the API, the problem comes with the API usage because anyone can hit backend proxy and consume the API, and then you get charged for others using your backend proxy – Ger Nov 19 '21 at 13:48
  • @Ger Does it matter if the calls come from your frontend or someone using Postman? –  Nov 19 '21 at 14:34
  • @MechMK1 No the usage is going to be billed no matter where does the calls from – Ger Nov 19 '21 at 15:26
  • @Ger Then why does it matter? –  Nov 19 '21 at 17:08
  • @MechMK1 Because on client credentials flow you only send API keys to the auth server, but you can't do it just with the SPA and If you do it using the backend proxy then everyone who hits the backend proxy is going to get authenticated because backend proxy holds the keys, then you are going to get billed for request made by other clients – Ger Nov 19 '21 at 20:59

1 Answers1

3

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.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 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 Nov 24 '21 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 Nov 24 '21 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 Nov 24 '21 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 Nov 24 '21 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 Nov 24 '21 at 17:36
  • I'm afraid, I still don't get it, so In the Google API case my backend proxy approach is correct?, if so how do you prevent others to hit your backend proxy API endpoint to authenticate with your credentials – Ger Nov 24 '21 at 17:45
  • Nobody access the backend data. The backend exposes an endpoint that gets accessed, and the backend uses its own credentials to access Google API. – ThoriumBR Nov 24 '21 at 18:16
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/131750/discussion-between-ger-and-thoriumbr). – Ger Nov 24 '21 at 18:18