Reverse Proxy Review Checklist: Finding Hidden Trust Gaps Before They Turn Into Exposure

A reverse proxy usually arrives with good intentions. It centralizes TLS, simplifies routing, adds caching, supports load balancing, and can enforce useful controls before traffic reaches an application.

That same convenience is why it deserves deliberate review.

When teams stop thinking about the proxy as a security-sensitive component, it becomes a quiet blind spot. Applications start trusting headers they should not trust. Logs lose the real client IP. Internal services become reachable through unexpected paths. TLS assumptions drift. Monitoring sees the proxy, but not what the proxy is actually doing.

This tutorial walks through a practical review process for reverse proxy deployments so you can find hidden trust gaps before they become incidents.

---

Why reverse proxies create blind spots

A reverse proxy sits in a powerful position:

• It sees inbound requests first.
• It may terminate TLS.
• It may add, remove, or rewrite headers.
• It decides where traffic goes.
• It often shapes what the backend believes about the client.
• It may generate the logs your responders rely on.

That means a bad assumption at the proxy layer can ripple into multiple systems.

Common examples include:

• Backends trusting X-Forwarded-For from untrusted sources
• Admin paths accidentally published through broad routing rules
• Security teams seeing only proxy IPs in logs
• TLS being strong at the edge but weak or missing between proxy and backend
• Health check endpoints disclosing sensitive internal details
• Default error pages exposing product and version information

A reverse proxy review is not just a configuration audit. It is a trust and visibility audit.

---

Start with a simple architecture map

Before checking directives or toggles, map the flow.

Document:

1. Who can reach the proxy

   • Internet users
   • Internal users
   • Partners
   • CDN or DDoS provider
   • VPN users

2. What the proxy forwards to

   • Application servers
   • API gateways
   • Legacy services
   • Admin interfaces
   • Internal dashboards

3. Where TLS starts and ends

   • Client to CDN
   • CDN to reverse proxy
   • Reverse proxy to backend

4. Which identity signals the backend trusts

   • X-Forwarded-For
   • X-Real-IP
   • X-Forwarded-Proto
   • Forwarded
   • Client certificate metadata
   • SSO headers injected upstream

5. What logs exist at each layer

   • Edge/CDN logs
   • Reverse proxy access/error logs
   • WAF logs if present
   • Backend application logs

This architecture map helps you review behavior in context instead of reading isolated config blocks.

---

Step 1: Define the trust boundary clearly

The most important review question is simple:

What does the backend trust just because traffic came through the proxy?

That trust may include:

• Source IP information
• Original protocol information
• Authenticated identity headers
• Request path normalization
• Rate limiting decisions
• Request size enforcement

If the backend accepts those values without verifying that they came from a trusted proxy, attackers may be able to spoof them.

What to review

• Are backend services reachable directly, bypassing the proxy?
• Are firewalls or security groups restricting backend access to the proxy tier only?
• Are applications configured to trust forwarded headers only from known proxy IPs?
• If there are multiple proxy layers, is trust limited to the correct upstream ranges?

Red flags

• Backend exposed to the internet for convenience or testing
• Application framework set to trust all proxies
• No documentation showing which headers are authoritative
• Teams assuming the load balancer and reverse proxy behave the same way

Practical goal

A backend should trust proxy-provided metadata only when the request actually came from a trusted proxy path.

---

Step 2: Review forwarded headers with suspicion

Forwarded headers are one of the most common areas where reverse proxy mistakes become security problems.

Headers often involved include:

• X-Forwarded-For
• X-Real-IP
• X-Forwarded-Proto
• X-Forwarded-Host
• Forwarded
• Custom identity headers such as X-User, X-Email, or X-Authenticated-User

What can go wrong

If the proxy appends to or passes through client-supplied headers without normalization, the backend may:

• Log a forged source IP
• Apply allowlists incorrectly
• Generate insecure redirects
• Believe a request was HTTPS when it was not
• Trust a fake authenticated identity header

Review checklist

• Does the proxy overwrite sensitive forwarded headers instead of blindly passing them through?
• Does the backend parse these headers safely and consistently?
• Are duplicate header cases understood and tested?
• Are custom auth headers stripped from inbound client traffic before the proxy injects trusted values?

Good review question

If an attacker sends their own X-Forwarded-For or X-Forwarded-Proto, what exact value reaches the application?

If the answer is unclear, the setup needs attention.

---

Step 3: Confirm client IP visibility is accurate

Many defensive controls depend on correct client IP attribution:

• Rate limiting
• Geo-based filtering
• Abuse detection
• Account lockout logic
• Incident response
• Forensics

If your proxy logs only its immediate upstream or if your backend sees only the proxy address, your visibility may be incomplete.

Review both layers

At the proxy layer:

• What does the access log record as the client IP?
• If a CDN or load balancer sits in front, is the correct upstream header being consumed?
• Are trusted upstream ranges configured explicitly?

