Reverse proxies solve problems — and create assumptions

A reverse proxy often starts as a practical fix. You want TLS termination, simpler routing, centralized authentication, caching, rate limiting, or a cleaner way to publish internal services. Over time, that proxy becomes the front door for multiple applications.

That is where risk grows.

Once a reverse proxy sits between users and applications, it begins to shape trust. It may decide which hostnames are valid, which headers are passed through, which client IP address is recorded, where authentication happens, and what the upstream app is allowed to see. If nobody reviews those decisions carefully, the proxy can become a blind spot: critical enough to influence security, but familiar enough that teams stop questioning it.

This tutorial walks through a practical review process you can apply to NGINX, HAProxy, Traefik, Apache, Envoy, cloud load balancers, or mixed stacks. The goal is not to rebuild your platform. The goal is to verify that the proxy is doing exactly what you think it is doing.

What a good reverse proxy review should answer

Before looking at directives or dashboards, define the questions you need answered:

• Where does trust start and stop?
• Who is allowed to connect to the proxy?
• Which client attributes are accepted, rewritten, or discarded?
• How does the proxy choose an upstream?
• What happens when an upstream fails, times out, or returns an error?
• Which events are logged at the proxy layer versus only at the app layer?
• Which controls exist at the edge, and which are only assumed to exist?

If your review cannot answer those clearly, the setup is already too opaque.

Step 1: Map the real traffic path

Start with the path a request actually takes, not the path shown in an architecture diagram.

A typical chain may look like this:

1. Client browser or API consumer
2. CDN or DDoS filtering layer
3. Internet-facing load balancer
4. Reverse proxy
5. Internal service mesh or sidecar
6. Application server

In some environments, the reverse proxy is also the ingress controller, WAF, auth gateway, and TLS terminator. In others, it is only one hop in a larger chain.

Document:

• Every hop before the application
• Which layer terminates TLS
• Which layer injects identity or forwarding headers
• Which layer rewrites URLs or hostnames
• Which layer performs health checks
• Which layer can block, retry, cache, or redirect traffic

This sounds basic, but many blind spots begin because teams review only one layer. For example, the application team may trust X-Forwarded-For because the reverse proxy sets it, without realizing a CDN or external load balancer can also influence the same data.

Review output to produce

Create a simple table with columns like:

• Hop
• Public or internal
• TLS terminated here?
• Headers added here?
• Access control here?
• Logs stored here?

That table becomes the foundation for the rest of the review.

Step 2: Define the trust boundary explicitly

The most important review question is this: what does the upstream application trust because the reverse proxy told it to?

Common examples include:

• Client IP address
• Original protocol (http vs https)
• Original host
• User identity headers from SSO or auth middleware
• Country or geo headers from a CDN
• Request path after rewriting

If the upstream app trusts these values, verify:

• Only approved proxy layers can send traffic to the app
• The app does not trust those headers from arbitrary clients
• Older proxy paths or bypass paths do not exist
• Internal networks are not treated as automatically trusted without justification

A common failure pattern

A service trusts X-Forwarded-For and X-Forwarded-Proto because traffic is expected to come from the reverse proxy. Later, a maintenance path exposes the service directly on an internal subnet. Another internal system can now send forged headers, and the app treats them as legitimate.

That is not a reverse proxy bug. It is a trust-boundary review failure.

What to verify

• Upstream apps restrict trusted proxy IP ranges where supported
• Direct access to upstream services is blocked unless explicitly required
• Security decisions are not made from spoofable headers alone
• Emergency or legacy paths are documented and controlled

Step 3: Audit forwarded and accepted headers

Headers are where reverse proxy misunderstandings become dangerous.

Your review should separate headers into three groups:

1. Headers accepted from the client
2. Headers generated or overwritten by the proxy
3. Headers consumed by the upstream app

High-value headers to examine

Pay special attention to:

• X-Forwarded-For
• X-Real-IP
• Forwarded
• X-Forwarded-Proto
• X-Forwarded-Host
• Host
• X-Original-URI
• X-Forwarded-Prefix
• Authentication or identity headers such as X-User, X-Email, Authorization, or SSO-specific fields

Review questions

• Does the proxy append to or replace forwarding headers?
• Can a client supply a header that the app later treats as trusted?
• Are duplicate headers possible?
• Are identity headers stripped before being recreated by the auth layer?
• Are host headers validated against expected domains?

Why this matters

