Proxy-based Architecture
You set up a proxy based architecture by placing a routing node between client apps and backend servers. This middle node receives every client request, checks basic rules, and forwards valid traffic to the backend. Engineering teams often build this setup with standard network routers and static database roles. Still, when those shared roles hold broad permissions, anyone inside the network can run risky commands. How a native proxy based architecture routes traffic In a standard proxy based
Proxy-Based Access + Zero Trust Architecture: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a proxy based architecture by placing a routing node between client apps and backend servers. This middle node receives every client request, checks basic rules, and forwards valid traffic to the backend. Engineering teams often build this setup with standard network routers and static database roles. Still, when those shared roles hold broad permissions, anyone inside the network can run risky commands.
How a native proxy based architecture routes traffic
In a standard proxy based architecture, clients never talk directly to backend databases or internal servers. Instead, the client app sends every request to an intermediate network node first. This node listens on a single port and accepts incoming network traffic from authorized subnets. Once the traffic arrives, the node checks its local routing table to find the right destination.
Teams usually pair this network design with native role permissions on the backend server itself. First, an admin creates a local user account on the database or internal service. Next, the admin assigns read and write permissions to that specific account. Finally, the team distributes those login keys to the developers or apps that need them.
The intermediate node then forwards the client traffic to the backend server over a private network. In simple setups, the node only checks source IP addresses and target port numbers. In deeper setups, the node also terminates TLS traffic and inspects standard HTTP headers. The backend server receives the request, checks the user key, and opens a session.
What native network routing solves and what it misses
This traditional design solves several major network problems for growing engineering teams right away. First, it hides internal server IP addresses from the public internet and outside networks. Second, it gives admins one central place to manage firewall rules and network allowlists. Third, it helps distribute heavy traffic loads across multiple backend servers without changing client settings.
Still, standard network routing and static backend roles leave a major operational gap open. The network node only decides which machine can open a path to the server. Meanwhile, the native backend role only checks who logs in at the start of a session. Neither layer inspects what individual SQL statements, shell commands, or API requests do in flight.
Once a user logs in with a shared role, that keeps the session active and trusted. A developer with read access can still run a query that pulls thousands of customer emails. A tired engineer with write access can accidentally drop a production table during a routine fix. Standard network logs only show that packets moved between two IP addresses at a certain time.
Proxy-Based Access + Zero Trust Architecture: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing sensitive data and permissions in flight
Teams often try to fix this gap by creating dozens of tiny, restricted backend roles. Admins spend hours writing custom permission rules for every single table, view, and internal service. When a developer needs to fix a live bug, they must ask for a temporary role upgrade. An admin then has to manually grant the role and remember to revoke it later.
Even with strict roles, raw data still flows back to the client screen in plain text. If a table holds phone numbers, card numbers, or national IDs, a valid query returns them all. Native network routers cannot tell the difference between safe metadata and sensitive personal records inside a query response. To control actions and rewrite matched fields in results, teams need checks at the command level.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between a forward and reverse setup?
A forward node sits in front of clients and sends their requests out to outside servers. A reverse node sits in front of backend servers and takes requests from outside clients.
Does network routing replace backend user roles?
No, network routing only controls which machines can send traffic to a target server port. You still need identity checks and permission rules to control what users do inside the server.
Why do teams avoid sharing static database keys across apps?
Shared keys make it impossible to see which specific person ran a harmful query in the logs. If a shared key leaks, an admin must rotate it everywhere at once, which can break apps.
Short role checks help teams work fast. Simple rules make each review clear. Good logs keep every team safe. Scoped keys stop bad changes early.