Reverse proxies solve problems — and create new places to miss them

A reverse proxy can make infrastructure easier to publish, scale, and protect. It can terminate TLS, route traffic by hostname or path, apply rate limits, centralize logging, and hide backend details from the internet.

That convenience is exactly why reverse proxies deserve periodic review.

When a proxy sits between users and applications, it becomes part of the security model whether the team planned for that or not. A configuration that looks clean on a diagram can still create operational blind spots:

• the backend trusts the wrong client IP
• TLS is strong at the edge but weak internally in unexpected ways
• logs show the proxy address instead of the real requester
• internal admin paths are accidentally published
• a default virtual host catches traffic nobody intended to serve
• direct backend access bypasses authentication, WAF, or rate limiting

This tutorial gives you a practical way to review a reverse proxy deployment before it quietly hides risk.

What a good reverse proxy review is trying to answer

Do not start with syntax. Start with security questions.

A useful review should answer:

1. What trust boundary does the proxy enforce?
2. What identity and context does it pass to the backend?
3. Can users or attackers bypass it?
4. Will logs and alerts still be trustworthy during a real incident?
5. What happens when routing, upstream health, or TLS behavior fails?

If you only check whether requests return 200 OK, you are testing availability, not the integrity of the design.

Step 1: Map the actual request path

Before reviewing settings, document the real flow of traffic.

For each published application, note:

• public DNS name
• public listener ports
• reverse proxy product and instance location
• TLS termination point
• whether traffic is re-encrypted to the backend
• backend hostnames, IPs, and ports
• any CDN, WAF, load balancer, or ingress layer in front of the proxy
• any authentication layer in front of the app

A simple text map is enough:

Client -> CDN/WAF -> Reverse Proxy -> App Load Balancer -> Application

Or:

Client -> Reverse Proxy -> Container Service

This matters because many blind spots come from assuming a certain layer is responsible for something:

• “The load balancer handles TLS validation.”
• “The app already knows the real client IP.”
• “The backend is internal, so direct access is impossible.”

If those assumptions are wrong, security gaps form between teams.

Review tip

If two different teams own the edge and the application, ask each team to explain the path independently. Mismatched answers usually reveal hidden dependencies fast.

Step 2: Confirm what the proxy is supposed to protect

A reverse proxy can enforce several controls, but not every deployment uses all of them.

Make the expected responsibilities explicit:

• TLS termination
• HTTP to HTTPS redirect
• hostname-based routing
• path-based routing
• authentication offload
• rate limiting
• request size limits
• header normalization
• security header injection
• bot or abuse filtering
• caching
• access logging

Why this matters: if a control is assumed but not explicitly configured or tested, it often exists only on paper.

For example:

• Security assumes rate limiting is on, but it only exists for one hostname.
• Operations assumes all applications get HSTS, but one legacy virtual host does not.
• Developers assume the app is only reachable through the proxy, but a security group exposes the backend directly.

Step 3: Review trust boundaries around client IP and forwarded headers

One of the most common reverse proxy mistakes is mishandling client identity.

Backends frequently rely on forwarded headers such as:

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

Those headers are useful, but dangerous if the backend trusts them from untrusted sources.

What to check

1. Can clients send spoofed forwarding headers?

If the proxy simply appends or forwards user-supplied values without normalization, logs and app logic may trust attacker-controlled data.

2. Does the backend trust only known proxy addresses?

Applications and frameworks should only accept client IP information from approved proxy hops.

3. Is the number of expected proxy hops documented?

In layered deployments, incorrect trusted hop counts can produce false client attribution.

4. Do logs record both proxy and derived client identity?

During an incident, you want enough context to reconstruct what happened.

Why this matters

If the app uses client IP for:

• access control
• geo restrictions
• rate limits
• fraud decisions
• audit logs

then a weak forwarding model turns the proxy into a source of false evidence.

Practical test

Send requests with custom forwarded headers from a non-trusted origin and confirm they are ignored or rewritten. Then verify what appears in:

• proxy access logs
• application logs
• security analytics
• rate limit counters

Step 4: Check whether backends are reachable without the proxy

A reverse proxy cannot protect traffic that never passes through it.

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

Look for bypass paths

• backend public IPs still exposed
• open security groups or firewall rules
• internal DNS names reachable from untrusted segments
• container node ports published directly
• alternate listener ports not covered by the proxy
• management interfaces on the same host

If the backend can be accessed directly, an attacker may bypass:

• authentication at the proxy
• request filtering
• TLS policy
• rate limiting
• logging and alerting controls

Quick validation approach

For each app behind the proxy:

1. Identify backend IPs and ports.
2. Attempt connection from outside the expected trust zone.
3. Confirm whether the backend responds differently from the proxied path.
4. Check whether admin or debug routes become reachable directly.

A secure design usually makes the proxy the required path, not just the convenient one.

Step 5: Review TLS behavior on both sides of the proxy

TLS review should not stop at “the browser shows a lock.”

Reverse proxy deployments often have two separate TLS decisions:

• client to proxy
• proxy to backend

Client to proxy checks

Verify:

• only intended TLS versions and ciphers are enabled
• certificates match current hostnames
• redirect behavior is consistent
• HSTS is applied where appropriate
• certificate renewal paths are understood
• HTTP listeners do not expose unintended content

Proxy to backend checks

Verify:

• whether traffic is plaintext or encrypted
• whether backend certificates are validated
• whether hostname verification is enabled
• whether self-signed or internal CA trust is documented
• whether certificate failures fail closed or silently downgrade

Why backend TLS still matters

In many environments, “internal” does not mean “implicitly trustworthy.” Shared networks, flat VLANs, over-permissive east-west access, and temporary troubleshooting changes can all weaken internal assumptions.

Even if plaintext to the backend is acceptable in a specific segment, that should be a documented decision, not an accident.

Step 6: Inspect routing rules for unexpected exposure

Routing logic can quietly publish more than intended.

Review:

• wildcard hostnames
• catch-all virtual hosts
• default backends
• path rewrites
• prefix stripping
• regex routes
• case sensitivity assumptions
• trailing slash behavior

Common risk patterns

Default site catches unknown hostnames

Requests for unrecognized domains may land on a real application instead of a harmless deny response.

Path rewrites expose hidden endpoints

A rule intended to publish /app/ may accidentally make /admin/ or framework internals reachable after rewriting.

Mixed host and path logic creates overlap

Two applications may unintentionally share a route space, especially during migrations.

Legacy routes remain active

Temporary compatibility rules often outlive the migration they were created for.

Practical review method

Create a route inventory with:

• hostname
• path match
• backend target
• rewrite behavior
• authentication expectation
• owner

Then test:

• unknown hostnames
• malformed paths
• encoded paths
• doubled slashes
• alternate casing
• direct access to old prefixes

The goal is to identify traffic that reaches a backend when policy says it should be rejected.

Step 7: Review header handling beyond client IP

Reverse proxies routinely add, drop, or rewrite headers. That behavior affects both security and application correctness.

Headers worth reviewing

• Host
• X-Forwarded-Host
• X-Forwarded-Proto
• X-Forwarded-Port
• Authorization
• Cookie
• Connection
• Upgrade
• security headers such as Strict-Transport-Security, Content-Security-Policy, and X-Frame-Options

What to look for

Host header trust

Applications that generate links, redirects, or tenant context from host data can behave dangerously if host handling is loose.

Authorization propagation

Make sure authentication headers are forwarded only where intended and are not leaked across routes.

Duplicate header behavior

Some proxies and apps handle duplicates differently. That can create bypasses or inconsistent logging.

Security header consistency

If the proxy injects security headers, verify that all relevant routes receive them and that upstream apps are not unintentionally overriding them.

Connection-specific header cleanup

Proxies should properly normalize hop-by-hop headers so backend behavior stays predictable.

Step 8: Validate logging as if you will need it during an incident

A reverse proxy is often the best vantage point for HTTP visibility. It is also a common place for logging gaps.

Minimum questions to answer

• Do access logs exist for all published applications?
• Do they capture the real client IP correctly?
• Do they include host, path, method, status, response size, and upstream target?
• Do they record request IDs or correlation IDs?
• Are TLS handshake failures, routing failures, and upstream errors visible?
• Are logs centralized quickly enough to survive host loss?

Blind spots to look for

Only successful requests are logged

Failed routing and denied traffic can be just as important as successful requests.

Error logs are too sparse

A generic upstream failure message may not help distinguish timeout, TLS validation failure, DNS resolution error, or backend refusal.

Log formats differ across environments

If staging and production use different fields, operational learning does not transfer well.

Sensitive data leaks into logs

While increasing visibility, avoid logging credentials, session tokens, or personal data unnecessarily.

Practical recommendation

Pick a sample request and trace it through:

1. edge access log
2. reverse proxy log
3. application log
4. SIEM or log pipeline

