Origin IP Discovery Behind a WAF: A Bug Bounty Recon Guide
A WAF can only inspect traffic that reaches it. If the backend still accepts connections from the public internet, the protected hostname and its security rules can be skipped with one IP address and the right Host header. That makes origin discovery more than an infrastructure scavenger hunt: it can turn a blocked application bug into a reachable one.
Start with passive history. Old A records often survive in DNS datasets long after a team moves to Cloudflare, Akamai, or Fastly. Search the apex domain and important subdomains, then compare dates. An address used immediately before the CDN appeared deserves attention. Certificate transparency logs can expose old names such as origin.example.com, direct.example.com, or a forgotten staging host that resolves to the same server.
Follow the side doors
Mail and operational services leak useful relationships. MX records, SPF includes, VPN portals, status pages, and file-transfer hosts may sit in the same provider or subnet as the web origin. JavaScript bundles and error responses occasionally contain an internal API hostname that now resolves publicly. A public repository may have an outdated deployment file with a load balancer name.
Do not assume every related IP is the target. Shared hosting, cloud ranges, and third-party email providers create false matches. You need an application fingerprint.
Request a candidate IP while supplying the target hostname:
GET / HTTP/1.1
Host: app.example.com
With curl, use --resolve app.example.com:443:203.0.113.10 so TLS sends the correct SNI name. This is cleaner than disabling certificate checks. Compare the candidate response with the CDN response: status, title, body length, asset names, cookies, cache headers, and a distinctive error route. A byte-for-byte match is strong; a generic default page proves nothing.
Prove the security difference
The valuable result is not merely “I found an IP.” Show that direct access removes a control. Send one harmless canary request through the normal hostname and then to the candidate origin. Perhaps the edge blocks a test pattern while the origin returns the application's normal validation error. Perhaps a rate limit exists at the edge but the origin has none. Keep the test small and never launch a scanner at an unconfirmed address.
Be careful with unrelated infrastructure. If the certificate, response, or program scope does not tie the IP to the target, stop. Cloud addresses are routinely recycled, and probing the wrong tenant creates legal and reporting problems.
Reporting the exposure
Include the passive clue that led you there, the exact --resolve command, and response differences that establish ownership. Redact any sensitive origin details from public discussion. Explain the practical chain: an attacker can bypass managed filtering, bot controls, IP reputation checks, or edge rate limits and talk straight to the backend.
The fix is network-level, not another WAF rule. Restrict inbound traffic to the CDN's published ranges, use authenticated origin pulls or mTLS where supported, rotate the exposed address, and monitor requests that arrive without the expected proxy headers. The origin should also validate the intended host. Once an address has appeared in DNS history, pretending it is secret will not put it back in the bottle.