Access-Control Bypass (X-Forwarded-For)

Many applications restrict certain routes to "localhost only" or "internal IPs only" by checking the source address. The frequent mistake is trusting the X-Forwarded-For header (or X-Real-IP, X-Client-IP, Forwarded...), which a proxy adds but which the client fully controls. If access control reads that header instead of the connection's real IP, forging it is enough:

curl http://<ip>/admin -H 'X-Forwarded-For: 127.0.0.1'

That reaches internal panels, management endpoints or "localhost" functions from the outside.

Other headers and tricks

When the WAF or the backend validates several headers, you try them all (together or separately), aiming at 127.0.0.1, localhost, ::1 or the server's internal IP:

X-Forwarded-For: 127.0.0.1
X-Real-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Forwarded-Host: localhost
Forwarded: for=127.0.0.1

If what it returns is a 403/401 on a specific route, 403 bypass tricks come into play: vary the path (/admin/, /admin/., /admin%2f, /./admin, /Admin, /admin..;/), change the method (POST/HEAD where GET is blocked) or add extensions (/admin.json). Tools like ffuf with a header list, or Burp extensions, automate the sweep.

Requirements

The application (not the proxy) making an authorization decision from a client-controllable header. A well-configured proxy overwrites X-Forwarded-For with the real IP and discards the client's, which defeats the trick. The bypass opens the door to whatever protects that route (an LFI, an admin API), it is not RCE on its own.

How to detect it. The clue is in the logs themselves: requests to restricted routes (/admin, internal endpoints) arriving with an X-Forwarded-For: 127.0.0.1/::1 from an external connection IP. A well-configured proxy never lets that contradiction through, so its appearance is the attack's signature. Always logging the real TCP-layer IP alongside the header makes it easy to hunt; one source trying many header combinations or path variants against /admin gives away the sweep.

Defence. Do not use client-controllable headers to authorize; validate against the connection IP (the TCP layer) or filter at the firewall/reverse proxy, which must rewrite X-Forwarded-For and not trust the incoming one. Related to LFI / path traversal and API information disclosure as what usually sits behind the door.