A reverse proxy often acts as a translator between the internet and internal services. If translation rules are loose, upstream logic may behave unpredictably. That can break rate limits, IP-based controls, audit trails, secure redirects, or access decisions.

Practical review method

For each published service, test requests with:

• A normal request
• A spoofed X-Forwarded-For
• A modified Host header
• Repeated forwarding headers
• Unexpected identity headers

Then verify:

• What appears in application logs
• What appears in proxy logs
• Whether redirects stay on approved domains
• Whether auth behavior changes unexpectedly

Step 4: Check host, path, and routing rules for overlap

Reverse proxies usually route traffic by hostname, path, SNI, or a combination of those. Over time, these rules can become messy.

Review for:

• Overlapping path prefixes
• Catch-all virtual hosts
• Default backends that should not be reachable
• Wildcard hostnames with broad scope
• Rewrite rules that change request meaning
• Priority order that sends traffic somewhere unexpected

Questions worth asking

• If a request arrives with an unknown hostname, where does it go?
• If two paths match, which backend wins?
• Can an internal admin path become reachable because of a broader public route?
• Do redirects preserve the intended host and scheme?

Example blind spot

A team adds /api/ and /api/internal/ routes. The broader rule is evaluated first, so internal traffic quietly lands on the public backend path. Functionality appears normal, but monitoring, auth logic, or request filtering may now differ from the intended design.

The issue is not always exposure. Sometimes the risk is silent policy drift.

Step 5: Review TLS behavior, not just certificate status

Many reverse proxy reviews stop at “the certificate is valid.” That is not enough.

You want to know:

• Where TLS terminates
• Whether traffic is re-encrypted to the upstream
• Whether upstream certificates are validated
• Whether internal plaintext segments are intentional and documented
• Which TLS versions and ciphers are allowed at the edge
• Whether redirect logic reliably enforces HTTPS

Common review gaps

• TLS is terminated at the proxy, but traffic to upstream apps is plaintext across shared infrastructure
• Upstream TLS exists, but certificate validation is disabled for convenience
• Mixed redirects cause users or services to hit both HTTP and HTTPS paths
• Health checks use a weaker path than normal production traffic

What to verify in practice

• The intended TLS policy matches the real data path
• Backend certificate checks are enabled where they should be
• Internal exceptions are documented with rationale
• HSTS or HTTPS enforcement behavior is consistent for browser-facing services

The goal is not maximum complexity. The goal is avoiding false confidence.

Step 6: Make sure logs preserve security context

When incidents happen, reverse proxy logs often become the bridge between network behavior and application behavior. If the proxy logs too little, you lose context. If it logs inconsistently, correlation becomes painful.

Minimum fields worth reviewing

At the proxy layer, confirm whether you capture:

• Timestamp with timezone or normalized format
• Source IP as seen by the proxy
• Effective client IP after trusted forwarding logic
• Hostname requested
• Request method and path
• Response status
• Upstream target
• Upstream status or response time
• TLS protocol details where useful
• Request ID or correlation ID

Questions to ask

• Can you distinguish a proxy-generated error from an upstream error?
• Can you tie a proxy log line to an app log line?
• Are blocked requests logged differently from successful ones?
• Do logs survive if the upstream is unavailable?
• Are sensitive headers or tokens being logged accidentally?

Blind spot example

If your application only records the proxy IP and the proxy only records the backend name, neither layer alone may preserve the full client-to-service story. During abuse investigation, you end up guessing.

Step 7: Review failure modes and degraded behavior

A secure-looking reverse proxy can still become dangerous during partial failure.

Review what happens when:

• An upstream is slow
• DNS resolution fails
• A health check marks all backends down
• The auth provider is unavailable
• The proxy reloads configuration
• Rate limiting state is reset
• A fallback backend responds unexpectedly

Defensive questions

• Does the proxy fail open or fail closed for authentication-dependent paths?
• Does a timeout become a 502, a retry, or a route to another backend?
• Can cached content appear after access should have been revoked?
• Does maintenance mode expose environment details?

Why this matters

Many blind spots are not visible during healthy operation. They emerge only when the proxy has to choose between availability and strict enforcement. You want to know that choice before an outage, not during one.

Step 8: Verify admin surfaces and configuration change paths

The proxy itself may expose management APIs, dashboards, stats pages, or dynamic config sources.

Review:

