Reverse Proxy Review Checklist: Finding Hidden Trust Gaps Before They Turn Into Risk

A reverse proxy often starts as a practical solution. You put it in front of applications to terminate TLS, centralize routing, add security headers, or simplify certificate management. Over time, it becomes part of everything.

That is exactly why it deserves periodic review.

A reverse proxy is not just a convenience component. It is a trust boundary. Applications behind it may trust it to report the real client IP, preserve protocol details, enforce access rules, or attach identity context. If the proxy is misconfigured, every upstream service can inherit the same bad assumption.

This tutorial walks through a practical review process you can use before a reverse proxy turns into a blind spot.

---

Why reverse proxies quietly accumulate risk

Reverse proxies tend to drift into critical roles without a formal design review. A deployment that began as "put Nginx in front of the app" may later handle:

• TLS termination
• path-based routing
• header normalization
• authentication handoff
• WebSocket upgrades
• rate limiting
• IP-based access control
• request logging
• origin shielding
• caching

None of those functions are inherently unsafe. The problem is that teams often review the application and the firewall, but not the assumptions in between.

Common failure patterns include:

• upstream apps trusting spoofable headers
• incomplete logging that hides real client activity
• exposed internal routes through path rewrites
• HTTP-to-HTTPS confusion breaking secure cookie behavior
• admin endpoints reachable through alternate hostnames
• inconsistent rules across environments
• stale routes pointing at retired services

A good review is less about finding one dramatic flaw and more about identifying where trust is being granted without verification.

---

Start with a simple architecture map

Before checking directives or YAML, write down how traffic actually flows.

At minimum, map:

1. Client entry points

   • public domains
   • internal domains
   • direct IP access
   • alternate ports

2. Proxy layers

   • CDN or edge service
   • cloud load balancer
   • ingress controller
   • internal reverse proxy

3. Upstream services

   • app servers
   • admin panels
   • APIs
   • legacy services

4. Trust decisions

   • where client IP is established
   • where TLS terminates
   • where authentication happens
   • where authorization depends on headers or path rules

This map helps answer the most important review question:

Which component is trusted to tell the truth about the client and the request?

If the answer is vague, that is already a useful finding.

---

Review what the upstream application trusts

Many reverse proxy problems are really upstream trust problems.

Applications often rely on the proxy for values they cannot see directly once traffic is terminated or rewritten. That makes forwarded metadata a high-value review area.

Check these assumptions explicitly

Ask whether the application trusts the proxy for:

• client IP address
• original scheme such as HTTP vs HTTPS
• original host
• original port
• authenticated user identity
• request path prefix

Then verify how that trust is implemented.

Headers that commonly matter

Look closely at:

• X-Forwarded-For
• X-Forwarded-Proto
• X-Forwarded-Host
• Forwarded
• Host
• X-Real-IP
• identity headers such as X-Authenticated-User or X-Remote-User

Key questions:

• Does the proxy set these headers, append to them, or pass client-supplied values through?
• Does the upstream application trust them only from known proxy IPs?
• If there are multiple proxy layers, is the chain handled consistently?
• Can a client connect directly to the upstream and inject these headers?

A frequent mistake is assuming that because a header exists, it is trustworthy. It is only trustworthy if:

• the request can only reach the upstream through the approved proxy path, and
• the proxy sanitizes or reconstructs the header correctly.

---

Verify direct access to upstream services is actually blocked

One of the easiest ways for a reverse proxy to become meaningless is when the backend is still reachable directly.

If upstream services accept traffic from anywhere, an attacker may be able to bypass:

• TLS enforcement
• rate limits
• host restrictions
• authentication middleware
• request filtering
• logging controls

Review points

• Are backend ports exposed publicly or to broad internal networks?
• Do security groups, ACLs, or host firewalls restrict access to known proxy sources?
• Are health-check paths the only exceptions?
• Are there alternate listeners for debug or legacy support?

Practical test

From a network location outside the trusted proxy path, try to reach the backend directly.

If it responds, ask:

• What protections are now bypassed?
• Does it accept spoofed X-Forwarded-* headers?
• Does it behave differently than the proxied route?

