Reverse proxies solve problems — and create a new review surface

A reverse proxy often starts as a convenience layer. It terminates TLS, routes traffic, adds compression, forwards requests to internal services, and can centralize authentication or rate limiting. That makes it operationally valuable.

It also makes it easy to trust too much.

Once a proxy sits in front of multiple services, teams may stop asking basic questions:

• Which headers are trusted, and from whom?
• Where is the real client IP coming from?
• Which system decides whether a request was HTTP or HTTPS?
• Are redirects, auth checks, and backend logs based on accurate request context?
• If the proxy fails open, what is still reachable?

A reverse proxy becomes a blind spot when it is treated as plumbing instead of a security-relevant control plane. The goal of this review is not to redesign everything. It is to verify that the proxy is forwarding traffic, trust, identity, and visibility in a controlled way.

Start with one simple diagram

Before checking directives or YAML, draw the real request path.

Include:

1. The client entry point: internet, VPN users, internal users, partner networks, or another upstream CDN or load balancer.
2. Each proxy hop: CDN, WAF, cloud load balancer, ingress controller, sidecar proxy, or host-based reverse proxy.
3. The backend target: application server, API gateway, legacy app, admin panel, or internal service.
4. The decision points: TLS termination, authentication, IP allowlists, rate limits, redirects, header rewriting, and logging.

This sounds basic, but many review failures happen because the documented design has one proxy while production has three.

Define the trust boundary explicitly

The most important question in a reverse proxy review is not performance. It is trust.

Ask:

• Which upstream systems are allowed to send forwarded headers?
• Which backend services trust the proxy as an identity source?
• Which interfaces should never be reachable directly?
• Which internal apps assume the proxy already handled authentication?

If the backend trusts headers from any source instead of only the known proxy layer, the proxy is not enforcing a boundary. It is only relaying traffic.

Review client identity handling carefully

Client identity is where reverse proxy mistakes become expensive. Logs, alerts, rate limiting, abuse controls, and forensics often depend on the source IP and protocol metadata being correct.

Check forwarded IP behavior

Look for how the environment handles:

• X-Forwarded-For
• X-Real-IP
• standardized Forwarded
• proxy protocol, if used

Review questions:

• Does the reverse proxy overwrite untrusted incoming values, or append to them?
• Does the backend trust these headers only from known proxy IPs?
• Is there more than one proxy hop, and if so, is the correct client IP extracted consistently?
• Are logs recording the real client IP or only the last internal hop?

A common failure is accepting spoofed X-Forwarded-For values from the internet. That can distort logs and weaken controls tied to IP reputation or rate limiting.

Check scheme and host forwarding

Applications often need to know:

• whether the original request used HTTP or HTTPS
• which host the client requested
• which port was externally visible

That usually means reviewing headers such as:

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

Problems here can break secure redirects, generate mixed-content issues, weaken cookie security assumptions, or cause application logic to trust the wrong origin.

Validate direct backend exposure

A reverse proxy cannot protect a backend that remains directly reachable.

Check whether the origin service can still be accessed:

• from the public internet
• from flat internal networks
• from container bridges or node networks not intended for users
• through alternate ports that bypass proxy controls

If direct access exists, ask what is bypassed:

• authentication at the proxy
  n- request filtering
• rate limits
• TLS enforcement
• logging and visibility

The review outcome should be clear: either direct origin access is intentionally restricted, or the team accepts that the proxy is not the only entry path.

Review routing rules for accidental exposure

Routing is not only about whether traffic reaches the right service. It is about whether the wrong traffic can reach a service at all.

Check:

• wildcard hosts and default virtual hosts
• fallback routes
• regex path matching behavior
• path normalization and trailing slash handling
• overlap between public and internal paths
• catch-all upstreams that may unintentionally publish admin interfaces

Examples of risky patterns include:

• a default host that forwards unknown domains to a live backend
• a path rule that exposes /admin under an alternate prefix
• a proxy that rewrites URLs in a way the backend does not expect

When reviewing routing, test both intended requests and malformed ones.

Inspect authentication and authorization assumptions

Reverse proxies often sit in front of SSO, basic auth, mTLS, API keys, or header-based identity systems. That means the proxy may be part of the authentication chain even when it is not the identity provider.

Review questions:

• Does the proxy inject identity headers for the backend?
• Can a client supply those same headers directly?
• Does the backend verify that identity-bearing headers only come from the trusted proxy?
• Are auth-exempt paths narrower than intended?
• Are health endpoints, metrics endpoints, and internal dashboards exposed under the same listener?

A backend that trusts X-User, X-Email, or similar identity headers without validating the source is relying on a fragile control model.

Review TLS termination and re-encryption choices

A reverse proxy commonly terminates TLS. That is normal, but it changes what must be reviewed.

Check:

• where TLS ends
• whether traffic to the backend is plaintext or re-encrypted
• whether backend certificate validation is enabled when HTTPS is used upstream
• whether internal certificates are verified properly or skipped for convenience
• whether HSTS or secure redirect behavior matches the public design

The goal is not to insist that every internal hop must use the same pattern. The goal is to understand whether the chosen pattern matches the risk and whether the implementation actually enforces it.

