Reverse proxies deserve a full review, not a quick glance

A reverse proxy often sits in one of the most influential positions in an environment. It may terminate TLS, normalize requests, apply access rules, route traffic to internal services, and generate the logs your team relies on during incidents.

That also makes it easy to misunderstand.

When a reverse proxy is treated as "just the front door," it can quietly turn into a blind spot. Teams may assume the application sees the real client IP, that redirects are safe, that TLS is consistently enforced, or that logs tell the full story. In reality, those assumptions can fail in small but important ways.

This tutorial walks through a practical review process you can use before a reverse proxy becomes a hidden risk.

---

Start with one basic question: what security decisions happen at the proxy?

Before looking at directives or YAML, define the proxy's actual role.

A reverse proxy may be responsible for:

• TLS termination
• HTTP to HTTPS redirection
• Host- and path-based routing
• Header insertion or removal
• Authentication or single sign-on handoff
• Client IP preservation
• Rate limiting
• WAF or bot filtering
• Request size limits
• Backend health checks
• Error page handling
• Access logging

If you do not list these responsibilities first, you can easily review the wrong thing. For example, a team may focus on backend firewall rules while missing that the proxy decides whether a request is considered secure, authenticated, or internal.

Step 1: Map the request path end to end

A review should begin with a simple architecture map.

Document the path from the client to the application:

1. Client
2. CDN or DDoS protection layer, if any
3. Load balancer
4. Reverse proxy
5. Service mesh or internal gateway, if any
6. Application
7. Logging and monitoring destinations

For each hop, answer:

• Who terminates TLS?
• Who can see the original source IP?
• Who can modify headers?
• Who makes allow or deny decisions?
• Who records logs?
• Which hop is reachable from the internet?
• Which hop is reachable from internal networks?

This sounds basic, but it exposes many design mistakes quickly. If two different layers both rewrite headers, or if three different systems can terminate TLS, you need to know exactly how trust is handed off.

Step 2: Identify the real trust boundary

One of the biggest reverse proxy review mistakes is assuming the trust boundary sits where the diagram looks cleanest.

Examples:

• If the reverse proxy accepts traffic directly from the internet, it is part of the external trust boundary.
• If the proxy only accepts traffic from a load balancer, then the load balancer-to-proxy path becomes critical.
• If internal networks can reach the proxy directly, then internal abuse or misconfiguration can bypass assumptions made for public traffic.

Review questions to ask:

• Can clients reach backends without going through the proxy?
• Can internal users or workloads send requests directly to the proxy on alternative ports?
• Are health check ports, admin ports, or metrics endpoints exposed beyond the intended network?
• Does the backend trust the proxy because of network location alone?

The goal is to make sure the environment enforces the trust boundary you think exists.

Step 3: Review how client identity is preserved

Many downstream controls depend on the correct source IP and transport context.

If the reverse proxy changes what the backend sees, review that behavior carefully.

Check forwarded headers

Common headers include:

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

Questions to answer:

• Which headers does the proxy add?
• Which headers does it overwrite?
• Which headers does it pass through unchanged?
• Which headers does the application trust?
• Is there a trusted proxy list in the application or framework?

A dangerous pattern is allowing client-supplied forwarding headers to reach the backend unchanged while the application trusts them as if they came from your proxy.

Check proxy chain behavior

If traffic passes through multiple layers, decide how the final backend interprets the chain.

For example:

• Does the proxy append to X-Forwarded-For or replace it?
• Does the application parse the first IP, the last IP, or a trusted subset?
• Can an attacker influence the leftmost value?

If your rate limiting, geolocation, fraud checks, or audit logs depend on source IP accuracy, this review is not optional.

Step 4: Validate TLS handling beyond "HTTPS is enabled"

A reverse proxy often owns the most visible part of TLS, but a review should go deeper than checking for a certificate.

Confirm where TLS terminates

Possible patterns include:

• TLS terminates at the reverse proxy and backend traffic is plain HTTP
• TLS terminates at the reverse proxy and re-encrypts to the backend
• TLS passes through to the backend
• Different virtual hosts use different termination patterns

Review whether the chosen pattern matches the data sensitivity, internal network assumptions, and monitoring design.

Check redirect logic and scheme awareness

Applications often rely on proxy headers to know whether the original request used HTTPS.

If X-Forwarded-Proto or equivalent is wrong or untrusted, you can see:

• redirect loops
  n- insecure redirects
• cookies missing the Secure attribute in practice
• mixed-content behavior
• application logic that thinks a secure request was insecure

Review certificate operations

Look at:

• certificate renewal process
• private key storage
• fallback certificates
• wildcard certificate scope
• certificate selection for multiple hostnames
• monitoring for expiration failures

The reverse proxy may support dozens of services. A renewal mistake there can create a wide outage surface.

Step 5: Review routing rules for unintended exposure

Routing logic is one of the easiest places for hidden access paths to appear.

Inspect:

• host-based rules
• path-based rules
• default backends
• catch-all virtual hosts
• rewrite rules
• trailing slash normalization
• case sensitivity behavior
• websocket and upgrade handling

Questions that reveal risk

• What happens to requests for unknown hosts?
• What happens to unmatched paths?
• Is there a default backend that should not be public?
• Can a legacy hostname still reach a live service?
• Do internal paths become reachable through rewrites?
• Are admin or debug routes accidentally exposed under a shared prefix?

A classic issue is a catch-all route forwarding unrecognized hostnames to a default application. That may leak content, bypass tenant isolation, or expose a backend never meant for public requests.

Step 6: Inspect access control placement

Access policy can exist in several places at once:

• reverse proxy
• load balancer
• WAF
• identity-aware gateway
• application
• backend service

That is not always bad, but overlapping controls often lead to confusion.

Review where these decisions are actually enforced:

• IP allowlists
• authentication requirements
• path restrictions
• method restrictions
• rate limits
• bot protections
• tenant routing rules

Important consistency checks

• Does the proxy block admin paths before the application sees them?
• Do backend services assume the proxy has already authenticated users?
• Are internal-only routes blocked at the proxy and backend, or just one of them?
• If a second proxy is introduced later, will those assumptions still hold?

A reverse proxy becomes a blind spot when everyone assumes someone else is enforcing the critical rule.

Step 7: Review header rewriting and trust-sensitive metadata

Reverse proxies regularly add or modify headers for useful reasons. But some headers influence application behavior in major ways.

Review any handling of:

• authentication headers
• identity headers from SSO systems
• original host and scheme headers
• caching headers
• CORS headers
• security headers
• custom internal routing headers

Focus on dangerous assumptions

Examples include:

• backend trusts X-Forwarded-User without verifying the proxy is the sender
• application uses Host or X-Forwarded-Host to build redirects without validation
• internal services accept a custom header as proof that a request came through the proxy
• the proxy strips some authentication headers but forgets alternates used by another framework

If a header can influence identity, authorization, URL generation, logging, or cache behavior, it deserves explicit review.

Step 8: Check logging for completeness and usefulness

A reverse proxy is often your best evidence source during an incident, but only if logs capture the right fields and survive failure conditions.

Review whether logs include:

• timestamp with timezone or normalized format
• client IP as received and as interpreted
• forwarded header chain
• request method
• host header
• path and query, where appropriate
• response status
• upstream backend selected
• upstream response time
• TLS details if relevant
• correlation or trace identifiers
• authentication context if handled at the proxy

Ask practical incident questions

Can you answer these from your logs?

• Which backend served the suspicious request?
• Did the proxy redirect, deny, or forward it?
• What host did the client ask for?
• What source IP did the proxy actually trust?
• Did a retry or failover send the request elsewhere?
• Are 4xx and 5xx responses logged with enough context?

