Reverse Proxy Review Checklist: Finding Trust Gaps Before They Hide Real Risk

A reverse proxy often starts as a practical fix. You put it in front of applications to terminate TLS, centralize routing, add caching, simplify certificates, or expose several services behind one public entry point.

That convenience is exactly why reverse proxies deserve regular review.

When a proxy sits between users and applications, it changes what downstream systems can see, what they trust, and what they stop validating for themselves. If that design is not reviewed carefully, the proxy becomes a quiet blind spot: requests look normal, services stay reachable, and dashboards stay green, while important security assumptions drift out of sync.

This tutorial walks through a practical way to review a reverse proxy setup before it becomes a hidden source of risk. The goal is not to blame the proxy. The goal is to confirm that routing, identity, encryption, logging, and failure handling all work the way your team believes they do.

Why reverse proxies deserve their own review

A reverse proxy is more than a traffic forwarder. It is often doing several security-relevant jobs at once:

• terminating TLS
  n- rewriting headers
• choosing upstream destinations
• handling redirects
• enforcing request limits
• attaching authentication context
• hiding internal addresses
• generating access logs
• responding to health checks
• serving error pages

That means a small configuration change can affect far more than connectivity.

For example:

• A backend may start trusting X-Forwarded-For from untrusted sources.
• Logs may show only the proxy IP instead of the real client.
• A health endpoint may expose internal build details publicly.
• An HTTP-to-HTTPS redirect may work at the edge but fail for internal callers.
• A default route may accidentally publish an internal admin service.

These are not dramatic, movie-style failures. They are the kind of quiet mistakes that survive into production because systems still appear to work.

Start with a trust boundary map

Before checking directives, build a simple map of the request path.

Document:

1. Where traffic enters

   • Internet-facing DNS names
   • CDN or DDoS protection layers
   • cloud load balancers
   • on-prem edge appliances

2. Where TLS starts and ends

   • client to CDN
   • CDN to reverse proxy
   • reverse proxy to application
   • internal service-to-service hops

3. Which systems add or modify headers

   • X-Forwarded-For
   • X-Forwarded-Proto
   • Forwarded
   • X-Real-IP
   • authentication or identity headers

4. Which systems make security decisions

   • proxy ACLs
   • WAF rules
   • backend allowlists
   • application session logic
   • admin route restrictions

5. Which systems produce logs and alerts

   • edge provider
   • reverse proxy
   • application
   • SIEM or log pipeline

If you cannot draw this path clearly, that is already a useful finding. Reverse proxy blind spots often begin when nobody is fully sure where one trust boundary ends and another begins.

Review what the backend assumes after proxying

One of the most important questions is this:

What does the application trust simply because traffic came through the proxy?

Common assumptions include:

• the request was already decrypted safely
• the client IP header is accurate
• the original scheme was HTTPS
• authentication happened upstream
• rate limiting happened elsewhere
• malformed requests were already filtered

Those assumptions may be true. They may also be outdated, incomplete, or true only for some paths.

Look for places where the backend has reduced validation because the proxy was expected to handle it. Then verify the proxy still enforces that expectation consistently.

Check client IP handling carefully

Client IP handling is one of the most common reverse proxy review failures.

Applications often need the real client address for:

• rate limiting
• abuse detection
• fraud analysis
• geolocation
• audit trails
• blocking repeated login attacks

But once a proxy sits in front, the backend usually sees the proxy's address unless forwarding is configured correctly.

Review questions

• Which header carries the client IP?
• Which upstream systems are allowed to set that header?
• Does the proxy overwrite untrusted incoming values or append to them?
• Does the application parse the correct IP from a chain of addresses?
• Are private or spoofed addresses handled safely?
• Are logs using the same logic as access control and rate limiting?

Common blind spot

A backend trusts X-Forwarded-For from any source instead of only from known proxies. An attacker can then supply a fake IP and influence logs, rate limits, or allowlist checks.

What good looks like

• Only trusted proxy layers can set or extend forwarded IP headers.
• The reverse proxy is configured with explicit trusted upstream networks where supported.
• The application uses a clear, documented proxy trust setting rather than blindly consuming user-controlled headers.
• Logging and security controls use the same client identity model.

Validate scheme and host forwarding

Many applications need to know the original scheme and host to generate links, enforce secure cookies, process redirects, and validate callback URLs.

If the proxy terminates TLS but fails to pass scheme information correctly, the backend may think requests are plain HTTP.

