1

We develop web-applications using a javascript frontend framework (ReactJS), to retrieve the data to show, the user's browser calls an authenticated REST API which is our backend (Kotlin+Spring), the backend then connects to the relational database to retrieve the data (see the sequence diagram).

current interaction

Our customer doesn't seem to like this simple architecture anymore and he is asking us to add a layer for security purposes, his idea being that no service reachable by users should talk directly to the database because if the service gets hacked then the whole database is exposed. He suggests we add another gateway layer which cannot connect to the database, this gateway layer then should connect to the backend service instead; the backend service wouldn't be directly exposed to the clients anymore (see the second sequence diagram)

sequence diagram with middle layer

I've never seen this pattern explicitly described in literature as a security feature and it seems kind-of pointless but I might be wrong, maybe it makes sense in some contexts. So is it a good practice? Does this pattern have a name?

Improve this question
3
  • From a security perspective, separating different service in order to keep the attack surface small can be a good idea – but it wont automatically work. How are database credentials managed? If the frontend-API has access to the same credential store, little is won. How will the database-API determine which requests are legitimate? If this layer just passes through anything the security benefit is minimal. Similarly, a gateway at the front will do very little. Will the two APIs use different tech stacks? If not, vulnerabilities could perhaps be chained to traverse your network.
    – amon
    Commented Mar 15, 2021 at 22:09
  • 1
    the database credentials are secrets mounted on the pods of the kubernetes cluster, the gateway would not have access to it, it would be in another cluster altogether. the backend (database-api) would just accept any request since it would be only reachable by the gateway. I agree that if the gateway and the backend use the same tech stack it's pretty much useless.
    – molok
    Commented Mar 15, 2021 at 22:39
  • 1
    @molok, are you familiar with the term DMZ? The idea here is that the database is not accessible directly from the DMZ, which is much more exposed than your true back end systems.
    – John Wu
    Commented Mar 16, 2021 at 15:50

3 Answers 3

Reset to default
2

You already have an API.

Spring is the API. While Spring does talk directly to the database, it does so through a Data Access Layer, and it separately exposes JSON endpoints for your application. A properly architected Spring API does not allow the public-facing endpoints to interface directly with the database.

What you're labelling as an API in your second illustration is actually the place where a Gateway or Backend-for-Frontend would go. While such mechanisms can confer certain benefits, security isn't necessarily one of them; your endpoints on your Spring application must still be secured unless they're not public-facing.

Further Reading
API Gateway Pattern
Building a Backend for Frontend for your Microservices

Improve this answer
7
  • 1
    What you describe is a reasonable architecture to reduce coupling between components, but such an (in-process) architecture is no security barrier, which the question seems to be about.
    – amon
    Commented Mar 15, 2021 at 22:13
  • Yes, my point exactly.
    – Robert Harvey
    Commented Mar 15, 2021 at 22:18
  • 2
    Well, what if your gateway gets hacked?
    – Robert Harvey
    Commented Mar 15, 2021 at 22:24
  • 1
    Not to me. But if the customer is suddenly concerned about security, then you need to provide him with a rationale. It could just be money; it will be expensive to put up a Gateway, and if you can demonstrate that the Spring API already has adequate security ...
    – Robert Harvey
    Commented Mar 15, 2021 at 22:37
  • 2
    And if they're willing to take the cost, well ...
    – Robert Harvey
    Commented Mar 15, 2021 at 22:39
0

It’s not your decision. It’s your management‘s decision and should be based on two questions: Does the customer know what they are talking about, and does the customer pay for it?

Improve this answer
1
  • 1
    it is my job to understand if what the customer is asking makes any sense, I've never thought about this use case so I am researching about it. If this is useless and will increase the technical debt I am the one that has to tell them.
    – molok
    Commented Mar 16, 2021 at 8:00
0

I would not consider that the addition of another layer would actually benefit you in terms of security. The requests are satisfied by performing SQL queries, but do not themselves contain SQL.

All that being said, I did use such an architecture to isolate the credit-card processing engine of a website. The first-tier server had to issue an internal request to a highly-secured separate computer which actually talked to the financial vendors. This was deemed necessary to achieve "PCI compliance."

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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