Reverse Proxy Review Playbook

Reverse proxies are often introduced for practical reasons: TLS termination, centralized routing, load balancing, caching, rate limiting, or cleaner application publishing. Over time, they become a critical control point. They also become easy to stop questioning.

That is where blind spots form.

If your reverse proxy sits in front of customer-facing applications, internal admin panels, APIs, or identity-aware services, then it is doing much more than forwarding traffic. It is shaping trust. A weak review process can leave teams assuming the proxy is enforcing controls that are actually missing, misapplied, or easy to bypass.

This tutorial walks through a practical review process you can use before a reverse proxy setup turns into an operational or security liability.

Start with one simple question: what does the proxy decide?

Before reading config files, define the proxy's actual role.

A reverse proxy may decide:

• which hostnames are accepted
• which paths are published
• whether TLS is required
• how client IP is interpreted
• what headers are forwarded
• whether authentication is enforced upstream or downstream
• which backends are reachable
• which errors are exposed to clients
• what gets logged
• what gets blocked, redirected, cached, or rewritten

That means your review should not begin with syntax. It should begin with decision mapping.

Build a quick architecture map first

Document the request path from client to application.

A minimal map should include:

1. Client or internet-facing source
2. CDN, DDoS layer, or cloud edge if present
3. Load balancer or reverse proxy
4. Any internal proxy tier or service mesh hop
5. Application backend
6. Authentication provider if auth is delegated
7. Logging and monitoring destinations

This matters because many reverse proxy problems are not local misconfigurations. They are chain-of-trust problems across multiple layers.

For example:

• A CDN inserts X-Forwarded-For
• A load balancer passes it unchanged
• NGINX trusts it without restricting trusted upstream sources
• The application uses the spoofed client IP for allowlisting or rate limiting

Each layer may appear reasonable on its own. Together, they create a blind spot.

Review the trust boundary, not just the service definition

A reverse proxy is often the first system that translates outside requests into something the application trusts. That makes trust-boundary review mandatory.

Focus on these questions:

Which systems are allowed to talk to the proxy?

Check:

• listener interfaces
• public versus private exposure
• firewall or security group rules
• management ports versus data-plane ports
• internal-only virtual hosts accidentally exposed externally

A common mistake is assuming a service is "internal" because of DNS naming, while the listener is actually reachable on a public interface.

Which systems are allowed to talk to the backend directly?

This is one of the most important checks in the whole review.

If a backend can be reached directly, users may bypass controls enforced only at the proxy, such as:

• authentication
• rate limiting
• path restrictions
• method restrictions
• IP allowlists
• request size limits
• bot filtering
• logging correlation

Ideally, backends should accept traffic only from the proxy tier or a tightly defined internal network segment.

What traffic is considered trustworthy?

Do not assume headers are trustworthy just because they are present.

Explicitly identify:

• trusted upstream IP ranges
• trusted proxy layers
• trusted identity headers
• trusted protocol indicators like X-Forwarded-Proto
• trusted host information

If the proxy accepts client-supplied values without restricting who can set them, downstream applications may make the wrong security decision.

Validate host and routing behavior carefully

Reverse proxies often route traffic based on hostnames, paths, SNI, headers, or URL patterns. Review these rules with a security mindset.

Confirm expected hosts only

Check whether the proxy:

• rejects unknown Host headers
• serves a safe default site
• accidentally routes unmatched traffic to a sensitive backend
• exposes staging, admin, or legacy applications through forgotten server blocks or routes

A dangerous pattern is using a permissive default virtual host that forwards traffic somewhere useful. Unknown hosts should usually fail closed.

Review path matching and precedence

Path rules can behave differently than teams expect.

Look for:

• ambiguous prefix matching
• case sensitivity assumptions
• hidden admin paths exposed through broader route rules
• rewrite logic that changes authorization scope
• path normalization issues between proxy and backend

If the proxy sees /admin/../api, but the backend normalizes it differently, access control can break in subtle ways.

Watch for shadow routes

During long-lived deployments, temporary routes often become permanent.

Examples include:

• /old-admin
• /debug
• /healthz exposed externally
• /internal-api published for a migration and never removed

These routes may not appear in current application documentation, but they can still be reachable through the proxy.

Inspect TLS handling beyond “HTTPS works”