This is one of the highest-value checks in the whole review.

---

Inspect header handling like a security control

Header forwarding is often treated as plumbing. It should be reviewed like policy.

What can go wrong

Poor header handling can lead to:

• incorrect client attribution in logs
• broken IP allowlists
• insecure redirects
• session cookies missing the Secure flag because the app thinks traffic is plain HTTP
• authentication confusion when identity headers can be spoofed
• cache poisoning or route confusion tied to host handling

What good looks like

A defensible setup usually does the following:

• strips untrusted incoming versions of security-relevant headers
• rebuilds trusted values at the proxy
• documents which upstreams are allowed to consume which headers
• rejects malformed or ambiguous host and forwarding data

Review examples

Instead of asking only "Is X-Forwarded-For present?" ask:

• Is the leftmost or rightmost IP being used by the application?
• What happens when multiple values are present?
• Is there a trusted proxy list configured upstream?
• Are cloud load balancer headers handled differently from internal proxy headers?

This matters because many security controls fail quietly when client identity is interpreted inconsistently.

---

Check host and route ownership

Reverse proxies often route based on hostnames and paths. As environments grow, that logic can become fragile.

Questions to answer

• Which hosts are accepted?
• Which paths are exposed publicly?
• Are catch-all routes present?
• Do default virtual hosts send traffic somewhere useful instead of failing closed?
• Can an unrecognized hostname land on a sensitive app?

Common risks

• wildcard host rules exposing internal apps
• path overlap such as /admin and /admin-api
• rewrite behavior that reaches internal paths unexpectedly
• forgotten staging routes still active on production infrastructure
• default backends that reveal status pages or generic app content

A solid review catalogs every externally reachable hostname and route and verifies a clear owner for each.

If nobody owns a route, that route is a risk.

---

Review TLS termination and upstream transport assumptions

TLS is often where reverse proxies deliver the most value, but it is also where teams stop asking questions too early.

Terminating TLS at the proxy is normal. The important part is understanding what happens after that.

Review the full TLS story

Check:

• where TLS terminates
• whether traffic is re-encrypted to upstreams
• which services still allow plain HTTP internally
• how certificate validation is handled for upstream TLS
• whether HTTP and HTTPS behavior is consistent

Blind spots to look for

• upstream traffic assumed to be safe simply because it is internal
• apps trusting X-Forwarded-Proto without ensuring only the proxy can set it
• redirect loops or downgrade behavior caused by mixed scheme awareness
• internal mTLS absent where service identity actually matters

If the reverse proxy tells the application "this request was HTTPS," make sure the application is hearing that from a trusted source and using it correctly.

---

Make logging support investigation, not just metrics

A reverse proxy that does not log the right fields creates operational blindness.

Security incidents involving web apps often require answers such as:

• What was the real client IP?
• Which hostname was targeted?
• Which upstream handled the request?
• Was the request blocked, redirected, or passed through?
• What headers influenced routing or trust?

Minimum useful logging fields

Your reverse proxy logs should usually include:

• timestamp
• client IP as seen at the trusted layer
• full forwarded chain if relevant
• hostname
• request method and URI
• response status
• upstream target
• upstream response status or timing
• TLS details where useful
• request ID or correlation ID

Common logging gaps

• logging only the proxy source rather than the client
• losing the original host after rewrites
• no correlation between proxy and app logs
• health checks mixed with user traffic without labels
• no visibility into denied requests

A review should verify not just that logs exist, but that they help reconstruct what happened during a bad day.

---

Look for authentication and identity shortcuts

Reverse proxies are frequently used to centralize access control. That can be useful, but it creates a high-trust role.

Review cases carefully

Examples include:

• SSO handled at the proxy
• auth_request or external auth middleware
• proxy-added identity headers consumed by upstream apps
• admin paths protected at the proxy instead of in the app

Questions to ask

• Can the upstream be reached without passing through auth enforcement?
• Does the upstream independently verify identity, or fully trust proxy-added headers?
• Are identity headers stripped from inbound client requests first?
• What happens on auth service failure: fail open or fail closed?