Examine header normalization and request rewriting

Reverse proxies commonly rewrite requests. That can be useful, but it can also create confusing behavior between what the client sent and what the backend saw.

Review:

• path rewriting
• host header rewriting
• stripping or preserving hop-by-hop headers
• duplicate header handling
• maximum header size and body size behavior
• normalization of encoded paths and unusual characters

If the proxy and backend interpret paths differently, security rules can be bypassed or monitoring can become inaccurate.

Check logging for completeness, not just existence

Many teams say, "the proxy logs everything." Often it does not log the right things.

Useful proxy logging should help answer:

• who made the request
• which host and path were requested
• which upstream handled it
• what status the client received
• whether the backend returned an error or timed out
• how long the request spent in the proxy and upstream
• whether TLS and auth context were relevant

What to verify in logs

Confirm whether logs include:

• real client IP after trusted proxy processing
• request ID or correlation ID
• upstream address or service name
• upstream status code
• response time and upstream response time
• host, method, path, status, bytes sent, user agent where appropriate

Then check whether those logs actually reach your log pipeline consistently.

A reverse proxy is a blind spot when traffic passes through it but investigations still cannot answer basic attribution and failure questions.

Review error handling and failure modes

A proxy may behave safely during normal operations and dangerously during exceptions.

Test or inspect behavior for:

• backend timeouts
• upstream connection failures
• invalid host headers
• oversized requests
• malformed requests
• TLS handshake failures
• certificate expiration events
• unavailable authentication backends

Questions to ask:

• Does the proxy return a generic error or route to a fallback service?
• Do failures generate visible logs and alerts?
• Can an upstream outage expose internal details in error pages?
• Does a failed auth integration cause deny-by-default or accidental pass-through?

These are the moments when hidden assumptions surface.

Verify health checks and internal endpoints

Reverse proxies often expose operational paths that teams forget to review.

Look for:

• /health, /ready, /metrics, /status
• dashboard or admin interfaces
• service discovery endpoints
• debug routes
• ACME challenge paths and certificate automation helpers

Not every internal endpoint is dangerous by itself, but each one expands the attack and information surface. Review whether they are:

• publicly reachable
• restricted by network location
• protected by authentication
• logged properly

Check default behavior and inheritance

A lot of proxy risk comes from defaults rather than explicit configuration.

Examples:

• a default server block catches unexpected traffic
• inherited headers apply to more locations than intended
• a global redirect changes behavior for admin or callback paths
• a permissive middleware applies to both public and internal routes

When reviewing a configuration, do not stop at the route you care about. Trace what is inherited from global settings, parent blocks, templates, or Helm values.

Use a practical review workflow

A useful reverse proxy review can be done in a short, repeatable sequence.

1. Inventory listeners and published names

List every exposed:

• hostname
• port
• protocol
• certificate binding
• backend target

This quickly reveals unknown listeners, stale virtual hosts, and catch-all behavior.

2. Map trust inputs

For each listener, document:

• accepted proxy headers
• trusted upstream IP ranges
• auth-related headers injected or stripped
• whether backend identity relies on proxy assertions

3. Test expected and unexpected paths

Send requests that are:

• normal
• malformed
• unknown-host
• wrong-scheme
• oversized
• directed at admin-like paths

The goal is to observe routing, rejection behavior, and logging quality.

4. Compare proxy logs with backend logs

Pick a few requests and verify that:

• the same request can be correlated across layers
• the client IP matches expectations
• the host and path are interpreted consistently
• status codes make sense end to end

5. Confirm bypass resistance

Try to determine whether the backend can be reached without the proxy and whether that path changes auth or visibility.

Common findings worth fixing first

If you only have time for a short remediation pass, prioritize these issues:

Untrusted forwarded headers

If clients can influence source IP or protocol context, logs and controls become unreliable.

Publicly reachable origin services

If the backend is still exposed, proxy-based protections may be optional rather than real.

Weak or missing correlation in logs

Without request IDs and upstream status visibility, troubleshooting and incident response degrade fast.

Overbroad routing rules

Catch-all hosts and permissive path rules create accidental exposure that can remain unnoticed for long periods.

Proxy-injected identity headers without backend validation

This creates a dangerous trust shortcut if requests can ever bypass the expected path.

A short review checklist you can reuse

Use this as a compact defensive checklist:

• Are all public entry points known and documented?
• Are trusted proxy hops explicitly defined?
• Are X-Forwarded-* and similar headers handled safely?
• Do backends trust proxy-provided identity only from approved sources?
• Can origin services be reached directly?
• Are routing defaults and fallback hosts intentional?
• Are admin, metrics, and health paths reviewed for exposure?
• Does TLS behavior match the intended security model?
• Do logs capture real client identity, upstream status, and correlation IDs?
• Are failure modes visible and deny-safe?

Final thought

A reverse proxy is not just a traffic shaper. It is a policy, identity, and observability layer.

That is why reviewing it matters.

The best reverse proxy setups are not the most complex ones. They are the ones where the team can clearly explain what is trusted, what is forwarded, what is blocked, and what will still be visible when something breaks. If you can answer those questions confidently, the proxy is far less likely to become the quiet blind spot in front of everything that matters.