Trusted Proxies
You set up trusted proxies by adding known load balancer IP addresses to your app settings. This rule tells your server which upstream hosts can pass real client IP headers. Many teams trust every local network address just to make traffic work fast. Broad network rules let attackers fake their IP addresses and bypass rate limits. When any host can write forwarding headers, your security logs lose all value. How trusted proxies work in app networks Web apps often sit behind load balancers or
Trusted Execution Environments (TEE): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up trusted proxies by adding known load balancer IP addresses to your app settings. This rule tells your server which upstream hosts can pass real client IP headers. Many teams trust every local network address just to make traffic work fast. Broad network rules let attackers fake their IP addresses and bypass rate limits. When any host can write forwarding headers, your security logs lose all value.
How trusted proxies work in app networks
Web apps often sit behind load balancers or content delivery networks. When a user sends a request, the load balancer takes the traffic first. The load balancer then sends that request to the backend web server. Because of this hop, the web server only sees the load balancer IP address. To save the real user IP, the load balancer adds a forwarding header. The backend app reads this header to find out who sent the request. If the app trusts every incoming header, any user can send a fake header. By setting up trusted proxies, you give the app a strict allowlist of IPs. The app checks the direct sender IP against this safe list first. If the sender is on the list, the app reads the forwarding header. If the sender is not on the list, the app ignores the header.
How to set up a safe IP list
First, map out every network hop that sits in front of your app. Find the exact IP ranges for your load balancers and cloud routers. Put only those specific subnets into your web server settings. Next, decide how many network hops sit between the user and your code. Tell your server to count back that exact number of hops in the header. When a request passes through two load balancers, the header holds two IP addresses. Your app should read the right entry from the end of that list. Never read the very first IP in the header unless you control every hop. Attackers can add fake IPs to the start of the header before sending traffic. Also, set up cloud firewall rules to block direct traffic to your backend servers. Only your load balancers should have permission to talk to the app ports. When cloud IPs change, update your server list right away to avoid broken logs.
What network header rules leave open
A good IP allowlist stops outside users from faking their network address. It helps your app log the right client IP and apply basic rate limits. Still, network header checks only tell you where a packet came from. They do not check who the user is or what their commands do. Once traffic passes the network check, the backend app runs the request as sent. If an engineer or service has broad permissions, header rules will not stop bad queries. A valid internal host can still run a drop table command by mistake. Network rules also cannot mask sensitive fields like emails, phone numbers, or card numbers. They decide which host can forward traffic, not what happens inside the session. Teams still need a way to check individual commands and protect data in flight.
Trusted Execution Environments (TEE): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What happens if I trust all upstream addresses?
Any user on the internet can send a fake forwarding header to your app. They can trick your server into thinking they are on your local network. This lets them bypass IP blocks, rate limits, and location rules.
How does hop counting work with multiple load balancers?
Each load balancer adds the previous sender IP to the end of the header. Your app starts at the right side of the list and counts backward. It stops at the first IP address that is not on your safe list.
Should I use IP addresses or hostnames for my safe list?
Always use static IP addresses or CIDR subnet ranges for your safe list. Looking up hostnames on every web request slows down your app and adds risk. Static subnet ranges let the server check each packet right away.