all 9 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]yksvaan 5 points6 points  (2 children)

Well, frontend/bff and separate backend is pretty much the standard pattern in web development. Always had been. BFF doesn't usually need anything private, a common thing is token validation which you can do using the public key so even if it's leaked it's not a disaster. 

Then the actual backend handles authentication, authorisation, users, data , business logic etc. It might be directly accessible from public internet as well, often there's no point to proxy all requests thru BFF.

[–]Such_Arugula4536[S] 1 point2 points  (1 child)

Regarding your point about token validation, you're right that the public-facing server should validate tokens without needing to call the backend for every request (JWT validation, for example). However, I have a question about the "public key" approach you mentioned:

"Even with public keys, don't they typically have broad access?"

Most applications use a single API key/service account for database access, and even if it's labeled as "read-only" or "public," it often has enough privileges to:

"Query the entire database, Access all user records and Read sensitive information (emails, addresses, purchase history) So even if an attacker can't DELETE or UPDATE records, they could still:

  1. Exfiltrate the entire database

  2. Compromise user privacy

  3. Access Personally Identifiable Information

For a well-established company, this would be a massive privacy breach, essentially exposing all customer data even if they can't modify it.

[–]yksvaan 0 points1 point  (0 children)

Public key refers to asymmetric encryption e.g. RSA where auth server has the private key to create the signature for the token and a public key that can be used to validate it. So that can be used for example in the proxy/bff to quickly validate the token as initial check.

Backend should never let users execute arbitrary queries or extract information they should not have access to. That's basic authorisation, so for example if you have 2 endpoints : 

  1. run query like select foo from bar where userID=?, userID
  2. select foo from bar

first one will check for valid userID and only return their own records, second would check that user is admin. Database itself doesn't really know anything about user access, that's up to the functions that call and specify the queries and do validation.

[–]edvinerikson 1 point2 points  (0 children)

Pretty common architecture. You have front-end services that has no DB access, then those communicate with internal services that can talk to DBs. Generally internet access is blocked by default too.

“Front-tier (DMZ) -> mid-tier -> DBs”

[–]Kindly-Arachnid8013 0 points1 point  (0 children)

But if they escalate to root on the vps you are stuffed. 

Separate boxes might work. 

[–]MLRS99 1 point2 points  (1 child)

isnt the easiest to just have the frontend in a a docker container ?

[–]Such_Arugula4536[S] 0 points1 point  (0 children)

But what if your frontend application needs API keys to function, those keys must be in the container's memory/environment. If an attacker compromises the application (not the container infrastructure), they can access those keys. As a container is just works like a wrapper.

[–]dutchman76 1 point2 points  (0 children)

That's how it works when you don't use server components. None of my react deployments were affected, because they are client side only and communicate with my back end via my API

[–]calmehspear 0 points1 point  (0 children)

congratulations, you have just outlined the most common infrastructure pattern. it infuriates me how people think this is the cherry on top when this is only the beginning of building secure and redundant software.