If correlation is difficult during a calm review, it will be worse during an outage or attack.

Step 9: Review failure behavior, not just normal behavior

Many reverse proxy reviews focus on success paths. Real incidents usually happen on failure paths.

Test what happens when:

• the backend is down
• DNS for the upstream fails
• backend TLS validation fails
• the backend returns large headers
• request bodies exceed expected size
• websockets or long-lived connections are interrupted
• the proxy reloads configuration
• one upstream node is slow rather than fully offline

Why this matters

Failure handling can create hidden security and availability problems:

• fallback routes send traffic to the wrong backend
• custom error pages leak environment details
• health checks mark unhealthy nodes as healthy
• retries repeat non-idempotent requests
• timeout values hide upstream distress until users feel it

A reverse proxy should fail in a way that is observable, bounded, and consistent with policy.

Step 10: Examine admin and management surfaces

Reverse proxy products often include operational interfaces such as:

• status endpoints
• metrics endpoints
• dashboards
• API listeners
• configuration sync channels
• certificate management endpoints

These can become serious blind spots if they are reachable from broader networks than intended.

Check for

• dashboards exposed without strong authentication
• metrics endpoints revealing route names or internal topology
• health endpoints leaking version data
• admin APIs bound to all interfaces
• default credentials in lab-to-production migrations

This is especially important in container and orchestration environments where service discovery can accidentally publish internal ports.

Step 11: Compare configuration intent with live behavior

A clean configuration file is not enough. Runtime drift happens.

Examples:

• an old site definition is still loaded
• a container image uses different defaults than expected
• a hotfix changed trust proxy settings in the app but not in code
• a cloud load balancer adds headers differently than the team assumes
• certificates renewed on one node but not another

Practical validation techniques

• inspect active listeners on the host or service
• list loaded routes from the running platform if supported
• send test requests and compare observed headers
• verify actual certificates and chains presented live
• compare infrastructure-as-code definitions with deployed state

The point is simple: review the service that is running, not only the config someone intended to deploy.

A compact reverse proxy review checklist

Use this as a working checklist during audits.

Architecture and exposure

• Public entry points are documented.
• Backend systems are not directly reachable from untrusted networks.
• The proxy is the required path for protected applications.
• Trust zones between edge, proxy, and backend are understood.

Identity and headers

• Client IP handling is correct and resistant to spoofing.
• Trusted proxy hops are explicitly defined.
• Host and forwarding headers are normalized as intended.
• Sensitive authentication headers are forwarded only where necessary.

TLS and transport

• TLS policy is reviewed at the public edge.
• Backend TLS expectations are documented and tested.
• Certificate validation to upstreams is not assumed.
• Redirect and HSTS behavior are consistent.

Routing and application exposure

• Default vhosts and catch-all routes are intentional.
• Path rewrites have been tested for edge cases.
• Legacy routes are removed or documented.
• Unknown hosts and paths fail safely.

Visibility and operations

• Access and error logs are useful and centralized.
• Request tracing across proxy and app is possible.
• Failure modes produce actionable telemetry.
• Admin and metrics interfaces are restricted.

Common findings that deserve quick remediation

During reviews, these issues often provide the highest defensive value to fix first:

Direct backend exposure

If a backend is reachable without the proxy, close that gap before tuning anything cosmetic.

Incorrect real client IP attribution

This affects logging, rate limits, and incident response all at once.

Catch-all routes serving real content

Unknown hostnames should usually be denied or sent to a neutral response.

Backend TLS without validation

Encryption without identity verification is not the same as trustworthy transport.

Incomplete logging for denied or failed traffic

Blind spots often live in requests that never make it to the app.

Exposed admin endpoints

Operational convenience should not become an internet-facing service by accident.

How often should you review a reverse proxy setup?

Review when any of these happen:

• a new application is published
• TLS architecture changes
• a CDN, WAF, or load balancer is added or removed
• authentication moves to the edge
• routes are migrated or consolidated
• logging pipelines change
• a security incident raises attribution questions

Even without major changes, a recurring review is worthwhile because reverse proxies accumulate exceptions over time.

Final thought

A reverse proxy is not just a traffic director. It is a security boundary, an evidence source, and often a policy enforcement point.

That makes it dangerous to leave on autopilot.

The most effective review is not product-specific. It is a disciplined check of trust, identity, exposure, logging, and failure behavior. If you can clearly explain who the proxy trusts, what it forwards, what it blocks, and how you would investigate an incident through it, you are much less likely to let it become a blind spot.