Reverse proxies deserve a security review of their own

A reverse proxy often sits in the middle of everything important: inbound traffic, TLS termination, request routing, rate limiting, authentication handoffs, logging, and error handling. That central role is useful, but it also makes the proxy an easy place for hidden trust assumptions to accumulate.

When that happens, the reverse proxy stops being just an infrastructure component and starts becoming a blind spot.

This tutorial walks through a practical review process for reverse proxy deployments so you can identify issues before they become incidents, confusing outages, or unreliable forensic evidence.

What this review is actually trying to answer

A good reverse proxy review is not just asking whether requests reach the right backend. It is asking:

• What security decisions are being made at the proxy?
• What does the backend assume the proxy already checked?
• Can an attacker bypass, confuse, or spoof those assumptions?
• Do logs clearly show what really happened?

If you answer those questions well, you reduce the chance of quiet failures such as:

• backend services accepting direct traffic they were never meant to see
• applications trusting spoofed X-Forwarded-* headers
• TLS being terminated in a way that breaks security expectations downstream
• access controls relying on the wrong source IP
• monitoring showing only proxy health while backend failure modes go unnoticed

Step 1: Map the real request path

Before reviewing individual settings, document the actual traffic path.

For each public-facing application, write down:

1. Where the client connects first
   CDN, load balancer, WAF, reverse proxy, ingress controller, or edge appliance.

2. Where TLS starts and ends
   Is TLS terminated at the edge, re-encrypted internally, or passed through?

3. How traffic reaches the backend
   HTTP, HTTPS, gRPC, UNIX socket, loopback interface, overlay network, or internal VLAN.

4. Which systems can inject or modify headers
   CDN, gateway, ingress, service mesh sidecar, or custom middleware.

5. Which layer performs security checks
   Authentication, IP allowlisting, rate limiting, bot filtering, request size limits, or path filtering.

This simple map often exposes the first problem: teams think they have one reverse proxy, but the application is really behind several intermediaries, each changing request metadata.

Step 2: Define the trust boundary clearly

A reverse proxy is a trust boundary. Your review should make that explicit.

Ask:

• Which requests are allowed to reach the backend directly?
• Which headers are considered authoritative only when set by the proxy?
• Which backend endpoints assume they are reachable only from the proxy?
• Which internal services trust the proxy's identity without further validation?

If your architecture does not answer those questions in a documented way, the backend may be trusting traffic it should reject.

Healthy pattern

The backend accepts traffic only from approved proxy layers, and only those layers may provide identity-related forwarding headers.

Risky pattern

The backend is reachable from internal networks, container bridges, or VPN segments where unrelated systems can send requests with trusted-looking headers.

Step 3: Review forwarded headers and client identity handling

This is one of the most important parts of the assessment.

Reverse proxies commonly add or rewrite headers such as:

• X-Forwarded-For
• X-Forwarded-Proto
• X-Forwarded-Host
• Forwarded
• X-Real-IP

Applications often use these headers for:

• source IP logging
• geo or region rules
• rate limiting
• IP-based allowlists
• secure cookie behavior
• redirect generation
• scheme detection
• audit records

What to verify

1. The backend only trusts these headers from approved proxy sources

If a client can connect directly to the backend, or if another internal system can set those headers, the application may accept forged request context.

2. Header chains are parsed correctly

For X-Forwarded-For, confirm whether the application trusts:

• the leftmost IP
• the rightmost IP
• a specific proxy chain length
• only values supplied by configured trusted proxies

A wrong assumption here can corrupt logs and weaken controls based on source IP.

3. The proxy overwrites unsafe values when appropriate

If the proxy appends to untrusted client-supplied headers without a clear trust model, downstream logic may consume the wrong element.

4. The application's proxy trust configuration matches reality

Framework settings like trusted proxies, forwarded header support, or proxy protocol parsing must align with the actual deployment path.

Practical review question

If you send a request with forged X-Forwarded-For or X-Forwarded-Proto, what does the backend log and what logic does it apply?

If the answer is unclear, you likely have a blind spot.

Step 4: Check whether the backend is exposed more than intended

Many reverse proxy deployments are designed as if the backend is private, but in practice the backend may still be reachable:

• on a host interface
• through an internal load balancer
• from a container network
• from a peered VPC or flat internal subnet
• from an administrative VPN

That exposure matters because the backend may rely on the proxy for:

• authentication enforcement
• path restrictions
• request normalization
• body size limits
• method filtering
• security headers
• rate limiting

What to review

• Can the backend be reached without the reverse proxy?
• If yes, does it still enforce the same controls safely?
• Are internal-only assumptions documented and technically enforced?
• Are admin or debug paths accessible internally but not externally?

A backend that “should only be accessed through the proxy” needs more than intention. It needs network enforcement.

Step 5: Review TLS termination and downstream security assumptions

TLS at the reverse proxy is common and often correct, but the review must verify what that choice means downstream.

Questions to answer

• Is TLS terminated at the proxy and sent as plain HTTP to the backend?
• If so, is that path sufficiently isolated?
• Does the backend know the original request was HTTPS?
• Are redirects, cookies, and security policies generated correctly based on forwarded scheme?
• Is internal re-encryption used where trust boundaries require it?

Common blind spots

Secure cookie and scheme confusion

If the application does not correctly understand that the original connection was HTTPS, it may generate insecure redirects, mis-handle callback URLs, or fail to apply secure cookie expectations correctly.

Overtrusted internal networks

Teams sometimes treat “inside the network” as equivalent to trusted transport. That assumption becomes weaker as environments become more distributed, containerized, and shared.

Certificate handling drift

If the proxy re-encrypts to the backend, verify certificate validation is actually enforced rather than disabled for convenience.