At the application layer:

• Does the app log the real client IP or only the proxy IP?
• Does alerting rely on values that can be spoofed?
• Are authentication or abuse workflows tied to the wrong address source?

Red flags

• All users appear to come from one internal address
• Different services disagree on the same client IP
• Security tooling uses a different IP source than the application
• Proxy trusts IP headers from any source instead of a known front-end provider

A reverse proxy that breaks attribution weakens both prevention and response.

---

Step 4: Inspect TLS termination and re-encryption paths

One of the most common assumptions is that “TLS is enabled,” therefore the traffic path is secure. A review should be more specific.

Questions to answer

• Where is TLS terminated?
• Is traffic re-encrypted to the backend?
• Are backend certificates validated properly?
• Are internal hops treated as trusted just because they are internal?
• Are redirects and HSTS policies consistent with the actual deployment?

Why this matters

A reverse proxy may present a strong public TLS posture while forwarding to backends over plaintext or over weakly validated TLS. In segmented environments, teams sometimes accept this risk intentionally, but it should be explicit and documented.

Review checklist

• Verify certificate management and rotation at the edge.
• Check protocol and cipher policy against current standards.
• Confirm backend TLS validation is enabled if re-encryption is used.
• Review whether X-Forwarded-Proto influences security-sensitive app behavior.
• Test whether HTTP endpoints still exist and how they redirect.

Red flags

• Backend certificate verification disabled to “make it work”
• Sensitive admin apps reachable over plaintext behind the proxy
• Mixed HTTP/HTTPS behavior causing secure cookies or redirects to fail
• Proxy and application disagreeing on whether the session is secure

The goal is not perfect uniformity. The goal is understanding exactly where trust changes and whether the current design matches your risk tolerance.

---

Step 5: Review routing rules for accidental exposure

Reverse proxies often begin with a few clean routes and grow into layered exception logic over time.

That growth creates exposure risk.

What to inspect

• Host-based routing
• Path-based routing
• Regex rules
• Rewrite logic
• Fallback/default backends
• Static file handling
• Special-case admin or diagnostic endpoints

Common mistakes

• A catch-all route exposing a backend never intended for public access
• Internal paths published under a shared host
• Rewrites that bypass expected access control checks
• Overlapping path rules sending traffic to the wrong application
• Default virtual host serving unexpected content

Useful test cases

Try requests for:

• Unknown hosts
• Unused subdomains
• Similar path prefixes
• Trailing slash variants
• Encoded path characters
• Upper/lowercase path differences where relevant
• Hidden admin, debug, metrics, or health endpoints

Reviewing routes is partly about configuration and partly about behavior. Always test what the proxy actually does, not just what the config appears to say.

---

Step 6: Check header-based security controls

Reverse proxies are often used to add or enforce security headers, but this can create false confidence when responsibilities are unclear.

Review areas

• Which layer sets security headers: proxy, application, or both?
• Are headers consistent across all virtual hosts and response paths?
• Do redirects and error responses include required protections where applicable?
• Are upstream headers being unintentionally stripped?

Headers worth validating

• Strict-Transport-Security
• Content-Security-Policy
• X-Frame-Options or equivalent framing policy
• X-Content-Type-Options
• Referrer-Policy
• Cache-Control on sensitive content

Why this matters in proxy reviews

If the application assumes the proxy adds headers, and the proxy applies them only on some paths, your real posture may be weaker than expected. Error pages, static assets, and alternate hostnames often reveal these gaps.

---

Step 7: Review request size, timeouts, and buffering behavior

A reverse proxy influences availability and abuse resistance as much as confidentiality.

Default limits may be too permissive or too strict.

Review checklist

• Maximum request body size
• Header size limits
• Connection timeout values
• Read/write timeout values
• Idle timeout settings
• Buffering behavior for uploads and responses
• WebSocket or long-lived connection handling where relevant

Why this matters

Poorly tuned values can lead to:

• Slow client resource exhaustion
• Unexpected 413 or 502 errors during normal use
• Request smuggling edge cases in inconsistent parsing chains
• Application instability under large uploads or long-running requests

This part of the review is not just performance tuning. It helps expose unsafe assumptions between edge and backend parsing behavior.

---

Step 8: Validate logging for investigations, not just dashboards

Many proxy logging setups are good enough for traffic graphs but weak for incident response.

A defensive review should ask whether the logs can answer practical questions after an event.

Can your logs tell you:

• The real client IP?
• The upstream/backend selected?
• The requested host and path?
• The response code and response size?
• Request timing and upstream timing?
• TLS/protocol details when relevant?
• Correlation identifiers that match backend logs?

Review for consistency

• Are timestamps aligned across systems?
• Is a request ID passed from proxy to backend?
• Are error logs retained long enough?
• Are log formats documented and parsed correctly by your SIEM?
• Are sensitive headers or tokens accidentally being logged?