A reverse proxy should not quietly become the only thing standing between the internet and an admin interface unless that design is clearly intentional and hardened.

---

Review error handling and default behavior

Security issues often appear in fallback behavior rather than the happy path.

Check what happens when:

• the hostname is unknown
• the path does not match a route
• the upstream is unavailable
• TLS negotiation fails
• the auth backend times out
• a malformed header is received

Good review outcomes

Prefer behavior that:

• fails closed for sensitive routes
• does not leak internal hostnames or stack details
• does not reroute unmatched traffic to a generic backend
• logs enough detail to investigate repeated failures

Default behavior is one of the easiest places for hidden exposure to survive unnoticed.

---

Compare configuration across environments

A reverse proxy may be safe in production and risky everywhere else.

Development, staging, and temporary migration environments often accumulate exceptions such as:

• broad CIDR allowlists
• disabled TLS verification upstream
• test hostnames still resolving publicly
• debug headers exposed externally
• temporary routes left in place

During review, compare:

• public entry points
• enabled modules or middleware
• trust proxy lists
• logging formats
• certificate validation settings
• access control rules

A weak non-production environment can still become a pivot point, a data leak, or a source of misleading operational assumptions.

---

Test like both an attacker and an operator

A useful review includes hands-on validation, not just reading config.

Attacker-style checks

Try to identify whether you can:

• supply fake X-Forwarded-For or identity headers
• reach upstreams directly
• access sensitive routes with alternate hosts or paths
• trigger different behavior using HTTP instead of HTTPS
• discover hidden backends through default responses

Operator-style checks

Verify whether you can:

• trace one request from proxy to upstream using logs
• identify which route matched a request
• distinguish blocked traffic from app errors
• confirm the real client IP with confidence
• tell when an upstream certificate check fails

The attacker view finds exposure. The operator view finds blindness. You need both.

---

A practical review checklist

Use this checklist during periodic assessments or before major changes.

1. Trust boundary

• Document every proxy layer in the request path
• Identify where client identity is established
• Confirm upstreams trust only approved proxy sources

2. Exposure

• Test whether backends are directly reachable
• Restrict upstream access to proxy networks where possible
• Remove legacy listeners and unused ports

3. Header security

• Strip or overwrite untrusted forwarded headers
• Verify trusted proxy configuration in the app
• Review identity and auth-related headers separately

4. Routing

• Inventory hosts, paths, and default routes
• Remove orphaned routes and stale test domains
• Ensure unmatched traffic fails safely

5. TLS and transport

• Confirm where TLS terminates and whether upstream traffic is encrypted
• Validate upstream certificates when using TLS internally
• Check app behavior tied to X-Forwarded-Proto

6. Logging and observability

• Log client IP, host, URI, upstream, and correlation data
• Ensure denied requests are visible
• Confirm proxy and app logs can be correlated

7. Authentication flows

• Review proxy-enforced auth and identity header usage
• Confirm direct upstream access cannot bypass auth
• Check failure behavior for auth backends

8. Change control

• Compare prod and non-prod proxy behavior
• Review recent route additions and exceptions
• Retest after migrations, CDN changes, or ingress updates

---

Signs your reverse proxy needs immediate attention

Move the review higher on the priority list if any of these are true:

• nobody can clearly explain which headers the app trusts
• backend services are reachable outside the proxy path
• logs do not show the real client identity reliably
• default routes or wildcard hosts are loosely defined
• authentication depends on proxy-added headers without strict sanitization
• internal traffic is assumed safe without verification
• multiple proxy layers exist and each team documents them differently

These are not theoretical concerns. They are exactly the sort of conditions that let small mistakes become large incidents.

---

Final thought

Reverse proxies are valuable because they centralize control. That same centralization means their mistakes scale efficiently.

A strong review does not focus only on syntax or product-specific settings. It asks a broader question:

What security decisions depend on this proxy, and how do we know those decisions are based on trustworthy data?

If you can answer that confidently for headers, routing, TLS, access control, and logging, your reverse proxy is much less likely to become the layer everyone relies on but nobody truly sees.