Step 6: Inspect routing, host handling, and path normalization

A reverse proxy does more than pass requests. It interprets hosts, paths, methods, and often rewrites them.

That behavior can introduce ambiguity between what the client requested and what the backend receives.

Review these areas

Host header handling

Confirm:

• which hostnames are accepted
• whether unexpected hosts are rejected or routed somewhere unsafe
• whether the backend relies on Host or X-Forwarded-Host for security-sensitive behavior

Poor host validation can affect redirects, multi-tenant routing, absolute URL generation, and in some cases cache or auth logic.

Path rewriting

Check whether the proxy:

• strips path prefixes
• rewrites application roots
• normalizes encoded characters differently from the backend
• handles duplicate slashes or dot segments in a different way

Differences between proxy and backend interpretation can create access control gaps or route confusion.

Method restrictions

Verify whether dangerous or unnecessary HTTP methods are blocked at the proxy, passed through intentionally, or assumed to be filtered elsewhere.

Step 7: Review authentication placement and failure behavior

In many deployments, authentication is split across layers.

Examples include:

• SSO handled at the edge, app session in the backend
• mTLS at a gateway, user auth at the application
• basic auth or token checks at the proxy for specific paths

This can be safe, but only if responsibility is clear.

Ask these questions

• Which layer decides whether a request is authenticated?
• What identity data is forwarded to the backend?
• Can a client fake that identity data if the backend is reached another way?
• What happens if the auth service is slow, unavailable, or bypassed?
• Does the backend fail closed or quietly trust missing headers?

Warning sign

The proxy injects headers like user ID, email, or group membership, and the backend trusts them without verifying request origin.

That pattern is common, convenient, and dangerous if backend reachability is broader than intended.

Step 8: Make logging good enough for investigation, not just operations

A reverse proxy can improve visibility, but it can also fragment it.

If proxy logs and backend logs cannot be correlated, incident review becomes guesswork.

Minimum review points

• Are request IDs generated and forwarded consistently?
• Do logs record both proxy-facing and backend-facing status outcomes where useful?
• Is the source IP recorded in a trustworthy way?
• Are TLS details, hostnames, and upstream targets logged where operationally appropriate?
• Are denied requests visible, or do you only log successful routing?

What strong logging looks like

A single request can be traced across:

• client-facing entry point
• proxy decision
• upstream selection
• backend response
• final client status

Without that, the reverse proxy may hide whether a failure came from routing, auth middleware, TLS mismatch, header trust issues, or the application itself.

Step 9: Review error handling and health checks

A proxy that appears healthy can still mask application failures or security regressions.

Check health checks carefully

• Do they test only TCP reachability, or real application readiness?
• Do they bypass auth and route logic in a way that hides misconfiguration?
• Do they succeed even when the backend is serving incorrect content or redirect behavior?

Check error responses

• Are backend failures exposed clearly enough for operators?
• Does the proxy rewrite errors in ways that remove useful diagnostics?
• Are retry behaviors safe for the application and request type?

A review should confirm that health signals reflect reality instead of just proving that the proxy can still connect to something.

Step 10: Test assumptions with simple adversarial checks

A review is stronger when it includes targeted validation, not just configuration reading.

Use a controlled test plan to answer practical questions such as:

• What happens if a forged forwarding header is supplied?
• What does the backend log as the client IP?
• Can the backend be reached directly from any internal segment?
• Does the application behave differently when bypassing the proxy?
• What happens if an unexpected host header is sent?
• Are protected paths still protected if path encoding or rewriting changes?

This is not about aggressive testing. It is about confirming that trust assumptions survive real requests.

A compact reverse proxy review checklist

Use this checklist during design reviews, change reviews, or periodic audits.

Architecture and trust

• Document every hop between client and backend
• Identify all layers that modify request metadata
• Define which layer is authoritative for identity and scheme
• Confirm backend exposure is restricted as intended

Header handling

• Review X-Forwarded-* and Forwarded behavior
• Verify trusted proxy settings in the application framework
• Ensure spoofed client-supplied values are not accepted blindly
• Confirm source IP logic matches actual proxy chain design

TLS and transport

• Verify where TLS terminates
• Check whether internal cleartext transport is acceptable for the environment
• Confirm backend scheme awareness is correct
• Validate any re-encryption and certificate verification

Routing and normalization

• Review host validation rules
• Examine path rewriting and prefix stripping
• Confirm method handling is intentional
• Check for differences between proxy and backend request interpretation

Authentication and authorization

• Define where auth happens and what is forwarded
• Ensure backend trust in identity headers is justified
• Confirm direct backend access cannot bypass edge auth
• Test failure behavior for auth dependencies

Visibility and operations

• Correlate proxy and backend logs with request IDs
• Log denied and failed requests meaningfully
• Review health checks for realism
• Verify alerts distinguish proxy failure from upstream failure

Common findings that deserve immediate cleanup

Some issues are more urgent because they undermine multiple controls at once.

Prioritize these if you find them:

1. Backends reachable outside the intended proxy path
2. Applications trusting forwarded headers from untrusted sources
3. Authentication context injected by the proxy but not origin-protected
4. TLS termination causing incorrect scheme or cookie behavior
5. Logs that cannot reliably identify the real client or request path

Final thought

A reverse proxy is often treated as a convenience layer: routing, certificates, maybe some rate limiting. In practice, it quietly shapes trust, identity, visibility, and application behavior.

That is exactly why it should be reviewed deliberately.

If you treat the proxy as a security boundary, validate what the backend believes about it, and test those assumptions with simple checks, you can catch the kinds of quiet design flaws that otherwise remain hidden until an outage, an investigation, or an attacker finds them first.