Reverse Proxy Review Playbook

Reverse proxies often sit in front of the most important applications in an environment, yet they are frequently reviewed only when something breaks. That is risky.

A reverse proxy is not just a performance or routing component. It is often a security boundary, a policy enforcement point, and a source of identity and request context for backend services. If its configuration is inconsistent, over-trusting, or poorly observed, the proxy can quietly become a blind spot.

This tutorial walks through a practical review process you can use before that happens.

Why reverse proxy reviews matter

Many backend applications assume the reverse proxy is doing several jobs correctly:

• terminating TLS
• normalizing requests
• setting client IP headers
• enforcing host and path routing
• applying authentication or access checks
• generating reliable logs

The problem is that those assumptions are not always verified. Over time, exceptions get added:

• a temporary direct backend rule becomes permanent
• a trusted header is accepted from the wrong source
• an old virtual host remains active
• health check paths bypass controls more broadly than intended
• logs capture the proxy's IP instead of the real client

None of these issues look dramatic on their own. Together, they create conditions where investigations become harder and controls become easier to bypass.

Start with the architecture, not the config file

Before reading directives or YAML, map the actual request path.

Questions to answer first

• Where does traffic originate: internet, CDN, load balancer, VPN, internal clients?
• Which systems can send traffic to the reverse proxy?
• Which systems can send traffic directly to the backend?
• Where is TLS terminated, and is it re-established upstream?
• Which component sets X-Forwarded-For, X-Real-IP, Forwarded, or identity headers?
• Which backend applications trust those headers?

A simple diagram is often more useful than a long config dump. If the team cannot clearly explain the path of a request, that uncertainty is already a finding.

Define the trust boundary explicitly

One of the biggest reverse proxy mistakes is treating all incoming traffic as if it came from a trusted upstream.

The trust boundary should be explicit:

• Which source IPs are allowed to send proxy traffic?
• Which upstreams are allowed to supply forwarding headers?
• Which listeners are public versus internal?
• Which backends should trust the proxy's identity assertions?

If a backend trusts X-Forwarded-For or X-Forwarded-Proto, but those headers can be supplied by untrusted clients, logs and security logic can be manipulated.

Review header handling carefully

Header behavior is where many blind spots begin.

Focus on these header categories

1. Client identity headers

Common examples:

• X-Forwarded-For
• X-Real-IP
• Forwarded

Review whether the proxy:

• appends versus replaces values
• accepts these headers from clients directly
• trusts them only from known upstreams
• passes a clean, predictable format to applications

If multiple proxies exist in the path, decide how the chain should look and who is authoritative.

2. Scheme and host headers

Common examples:

• X-Forwarded-Proto
• X-Forwarded-Host
• Host

Applications often use these values for:

• redirect generation
• cookie security decisions
• absolute URL generation
• tenant routing

A mismatch here can create login loops, insecure redirects, or routing confusion. In some environments it can also affect authorization logic.

3. Identity and auth headers

Common examples:

• X-Remote-User
• X-Authenticated-User
• X-User-Email
• Authorization

If the proxy injects identity information after authentication, confirm that backends only trust those headers from the proxy itself. A backend reachable directly from another network segment may accept forged identity headers if this trust model is weak.

Check for direct backend exposure

This is one of the most important review steps.

A reverse proxy may enforce:

• authentication
• rate limiting
• request filtering
• WAF rules
• path restrictions
• standardized logging

If the backend remains reachable through another route, those controls may be bypassed.

Validate backend access paths

Review whether the backend is reachable:

• directly from the internet
• from office or VPN ranges
• from adjacent internal segments
• through old load balancer listeners
• through alternate ports or management interfaces

This does not mean every backend must be completely isolated, but exposure should be intentional. If a direct path exists, document why it exists and which equivalent controls apply there.

Audit routing logic and default behavior

Routing sprawl is common in mature proxy deployments.

Look for:

• catch-all virtual hosts
• broad wildcard hostnames
• fallback upstreams
• regex rules that match more than intended
• path rewrites that change application assumptions
• inactive but still loaded site definitions

A strong review asks not just "does the right route work?" but also:

• What happens when the host header is unknown?
• What happens when the path is malformed?
• What happens when a request partially matches several rules?

Default behavior matters. A safe default is often to reject the request clearly instead of forwarding it to a generic backend.

Review TLS as a traffic design question

Do not limit TLS review to certificate expiry.

For reverse proxies, TLS design affects what the backend can trust and what data may be exposed internally.

Review these TLS points

• Where is TLS terminated?
• Is traffic re-encrypted to the backend?
• Are upstream certificates validated properly?
• Are internal names and certificates managed consistently?
• Are HTTP-to-HTTPS redirects predictable and complete?
• Do backends know whether the original connection was secure?