That can lead to:

• bad redirects
• mixed-content behavior
• missing Secure cookie handling
• broken OAuth or SSO callback logic
• incorrect canonical URLs
• accidental downgrade behavior in internal paths

Review questions

• Is the original scheme forwarded consistently with X-Forwarded-Proto or equivalent?
• Is the backend configured to trust that header only from the proxy?
• Is the original host preserved where applications require it?
• Are redirects tested through both public and internal paths?
• Do cookies remain secure after proxy termination?

This area is often treated as an application bug when it is really a proxy trust issue.

Review authentication and identity headers with extra caution

Some environments let the reverse proxy perform authentication or pass identity to backends through headers.

Examples include:

• SSO gateways
• identity-aware proxies
• mutual TLS subject mapping
• access gateways that inject user or group headers

This can work well, but it must be reviewed as a high-trust design.

Review questions

• Which headers communicate identity or authorization context?
• Can a client submit those same headers directly?
• Does the proxy strip inbound copies before setting trusted values?
• Are internal services reachable without passing through the identity-enforcing layer?
• Is there a fallback path that bypasses authentication logic?

Common blind spot

An application trusts a header like X-Authenticated-User, but the header is not stripped from direct requests or alternate ingress paths. A user can then forge identity context.

What good looks like

• The proxy removes any inbound identity headers from clients.
• Only the trusted layer can inject authentication context.
• Backends are not directly reachable from untrusted networks.
• Documentation states exactly which headers are authoritative.

Inspect routing rules for accidental exposure

Routing complexity grows quickly over time. A reverse proxy that started with two services may later carry dozens of hostnames, path prefixes, temporary exceptions, and migration rules.

That is where accidental exposure happens.

Review for these issues

• default backends that catch unexpected requests
• internal services exposed through wildcard host rules
• admin paths reachable from public listeners
• old staging routes still present
• path prefix confusion such as /admin versus /admin/
• overlapping host and path rules with unclear match order
• websocket or gRPC routes bypassing standard controls

Practical review step

Build a route inventory from the actual running configuration, not from memory or old diagrams. For each route, answer:

• Who should reach this?
• From where?
• Over which protocol?
• With which authentication?
• Is it logged distinctly?
• What happens on mismatch?

If a route does not have a clear owner and purpose, it deserves attention.

Check TLS handling end to end, not just at the edge

Many teams verify that HTTPS works publicly and stop there. That is not enough for a meaningful reverse proxy review.

You need to understand whether encryption expectations remain valid after the edge hop.

Review questions

• Is TLS terminated only at the proxy, or re-encrypted to upstream services?
• If traffic is forwarded internally over HTTP, is that segment adequately isolated?
• Are upstream certificates validated when using HTTPS to backends?
• Are expired or mismatched backend certificates detected or ignored?
• Are different virtual hosts mapped correctly to certificates and SNI?
• Are legacy protocols or ciphers still enabled for compatibility reasons nobody remembers?

Common blind spot

A proxy uses HTTPS to upstream services but disables certificate validation to make deployments easier. Teams then assume the internal hop is protected when it is not actually authenticated.

What good looks like

• The TLS model is explicit and documented.
• Internal plaintext is a conscious decision, not an accidental default.
• Upstream certificate validation is enabled where HTTPS is used.
• Certificate rotation and failure behavior are tested.

Review request normalization and header rewriting

Reverse proxies often normalize requests before the application sees them. That can be useful, but it can also create inconsistent interpretation between layers.

Look at how the proxy handles:

• duplicate headers
• large headers
• unusual encodings
• path normalization
• trailing slashes
• encoded slashes
• absolute versus relative URLs
• hop-by-hop headers
• connection upgrade behavior

The main concern is mismatch. If the proxy and backend interpret the same request differently, controls can be bypassed or logs can become misleading.

You do not need to turn this into advanced exploit research to make the review useful. Simply identify where the proxy rewrites or discards request elements and verify that backend expectations still match reality.

Test failure modes, not just successful traffic

Healthy requests rarely reveal blind spots. Misconfigurations become visible when upstreams fail, headers are missing, or routes do not match.

Test scenarios to include

• upstream service unavailable
• TLS validation failure to backend
• request to unknown host header
• request to undefined path
• oversized body or header
• malformed forwarded header chain
• missing authentication context from upstream identity service
• backend timeout

What to observe

