Reverse Proxy Audit Playbook

Reverse proxies are often introduced for good reasons: cleaner exposure, TLS termination, central routing, virtual hosting, rate limiting, and easier backend changes. Over time, though, they can become a layer that everyone depends on and few people fully review.

That is where problems start.

A reverse proxy can quietly become a blind spot when teams assume it is enforcing rules that are no longer true, when applications trust headers too broadly, or when direct backend access still exists outside the proxy path.

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

---

What you are really reviewing

Do not review a reverse proxy as just a server process or a config file. Review it as a trust broker between the internet, your internal services, and your observability stack.

A useful mindset is:

• The proxy receives untrusted traffic
• The proxy rewrites, forwards, or drops parts of that traffic
• Backend services may trust what the proxy says
• Your logs and alerts may depend on what the proxy records

If any of those assumptions are wrong, the proxy can hide the real problem instead of containing it.

---

Step 1: Map the request path end to end

Before reading directives or YAML, draw the real flow of a request.

Include:

• Public DNS names
• Public listener ports
• TLS termination points
• Reverse proxy instances
• Load balancers or CDN layers in front
• Backend services and ports
• Health check paths
• Internal admin endpoints
• Logging and metrics destinations

A simple map should answer these questions:

Where does TLS start and stop?

You need to know whether TLS is terminated:

• At a CDN
  n- At the reverse proxy
• At both the proxy and the backend
• Only at the backend

If traffic is decrypted and forwarded internally, verify whether that is intentional and whether the internal segment is actually trusted.

Can backend services be reached directly?

This is one of the most important checks.

If a backend app is accessible:

• Directly from the internet
• From broad internal networks
• From another shared environment
• Through a forgotten alternate listener

then the proxy may not be the control point everyone thinks it is.

Are there multiple paths to the same app?

It is common to find:

• app.example.com through the proxy
• A direct node port or container port still exposed
• A separate admin hostname with weaker controls
• Old test domains still resolving to live systems

That is exactly how visibility gaps form.

---

Step 2: Identify backend trust assumptions

Applications behind reverse proxies often trust proxy-provided information such as:

• Client IP address
• Original scheme (http vs https)
• Host header
• Authentication headers
• Client certificate details
• Path rewrites or prefix stripping

Document what each backend assumes the proxy is doing for it.

Examples:

• The app assumes X-Forwarded-Proto: https means the user came over TLS
• The app uses X-Forwarded-For for rate limiting or audit logs
• The app trusts an authentication header inserted by the proxy
• The app expects /api to be stripped before routing

Once those assumptions are listed, verify them one by one.

---

Step 3: Review forwarded headers carefully

Forwarded headers are one of the easiest places for a reverse proxy to become dangerous without looking obviously broken.

Common headers include:

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

What to check

Does the proxy overwrite or append correctly?

If the proxy simply passes client-supplied headers through unchanged, a user may be able to spoof:

• Source IPs
• TLS status
• Host values
• Internal routing assumptions

The expected behavior depends on the stack, but in general you want a clearly defined policy for whether headers are:

• Dropped
• Normalized
• Rebuilt from trusted connection metadata
• Appended only when the upstream source is trusted

Does the application trust these headers only from known proxies?

Many frameworks support a trusted proxy list. If that list is too broad, the app may accept spoofed headers from places that are not actually trusted.

Review whether the application trusts:

• All internal addresses
• Entire RFC1918 ranges
• Every hop in a container network
• Any host that can reach the service

That trust model is often much wider than intended.

Are logs showing the real client IP or just the last hop?

If the logging path is inconsistent, investigations become messy fast. Compare:

• Proxy access logs
• Backend application logs
• Rate limiting identity sources
• WAF or CDN logs if present

If every system reports a different source IP, the review is not complete.

---

Step 4: Check host and routing behavior

Reverse proxies make routing look simple, but subtle host and path behavior can create confusion or exposure.

Review:

• Host-based routing rules
• Wildcard host matches
• Default virtual hosts
• Path prefix matching
• Rewrite and redirect logic
• Catch-all backends

Risk patterns to look for

Unexpected default backends

If an unknown host header lands on a default application, the proxy may expose a service that should only respond to named hosts.

Overly broad wildcard routing

A wildcard such as *.example.com can be useful, but verify what happens to unplanned subdomains and stale DNS records.

Rewrite rules that change security context

Path rewrites can break assumptions in applications that rely on prefixes for:

• Access control
• Session cookie scoping
• API version routing
• Static asset separation

Make sure the backend understands the path it actually receives.

---

Step 5: Verify TLS behavior, not just certificate validity

A certificate can be valid while the overall TLS design is still weak or misleading.

Check:

• Where TLS terminates
• Whether backend re-encryption is required
• Whether backend certificate validation is enabled
• Whether internal upstream names match certificates
• How redirects from HTTP to HTTPS are handled

Important questions

Does the proxy validate backend certificates?

If the proxy re-encrypts to HTTPS upstream but does not validate the backend certificate properly, you may have encryption without meaningful identity assurance.

Is X-Forwarded-Proto aligned with reality?

Applications often use this header for:

• Secure cookie flags
• Redirect generation
• Absolute URL building
• Mixed-content prevention logic

If the proxy sets it inconsistently, the app may behave insecurely or unpredictably.

Are old protocols or ciphers still enabled for compatibility reasons?

This tutorial is not a generic TLS hardening guide, but if legacy support remains enabled, confirm it is still necessary and documented.

---

Step 6: Review authentication and identity injection

Some reverse proxies perform authentication directly or inject identity headers after an upstream auth step.

Examples include headers carrying:

• Username
• Email
• Group membership
• SSO claims
• Client certificate attributes

