A reverse proxy or CDN/WAF in front of the origin adds a second request parser and a routing table, so security now depends on the proxy and origin agreeing about what the request is and where it goes. These issues belong to the proxy role rather than any single server product, which is why they sit here instead of under Apache/nginx/IIS (a product-specific proxy bug, like nginx variable proxy_pass, lives under its product).
What to check#
- Normalization mismatch: the edge and origin canonicalize paths differently, so a crafted path passes an edge allow/deny rule but resolves to a protected resource at the origin.
- Origin exposure: the backend is reachable directly, bypassing the proxy's filtering, rate limits, and access control entirely.
- Edge header trust: the proxy injects or forwards
X-Forwarded-*/Hostthat the origin then trusts as authoritative.
Related, covered elsewhere#
- HTTP request smuggling (front/back desync on request boundaries) is in Code > Injection > HTTP.
- The application-side consequences of trusting forwarded headers are in Code > Access Control > proxy header trust and Identification; here the focus is the edge wiring that creates that trust.
Pages#
- Normalization mismatch: edge and origin disagree on the canonical path, bypassing path-based access control.
- Origin exposure: reaching the backend directly, past the proxy, WAF, or CDN.
- Edge header trust: how proxy wiring makes forged
X-Forwarded-*/Hostheaders authoritative.
References#
- PortSwigger Web Security Academy: Access control, SSRF, Web cache
- Orange Tsai: reverse-proxy path confusion research