0

I have a system with three layers: two client web apps, one Backend, and two DBs. The two DB and client app instances represent prod and test environments. The backend has only one instance that should serve both environments. Say I have prod-client.myapp.com, test-client.myapp.com, prod-db.myapp.com, and test-db.myapp.com but only one API service api.myapp.com.

The backend exposes one API, but it should match the client app and the DB environment. My current implementation is to send the environment code prod or test from the client app to the backend so it will know which DB to query.

Duplicating the backend for each environment is not an option.

But I'm wondering if sending the environment code from the client app is a good idea... Is there some security risk with that approach?

4
  • 1
    Why does the client need to send the environment code to begin with? Why can't all requests to prod.myservice.com be assumed to be meant for the prod db? Note: adding the code seems to create more headaches anyway (how do you handle the client sending the code prod to the test.myservice.com domain, and vice versa?) May 25, 2021 at 15:55
  • I have ONE backend that serves BOTH environments. So it needs to know to which DB to access based on the client environment, somehow... The easiest thing for me is to pass the environment code in each request, but is it safe?
    – nrofis
    May 25, 2021 at 20:58
  • Your response doesn't answer my question though: Why can't all requests to prod.myservice.com be assumed to be meant for the prod db? May 26, 2021 at 12:01
  • Since I don't have prod.myservice.com... I have something like api.myservice.com that serves BOTH environments. If I had prod.myservice.com and test.myservice.com everything was easy...
    – nrofis
    May 26, 2021 at 19:19

1 Answer 1

1

I'm not sure I follow, but in any case, you need someway to authenticate they webapps. The web app that is for "test" should never be able to send a code that it is asking for the "prod" data.

A safer way of doing this is to handle that mapping in the backend. The webapps are registered with the backend and the backend knows where to send the queries based on the registration information. This makes it hard to accidentally (or maliciously) query prod data from the test app.

4
  • 1
    I'm generally supportive of this answer, but it's not clear to me what it means to "register" a web app with a backend. The web app is the client after all, and so the backend can't trust anything it says. A "registration" implies that the backend knows which client is which. May 25, 2021 at 17:24
  • Easy, I have ONE backend that serves BOTH environments. Say I have prod-client.myapp.com, test-client.myapp.com, prod-db.myapp.com, and test-db.myapp.com but only one API service api.myapp.com. I need that the backend api.myapp.com will access the correct DB environment as the client environment. Is there any (security) problem to send the environment code from the client to the backend?
    – nrofis
    May 25, 2021 at 20:54
  • @ConorMancone I was thinking of the web app is a just a process on a single front-end machine and not the web browser. This all sounds poorly engineered and/or working around annoying organizational policies. They shouldn't be sharing a backend for 2 different environments. If the browser is sending the backend DB env string, then it is all a terrible idea. May 25, 2021 at 21:36
  • Yes, the client app is web based app running at the users browser. Look, if we had separated backend, still the client app need to know where it send to: prod-api.myapp.com or test-api.myapp.com. So instead of sending the env inside the request body, the env described in the route itself... You always need to send the env somehow, I just wanted to know if sending it inside the body can case some security issue that I didn't think of... And yes, we wish for a better solution, but in the current circumstances this is our limitation... If there is a risk we will need to find better solution..
    – nrofis
    May 26, 2021 at 8:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.