What to verify

• Which headers are added by the proxy
• Whether the backend rejects the same headers from non-proxy sources
• Whether direct backend access bypasses the auth layer
• Whether error paths or alternate routes skip identity checks

A backend should never blindly trust a header unless it is impossible for an untrusted source to send it.

That means your network exposure review and your header trust review must agree.

---

Step 7: Inspect timeouts, buffering, and error handling

Not every blind spot is about unauthorized access. Some are about reliability failures that the proxy masks until an outage is already underway.

Review:

• Request timeout values
• Upstream connect and read timeouts
• Idle keepalive behavior
• Buffering settings
• Maximum header and body sizes
• Retry logic
• Custom error pages and fallback routing

Why this matters

A reverse proxy can hide backend distress by:

• Retrying requests in ways the app cannot tolerate
• Returning generic 502 or 504 errors without context
• Serving stale or misleading fallback content
• Buffering requests so heavily that latency is obscured

If your troubleshooting starts and ends at “the app was slow,” the proxy may be concealing the failure mode.

---

Step 8: Confirm observability is complete and consistent

A reverse proxy should improve visibility, not reduce it.

Check whether you can answer these questions from logs and metrics:

• Which client made the request?
• Which hostname and path were requested?
• Which backend handled it?
• What status code was returned?
• How long did the proxy wait on the upstream?
• Was the request rejected by the proxy or by the app?
• Can you correlate a proxy log line to an application log line?

Logging review checklist

• Access logs enabled where needed
• Error logs capture routing and upstream failures
• Request IDs are propagated to backends
• Sensitive headers are not logged carelessly
• Log formats include enough context for investigations
• Rotation and retention are defined

Metrics review checklist

• Per-backend error rates
• Upstream latency distributions
• Active connections
• Rejected requests by reason
• TLS handshake failures
• Health check status changes

A proxy becomes a blind spot when it is the busiest component in the request path but records too little detail to explain incidents.

---

Step 9: Test health checks and failover behavior

Health checks can accidentally create a false sense of safety.

Verify:

• What path the health check uses
• Whether it tests real dependencies or just returns 200 OK
• Whether authentication or routing differs from real traffic
• How quickly a bad backend is removed and restored
• Whether failover changes headers, sessions, or path handling

Common issue

A backend can pass a shallow health check while failing real user requests due to:

• Database dependency issues
• Broken auth integrations
• Large request handling failures
• Path rewrite mismatches
• Host header sensitivity

A good review asks whether the health signal actually reflects user reality.

---

Step 10: Look for hidden admin surfaces

Reverse proxies often expose or protect operational endpoints such as:

• Metrics pages
• Dashboard interfaces
• Status endpoints
• Certificate management panels
• Internal route discovery APIs

Review whether these are:

• Bound only to local or management networks
• Protected by authentication
• Logged adequately
• Accidentally reachable through the same public listener

This matters especially in environments where convenience features were enabled during setup and never revisited.

---

Step 11: Validate direct backend isolation with testing

Do not stop at config review. Test the architecture.

From a controlled host, try to determine whether the backend can be reached without the reverse proxy.

Examples of questions to answer:

• Can the backend port be reached directly?
• Does it answer with the same application?
• Does it accept spoofed forwarded headers?
• Does it behave differently without the proxy?
• Does authentication still hold if requests bypass the proxy?

You are not attacking the system. You are verifying that the intended control boundary is real.

---

Step 12: Review change ownership and drift risk

A reverse proxy setup can start clean and become risky through operational drift.

Ask:

• Who owns routing rules?
• How are config changes reviewed?
• Are temporary exceptions removed?
• Are old backends and domains retired cleanly?
• Is there a source of truth for active listeners and routes?

Drift indicators

• Commented-out legacy rules left in place
• Duplicate route definitions across environments
• Emergency bypasses that became permanent
• Test hostnames still mapped to production services
• Unused upstreams that still resolve and respond

Blind spots often come from stale assumptions, not from dramatic misconfigurations.

---

A compact reverse proxy review checklist

Use this as a practical audit baseline:

Exposure

• Enumerate all public and internal listeners
• Confirm whether backends are directly reachable
• Identify alternate hostnames and stale DNS entries

Trust

• Document which headers backends trust
• Restrict trusted proxy sources explicitly
• Ensure identity headers cannot be supplied by untrusted clients

Routing

• Review default hosts, wildcard matches, and catch-all behavior
• Verify rewrites and prefix handling against application expectations
• Confirm admin endpoints are not exposed unintentionally

TLS

• Verify termination and re-encryption design
• Validate upstream certificates where HTTPS is used internally
• Confirm scheme headers match actual transport behavior

Reliability

• Review timeouts, retries, buffering, and error pages
• Test health checks for realism
• Confirm failover does not alter security assumptions

Visibility

• Ensure proxy and app logs can be correlated
• Capture upstream latency and error metrics
• Record enough request context for incident analysis

---

What a good outcome looks like

A strong reverse proxy review does not end with “the config loads fine.” It ends when you can say:

• We know exactly which systems trust the proxy
• We know exactly which headers are authoritative
• We know backends cannot be reached in unintended ways
• We can observe failures at the proxy and application layers clearly
• We have tested the boundaries instead of assuming them

That is the difference between a reverse proxy as a useful control layer and a reverse proxy as an unexamined point of failure.

---

Final thought

Reverse proxies are easy to normalize because they sit between users and applications so quietly. But that quietness is exactly why they deserve periodic review.

When the proxy becomes the place where identity, transport, routing, and observability all intersect, small mistakes compound quickly. A disciplined audit helps you catch those mistakes while they are still design issues, not incident report findings.