• Does the proxy leak internal hostnames or stack details in errors?
• Are failures logged clearly enough to troubleshoot?
• Do retries create duplicate risk for sensitive requests?
• Are health checks masking a partially broken route?
• Does the system fail closed where it should?

A reverse proxy that behaves correctly only during ideal conditions is not fully reviewed.

Confirm logging preserves the story of the request

A reverse proxy can either improve visibility or erase it.

Done well, proxy logs help correlate:

• real client identity
• target host and route
• upstream destination
• response status
• TLS details
• request timing
• rejection reasons

Done poorly, they leave you with ambiguous entries that say only that the proxy returned a 502 or that a request came from 127.0.0.1.

Review questions

• Do logs capture the effective client IP after trusted parsing?
• Are host, path, upstream, and status recorded?
• Can you distinguish proxy-generated errors from backend-generated errors?
• Are request IDs added and forwarded downstream?
• Are logs structured enough for searching and alerting?
• Are sensitive headers or tokens excluded from logs?

Practical advice

Take one test request and trace it across the proxy and application logs. If correlation is difficult during a controlled test, it will be much worse during a real incident.

Look for health check and monitoring blind spots

Health checks are useful, but they can also create false confidence.

A route may be marked healthy because:

• TCP responds
• one lightweight endpoint returns 200
• the proxy can reach the upstream port

Meanwhile, real user traffic may fail because of:

• broken authentication header forwarding
• incorrect host preservation
• bad TLS validation upstream
• path-specific routing errors
• application dependency failures

Review questions

• What exactly do health checks verify?
• Do they use the same host and path behavior as user traffic?
• Are synthetic checks testing representative routes?
• Are monitoring dashboards built from edge success alone?
• Do alerts distinguish between proxy failure and upstream failure?

A good review treats health status as one signal, not proof that the full request path is correct.

Verify direct access paths are actually blocked

One of the easiest ways for a reverse proxy design to lose value is when the backend remains reachable directly.

That creates a split world:

• normal users go through the proxy with one set of controls
• alternate callers reach the backend without those controls

Review this explicitly

• Can internal users reach the application directly by IP or alternate DNS?
• Are origin servers exposed to the internet unintentionally?
• Do firewall rules allow bypass around the proxy?
• Do management networks have broader access than intended?
• Are cloud security groups aligned with the intended ingress path?

If the backend should only accept traffic from the proxy, enforce that at the network layer where possible.

Create a change review checklist for every new proxied service

The best way to prevent future blind spots is to make reverse proxy review repeatable.

When onboarding a new service, verify at minimum:

Reverse proxy service onboarding checklist

• What hostname and paths will be exposed?
• Is the route public, private, or limited by source?
• Where does TLS terminate?
• Is upstream TLS required and validated?
• Which headers are forwarded, removed, or added?
• How is the real client IP determined?
• Does the app trust proxy headers explicitly?
• Are authentication or identity headers involved?
• Is direct access to the backend blocked?
• What should logs contain for this service?
• Which health checks represent real availability?
• What is the expected failure behavior?

This checklist prevents the common pattern where one working service becomes the template for ten others, even though their trust requirements are different.

A simple review workflow your team can use

If you want a lightweight but practical process, use this sequence:

1. Inventory the path

List every hop from client to backend and back.

2. Mark trust transitions

Document where identity, encryption, and routing decisions change.

3. Review proxy configuration by control area

Check routing, headers, TLS, auth context, logging, and error handling separately.

4. Test expected and unexpected traffic

Include invalid hosts, missing headers, and failure scenarios.

5. Correlate logs across layers

Make sure the request story survives proxying.

6. Record assumptions

Write down what the backend is allowed to trust and why.

7. Re-run after major changes

Repeat the review when adding services, changing edge providers, altering SSO, or redesigning internal networking.

Final thoughts

A reverse proxy is supposed to simplify access, not obscure it.

The real risk is not that a proxy exists. The risk is that over time it becomes the place where security assumptions accumulate without being revisited. Headers get forwarded because they always were. TLS choices remain because they once solved a deployment problem. Routes stay published because removing them feels risky.

A good review brings that hidden logic back into the open.

If you treat the reverse proxy as a trust boundary instead of just a convenience layer, you can catch the subtle problems early: spoofable client identity, bypassable auth context, exposed internal routes, weak upstream validation, and logs that no longer tell the truth.

That is how you keep a useful infrastructure component from becoming a long-lived blind spot.