Many reviews stop once the certificate looks valid. That is not enough.

Verify where TLS starts and ends

Document:

• whether TLS terminates at the edge, at the proxy, or both
• whether proxy-to-backend traffic is encrypted
• whether backend certificate validation is enabled
• whether mutual TLS is used anywhere in the path

If backend encryption is expected, make sure it is actually validated. Encrypting traffic without validating the backend identity is weaker than many teams assume.

Confirm protocol signaling is correct

Applications often need to know whether the original request was HTTPS.

Review how the proxy sets:

• X-Forwarded-Proto
• Forwarded
• redirect logic
• secure cookie expectations
• HSTS behavior if used

If the application thinks a request was HTTP when it was actually HTTPS at the edge, you may see:

• broken secure redirects
• insecure cookie handling
• incorrect absolute URLs
• mixed-content edge cases
• flawed auth callback behavior

Review forwarded headers as security inputs

Headers are one of the most common reverse proxy blind spots because applications routinely trust them.

High-priority headers to review

Client IP headers

Examples:

• X-Forwarded-For
• X-Real-IP
• Forwarded

Check:

• who is allowed to set them
• whether existing client values are overwritten, appended, or passed through
• how the application chooses the “real” client IP
• whether trusted proxy ranges are configured correctly

If this is wrong, you can break:

• IP-based access controls
• rate limiting
• geo restrictions
• fraud detection
• audit trails

Host and original URL headers

Examples:

• Host
• X-Forwarded-Host
• X-Original-URI
• X-Rewrite-URL

These may influence:

• route selection
• absolute URL generation
• authentication callbacks
• tenant selection
• origin validation

Any mismatch between proxy behavior and backend assumptions deserves investigation.

Identity and authentication headers

Examples:

• Authorization
• X-Forwarded-User
• X-Authenticated-User
• SSO or identity-provider headers

Ask:

• Does the proxy inject these headers?
• Can a direct client also submit them?
• Does the backend trust them only from the proxy?
• Are they removed before forwarding if not explicitly intended?

Identity headers should never be treated as trustworthy merely because they exist.

Check authentication and authorization placement

A reverse proxy may enforce authentication itself, pass identity to the backend, or leave everything to the application. None of these models is automatically wrong, but each requires clarity.

If auth is enforced at the proxy

Review:

• bypass paths
  n- backend reachability outside the proxy
• failure behavior when the identity provider is unavailable
• session timeout and logout handling
• whether all methods are protected equally

A frequent failure mode is protecting browser routes while leaving API endpoints or WebSocket paths inconsistently covered.

If auth is enforced by the application

Review whether the proxy accidentally undermines it by:

• rewriting paths in unexpected ways
• altering host/protocol context
• forwarding identity-looking headers from clients
• exposing alternate application entry points

If auth is shared between proxy and app

Be especially careful.

Shared responsibility often creates assumption gaps, such as:

• proxy team thinks app checks admin authorization
• app team thinks proxy blocks admin paths
• neither side validates a risky route consistently

Evaluate request filtering and method handling

A reverse proxy often limits methods, body size, upload behavior, or unusual request patterns. These controls deserve periodic review.

Check:

• allowed HTTP methods per route
• whether TRACE, CONNECT, or unexpected methods are blocked where appropriate
• body size limits and upload paths
• timeout configuration
• request buffering behavior
• header size limits
• chunked encoding handling if relevant

This is not about chasing every theoretical edge case. It is about making sure the proxy behavior matches the application's real expectations.

For example, if only GET and POST are expected on a route, allowing every method may expand attack surface unnecessarily.

Review error handling and information exposure

When a proxy fails, what does the client learn?

Check whether error responses:

• reveal backend names or internal IPs
• leak product versions in headers or templates
• expose stack traces through upstream error pages
• behave differently for unauthorized versus nonexistent resources in ways that aid enumeration

Also check proxy-generated headers such as:

• Server
• debug headers
• tracing headers exposed publicly

A clean external error surface makes reconnaissance harder and operations cleaner.

Logging review: can you investigate a real incident?

A reverse proxy is often the best place to preserve request context across many applications. But many deployments log too little, too much, or the wrong fields.

Minimum practical logging questions

Can you reliably answer these after an incident?