Also review where logs go. A strong logging format is not enough if logs stay only on the proxy and disappear during restarts, disk pressure, or compromise.

Step 9: Review failure behavior, not just success paths

Blind spots often appear when something breaks.

Test and review:

• backend unavailable behavior
• health check failures
• timeout handling
• retry rules
• circuit breaker behavior
• fallback backends
• maintenance pages
• custom error pages
• startup order dependencies

Why this matters

During backend failure, some proxies:

• route to a default service unexpectedly
• expose internal error details
• generate misleading status codes
• log only partial context
• retry non-idempotent requests
• hide that traffic was served by a failover pool

These behaviors can complicate both security reviews and incident response.

Step 10: Review administrative exposure

The reverse proxy itself needs protection.

Check for:

• admin dashboards
• local status pages
• metrics endpoints
• config APIs
• hot reload interfaces
• certificate management panels
• orchestration hooks

Questions to ask:

• Are these interfaces bound only to expected addresses?
• Is access restricted by network and authentication?
• Are they visible through the same reverse proxy unintentionally?
• Are changes logged?
• Are credentials or tokens stored securely?

A hardened backend does not help much if the proxy control plane is broadly reachable.

Step 11: Compare documented intent with real behavior

A useful review does not stop at reading config files.

Run practical validation tests from the outside and, where appropriate, from internal networks.

Examples:

• Send requests with fake X-Forwarded-For values and see what the backend logs
• Request unknown hostnames and inspect the response
• Test HTTP and HTTPS separately
• Check redirect destinations and status codes
• Probe paths that should be blocked at the proxy
• Observe what happens when a backend is intentionally unavailable in a test environment
• Verify whether the expected security headers are added consistently
• Confirm whether logs capture the same request fields you need during investigations

This is where many hidden assumptions finally become visible.

A concise reverse proxy review checklist

Use this as a working checklist during reviews.

Architecture and trust

• Document every hop between client and application
• Identify where TLS terminates
• Confirm who can reach the proxy and backends directly
• Define which systems are trusted to set forwarding headers

Client identity and headers

• Review X-Forwarded-*, Forwarded, and similar headers
• Ensure the proxy overwrites or sanitizes untrusted values as needed
• Verify application trusted proxy settings
• Confirm source IP handling matches logging and security controls

Routing and exposure

• Check host-based and path-based routing rules
• Review default virtual hosts and fallback backends
• Test unmatched hosts and paths
• Confirm internal or admin routes are not exposed through rewrites

TLS and transport

• Verify termination and re-encryption design
• Review redirect logic and secure scheme handling
• Check certificate renewal and monitoring process
• Confirm backend assumptions about secure transport

Logging and observability

• Ensure logs capture host, path, source IP context, status, and upstream target
• Confirm logs are centralized and durable
• Check correlation fields for tracing incidents
• Review how proxy errors and backend failures appear in logs

Access control and operations

• Confirm where authentication and authorization are enforced
• Restrict admin, metrics, and config interfaces
• Review change control and auditability for proxy updates
• Test failure behavior and fallback logic

Common findings worth fixing quickly

In many environments, the first review reveals issues like these:

• the backend trusts spoofable forwarding headers
• a default backend answers unknown hostnames
• HTTP to HTTPS redirects behave inconsistently behind another load balancer
• access logs do not show the real client context needed for investigations
• admin paths are blocked in the app but not at the proxy
• certificate renewal depends on a fragile manual step
• backend services are directly reachable, bypassing the proxy entirely

None of these are exotic. That is exactly why they matter.

Final thought

A reverse proxy can improve control and visibility, but only if its role is reviewed as part of the security architecture instead of treated as a transparent relay.

The most useful mindset is simple: assume the proxy changes security-relevant facts about every request, then verify which facts change, who trusts them, and how that trust is enforced.

If you do that before the next outage, migration, or incident, the reverse proxy is far less likely to become a blind spot hiding in the middle of your stack.