• Admin interfaces bound to network-accessible addresses
• Weakly protected dashboards
• Dynamic providers such as container labels, service discovery, or key-value stores
• CI/CD jobs that deploy proxy config changes
• Certificate automation permissions

Important angle

A reverse proxy can become a security blind spot not only because of traffic handling, but because too many systems are allowed to influence its behavior.

If service owners can create routes dynamically through labels or annotations, ask:

• Who can publish a new route?
• Who can attach middleware?
• Who can expose an internal service accidentally?
• Is there review or policy validation before changes go live?

This is especially important in container and Kubernetes-heavy environments.

Step 9: Test for bypass paths

A reverse proxy only helps if traffic actually goes through it.

Check for:

• Direct access to upstream ports from internal networks
• Old DNS records still pointing to backends
• Alternate load balancer listeners
• Debug ports exposed for convenience
• Services reachable through node ports or temporary firewall rules

Practical checks

• Attempt direct connections to upstream hosts from approved internal vantage points
• Review firewall and security group rules
• Compare DNS inventory with actual listening services
• Confirm that only intended layers can reach privileged app endpoints

This is one of the highest-value review steps because it reveals whether your trust assumptions hold in the real environment.

Step 10: Review caching, compression, and content handling

Not every reverse proxy caches content, but when it does, the security implications deserve attention.

Review whether the proxy:

• Caches authenticated content
• Varies cache keys correctly by host, path, or auth context
• Compresses content in a way that leaks sensitive patterns in edge cases
• Alters security headers on responses
• Strips or injects headers such as CSP, HSTS, or X-Frame-Options

Why this belongs in the review

A proxy that changes response behavior can quietly undermine application security decisions. Even if the app sets correct headers, the edge layer may override, duplicate, or remove them.

A practical reverse proxy review checklist

Use this short checklist during periodic reviews:

Trust and exposure

• All traffic paths to the app are documented
• Upstream services are not broadly reachable outside approved proxy paths
• Trusted proxy IP ranges are explicitly defined where supported
• Security decisions are not based on client-supplied spoofable headers

Header handling

• Forwarding headers are overwritten or sanitized appropriately
• Identity headers are stripped before trusted values are inserted
• Host header handling is validated
• Duplicate or conflicting headers are tested

Routing and policy

• Default routes and catch-all backends are understood
• Path and hostname match precedence is documented
• Internal-only paths are not shadowed by broader public routes
• Redirect behavior preserves intended scheme and host

TLS and upstream security

• TLS termination points are documented
• Backend encryption and certificate validation match policy
• HTTP-to-HTTPS enforcement is consistent
• Exceptions are documented and reviewed

Observability

• Proxy logs preserve client, host, route, and upstream context
• Request IDs can be correlated across layers
• Sensitive data is not logged unnecessarily
• Error handling remains visible during outages

Operations and change control

• Admin interfaces are restricted
• Dynamic configuration sources are controlled
• Routing changes are reviewed before deployment
• Periodic tests exist for bypass and header trust assumptions

Signs your reverse proxy is already becoming a blind spot

If several of these are true, your setup needs a closer review:

• Nobody can clearly explain which headers the app trusts
• Different teams assume different layers terminate TLS
• Catch-all routes exist but are undocumented
• Proxy logs are not used during incident response because they are incomplete
• There are multiple “temporary” access paths to the same service
• Config changes are pushed through automation without policy checks
• The application trusts the proxy, but the proxy trusts too many upstream signals

A sensible review workflow for real teams

You do not need a massive audit program to improve this.

A practical workflow looks like this:

1. Pick one published service

Start with a service that matters operationally. Do not begin with every route in the environment.

2. Trace one request end to end

Record headers, TLS boundaries, route selection, logs, and the upstream destination.

3. Test assumptions deliberately

Try forged headers, wrong hostnames, alternate paths, direct backend access, and failure conditions.

4. Compare intended policy with observed behavior

This is where hidden drift usually appears.

5. Turn findings into standards

If you discover one service trusts unsafe forwarding behavior, others probably do too. Create a reusable standard for trusted headers, logging fields, route defaults, and backend exposure rules.

Final thought

A reverse proxy is not just plumbing. It is a policy and trust layer.

That is why reviews should focus less on whether the service is “up” and more on whether its assumptions are still valid. If you can explain the trust boundary, route logic, header handling, TLS behavior, logging, and failure modes with confidence, the proxy is doing its job.

If you cannot, it is already becoming a blind spot.