Red flags

• No request correlation between proxy and application logs
• Security team cannot distinguish edge rejection from backend rejection
• High-value endpoints excluded from logs for performance reasons
• Log pipelines dropping fields responders assume are present

A reverse proxy should improve visibility. If it obscures causality, it is doing the opposite.

---

Step 9: Review error handling and default responses

Default behavior often reveals more than teams expect.

Check for:

• Version banners
• Product-specific error pages
• Backend leakage in 502/504 responses
• Stack traces or internal paths passed through from upstream services
• Different behavior between valid and invalid hosts

Why it matters

Verbose or inconsistent error handling can help attackers map the environment. It also complicates detection when failures at different layers all look the same to operators.

A good review verifies that:

• Public-facing errors are controlled and minimal
• Internal details remain in logs, not responses
• Operators can still distinguish routing, TLS, and upstream failures in observability tools

---

Step 10: Protect administrative and diagnostic surfaces

Reverse proxies often expose more than application traffic.

Potentially sensitive surfaces include:

• Management UI
• Metrics endpoints
• Status pages
• Health checks
• Debug routes
• ACME challenge handling
• Configuration test endpoints in containerized stacks

Review questions

• Are status or metrics endpoints internet-accessible?
• Are health checks returning detailed dependency information?
• Is admin access restricted by network and identity controls?
• Are legacy or temporary routes still enabled?

Red flags

• /status, /metrics, /debug, /healthz, or similar paths exposed without restriction
• Admin consoles living on the same public hostname as user traffic
• Operational shortcuts left in place after migrations

These paths are easy to forget because they are useful to operations teams. They are also useful to attackers doing reconnaissance.

---

Step 11: Test from an attacker mindset

A reverse proxy review should include safe behavioral testing.

You are looking for mismatches between what the proxy team believes and what the application actually receives.

Practical test ideas

• Send forged forwarded headers and inspect backend logs.
• Try direct backend access if network controls are supposed to prevent it.
• Request undefined hosts and paths.
• Test path normalization and encoded characters.
• Compare HTTP and HTTPS behavior.
• Trigger oversized headers or bodies in a controlled way.
• Compare responses through CDN, proxy, and backend where permitted.

What you want to find

• Header trust confusion
• Route overlap
• Inconsistent redirects
• Leakage in errors
• Monitoring gaps
• Security controls applied at one layer but not another

Keep this testing defensive and authorized. The goal is validation, not disruption.

---

Step 12: Look for configuration drift and ownership gaps

Many proxy weaknesses are not caused by one bad decision. They appear over time through drift.

Ask operational questions

• Who owns the proxy configuration?
• Where is the source of truth?
• Are changes peer-reviewed?
• Are emergency edits captured later in version control?
• Is there a standard for introducing new routes or headers?
• Are decommissioned backends removed promptly?

Why this matters

A technically sound configuration can still become a blind spot when nobody clearly owns:

• trust header policy
• route lifecycle
• certificate renewal expectations
• logging format changes
• admin surface restrictions

Ownership is part of security posture.

---

A compact reverse proxy review checklist

Use this as a practical field list during assessments:

Trust and exposure

• Backends are not directly reachable unless intentionally designed
• Trusted proxy IP ranges are explicit
• Applications do not trust all forwarded headers from all sources

Headers and identity

• Sensitive headers are overwritten or stripped appropriately
• Custom identity headers cannot be supplied by clients
• Client IP handling is consistent across proxy and backend

TLS

• Termination points are documented
• Re-encryption and certificate validation are reviewed
• HTTP-to-HTTPS behavior is tested

Routing

• Catch-all and default routes are understood
• Admin, debug, and internal paths are restricted
• Rewrite rules are tested, not just read

Logging and monitoring

• Logs capture real client identity and routing context
• Request IDs correlate across layers
• Sensitive values are not over-logged

Resilience and behavior

• Limits and timeouts match application needs
• Error pages do not leak internals
• Undefined hosts and malformed requests are handled safely

---

Common review findings worth fixing early

In real environments, a few issues appear repeatedly:

1. Backends trust spoofable IP headers
2. Direct backend access bypasses the proxy entirely
3. Admin or metrics endpoints are exposed through shared routes
4. TLS is strong externally but weak or undocumented internally
5. Logs cannot reconstruct which upstream handled a suspicious request
6. Temporary rewrites become permanent attack surface

These are valuable findings because they often affect several downstream controls at once.

---

Final thought

A reverse proxy should reduce complexity at the edge, not hide it.

The safest way to review one is to treat it as a decision point for trust, identity, routing, and visibility. If you only evaluate whether requests are being forwarded successfully, you will miss the conditions that turn the proxy into a blind spot.

Review what the proxy accepts, what it changes, what the backend believes because of it, and what your responders can prove afterward.

That is the difference between a reverse proxy that helps defend your environment and one that quietly weakens it.