• Which hostname was requested?
• Which backend handled it?
• What source IP was considered authoritative?
• Which request ID or trace ID ties logs together?
• What status code did the proxy return?
• Was the request blocked, rewritten, redirected, or passed upstream?
• How long did the upstream response take?

Logging pitfalls to catch

• only logging proxy status, not upstream status
• missing request correlation IDs
• trusting spoofable client IP values in logs
• inconsistent timestamps or time zones
• losing logs during restart or overload
• logging sensitive headers or tokens unnecessarily

A reverse proxy can be central to detection and forensics, but only if its logs are intentionally designed.

Health checks, monitoring, and safe observability

Health endpoints are useful, but they are also commonly overexposed.

Review:

• whether health checks are reachable externally
• whether they disclose application internals
• whether monitoring endpoints require authentication or network restriction
• whether metrics interfaces are separated from public listeners

Common blind spot: a route intended only for internal monitoring becomes internet-accessible because it was added to the same virtual host as the public application.

Review resilience behavior under failure

A reverse proxy does not become safer just because it stays online. Failure behavior matters.

Check:

• what happens when a backend is slow or unavailable
• whether retries can duplicate unsafe requests
• whether stale routing entries remain active
• whether maintenance pages reveal too much
• whether fail-open behavior exists for auth or filtering components

For example, if the proxy cannot contact an external auth helper, does it deny requests or allow them through? Teams should know that answer before an outage forces the issue.

Inspect configuration hygiene and change control

Long-running reverse proxy environments accumulate complexity faster than many teams realize.

Look for:

• duplicate or conflicting route definitions
• unused include files still loaded
• commented-out controls that signal temporary exceptions
• environment drift between staging and production
• manual hotfixes not represented in source control
• certificates, upstreams, or ACLs tied to retired systems

A review is not complete if you only inspect the active route and ignore the surrounding configuration sprawl.

A practical checklist you can use

Use this short review sequence during audits, migrations, or service onboarding.

1. Identify exposed services

List every hostname, path group, and backend currently published through the proxy.

2. Confirm intended trust boundaries

Document which upstream layers are trusted and which headers they are allowed to provide.

3. Verify backend isolation

Make sure backends cannot be reached directly from untrusted networks.

4. Test host and path handling

Send requests with unexpected hosts, paths, and methods. Confirm the proxy fails closed.

5. Review header forwarding rules

Inspect how client IP, protocol, host, and identity-related headers are added, removed, or rewritten.

6. Validate auth coverage

Check that all relevant routes, methods, APIs, and protocol upgrades are covered consistently.

7. Inspect TLS and upstream validation

Confirm where encryption ends and whether upstream certificates are actually validated when expected.

8. Review logging for investigation value

Ensure logs capture enough context for incident response without leaking unnecessary secrets.

9. Check monitoring and health exposure

Verify that observability endpoints are appropriately segmented and not casually internet-accessible.

10. Compare config to reality

Test the live behavior, not just the intended design document.

Sample review findings that matter in practice

Here are examples of issues that often look small until they combine with something else:

• The backend admin interface is restricted at the proxy, but the backend is also reachable directly on an internal subnet used by contractors.
• The application trusts X-Forwarded-Proto to mark cookies secure, but the proxy passes through whatever the client sends.
• Unknown hosts fall through to a default route that serves a staging application with weak authentication.
• Logs record X-Forwarded-For without restricting trusted proxies, making forensic source IP data unreliable.
• The SSO-protected UI is behind the proxy, but a versioned API path on the same backend bypasses that protection.
• Health endpoints expose build info, dependency versions, and internal hostnames to the internet.

None of these are rare. All of them are reviewable.

Keep the review defensive and repeatable

The goal is not to turn every reverse proxy assessment into a massive redesign. The goal is to make sure the proxy is not quietly becoming a place where assumptions pile up faster than verification.

A good reverse proxy review asks:

• What is exposed?
• What is trusted?
• What can be bypassed?
• What gets logged?
• What fails safely?

If your team can answer those questions confidently, the proxy is much less likely to become a blind spot.

Final thought

Reverse proxies earn trust because they sit in front of important systems and usually work quietly. That same quiet reliability is exactly why they deserve periodic scrutiny.

Review them as policy enforcement points, trust translators, and evidence sources—not just traffic routers. That shift in perspective is often what reveals the hidden gaps before an attacker, outage, or audit does.