If the proxy terminates TLS and forwards plaintext internally, understand whether that internal segment is truly controlled. In some environments that may be acceptable; in others it creates unnecessary exposure.

Also verify that backend applications do not make flawed assumptions about secure cookies or redirect behavior because X-Forwarded-Proto is inconsistent.

Compare proxy policy with application expectations

A reverse proxy can drift away from what the application expects.

For example:

• the app expects /admin to be blocked externally, but a new route exposes it
• the app expects a normalized host value, but the proxy forwards arbitrary hosts
• the app expects large uploads, but the proxy truncates or rejects them inconsistently
• the app expects websocket support, but timeout settings break sessions in ways that resemble app instability

This is why a reverse proxy review should include both infrastructure and application owners. Security issues often hide in the gap between those two perspectives.

Validate logging quality, not just log existence

A reverse proxy can make observability better or worse.

Many teams log requests, but the logs are not reliable enough during an incident.

Logging checks that matter

Confirm whether logs capture:

• real client IP and not just the nearest hop
• host header and requested path
• upstream target or backend name
• response status
• TLS and protocol details where useful
• request IDs or correlation IDs
• timing fields for upstream latency and failures

Also review whether logs distinguish between:

• proxy-generated responses
• backend-generated responses
• connection failures
• timeout conditions
• rejected hostnames or malformed requests

If all failures look the same in logs, the reverse proxy becomes hard to investigate under pressure.

Test failure paths and edge conditions

Healthy-path testing is not enough.

Reverse proxies reveal their real behavior during:

• backend timeouts
• partial upstream outages
• invalid host headers
• oversized requests
• upgrade requests such as websockets
• malformed paths or encodings

Run simple tests and inspect both responses and logs.

Practical examples

• Send a request with an unknown Host header.
• Send a request directly to the backend if network policy allows testing.
• Send a request with spoofed X-Forwarded-For from an untrusted source.
• Trigger an upstream timeout in a non-production test path.
• Verify whether error pages leak backend details.

You are not trying to break the service. You are checking whether unexpected input causes the proxy to fail open, fail ambiguously, or fail without visibility.

Review administrative and operational hygiene

Blind spots also emerge from how the proxy is operated.

Check for:

• stale site definitions or disabled apps still present on disk
• inconsistent configuration across nodes
• undocumented emergency rules
• manual edits without version control
• reload behavior that applies partial changes unpredictably
• certificates and keys stored with weak permissions

A reverse proxy with good technical settings can still become risky if operations are ad hoc.

Build a practical review checklist

Use a repeatable checklist so reviews are not based on memory.

Example checklist

Trust and exposure

• Identify all inbound sources.
• Verify who may set forwarding headers.
• Confirm whether backends are directly reachable.
• Document public, internal, and management listeners.

Routing and request handling

• Review host and path matching rules.
• Confirm safe default behavior for unknown hosts.
• Review rewrites, redirects, and fallback routes.
• Test malformed and edge-case requests.

TLS and upstream security

• Confirm where TLS terminates.
• Verify upstream certificate validation.
• Check secure handling of original scheme information.
• Review internal plaintext exposure risk.

Identity and headers

• Verify how client IP is derived.
• Replace or sanitize untrusted forwarding headers.
• Review auth and identity header trust.
• Confirm backend applications trust only the intended proxy path.

Logging and monitoring

• Validate request logs contain actionable fields.
• Distinguish proxy errors from backend errors.
• Confirm metrics exist for upstream failures and latency.
• Ensure request correlation is possible across layers.

Common review findings

In real environments, these issues appear often:

• backends accessible from internal networks without equivalent controls
• X-Forwarded-For trusted from any client
• wildcard virtual hosts forwarding unknown domains to real applications
• logs storing only the proxy IP
• authentication headers passed to services that should not receive them
• old routes left active after migrations
• upstream TLS validation disabled for convenience

These are not exotic flaws. They are normal operational drift. That is exactly why they deserve routine review.

A simple review workflow for teams

If you want this to become a habit rather than a one-time exercise, keep the process lightweight:

1. Diagram the request path.
2. Inventory listeners, routes, and upstreams.
3. Verify trust assumptions around headers and identity.
4. Test direct backend reachability.
5. Review logs for incident usefulness.
6. Test failure and default behavior.
7. Record exceptions and owners.

This approach works whether you use Nginx, HAProxy, Apache HTTP Server, Traefik, Envoy, or a managed edge platform. The product matters less than the trust model and the review discipline.

Final thought

A reverse proxy becomes a blind spot when teams assume it is "just forwarding traffic." In practice, it shapes identity, encryption, routing, and visibility for every application behind it.

Review it like a control plane, not a convenience layer. If you can clearly explain what it trusts, what it rewrites, what it exposes, and what it logs, you are far less likely to discover hidden gaps during an incident.