Origin IP Exposure

Origin IP Exposure looks for bypass paths around your WAF/CDN. The classic attack: you put yourdomain.tld behind Cloudflare or CloudFront for protection, but admin.yourdomain.tld or api.yourdomain.tld still points directly at your origin server's IP. An attacker discovers the bare hostname (CT logs, passive DNS, fingerprint matching) and routes attacks at the origin directly, skipping the WAF entirely. Your protection layer protects nothing because the attack path skips it.

How the check works

Two-phase logic:

• Identify the primary host (apex or www) and check whether it is behind a known CDN/WAF provider.
• If the primary is NOT behind a CDN/WAF, the check awards full credit and stops. There is no "origin bypass" if everything is the origin.
• If the primary IS behind a CDN/WAF, walk every other reachable host. For each host in a sensitive bucket (web, api, admin), check whether it also goes through a recognized CDN/WAF. Bare hosts in sensitive buckets are flagged as potential bypass paths.

Detection limitation: this check uses the same narrow header-based detection as WAF/CDN Detection. Providers like Netlify, Vercel, Azure Front Door, Google Frontend, StackPath, and Edgio are not currently recognized, so hosts behind those providers may be flagged as bypass paths even when they are protected. Treat such findings as advisory until the detection list is expanded.

How the verdict maps to evidence

• Pass: primary host has no CDN/WAF (everything is origin; nothing to bypass).
• Pass: primary host is behind a CDN/WAF and no sensitive subdomain bypasses it.
• Fail: at least one sensitive subdomain (web, api, admin bucket) is reachable directly without going through a recognized CDN/WAF. The potential_bypass_hosts array lists each (host, bucket, provider).

Fail: close the bypass paths

For each entry in potential_bypass_hosts, decide whether it should exist and how to lock it down. Three remediation paths:

1. Move the bypass host behind the same CDN/WAF

If api.yourdomain.tld and admin.yourdomain.tld serve real production traffic, they belong behind the same protection layer as the apex. In your CDN provider:

• Cloudflare: turn on the orange-cloud proxy on the bypass record's DNS entry. The change is immediate.
• AWS CloudFront: create or extend a distribution that includes the bypass hostname as an alternate domain (CNAME), then update DNS to point at the *.cloudfront.net hostname.
• Fastly, Akamai, Imperva: add the hostname to your existing service or create a new one, then update DNS.

2. Restrict origin firewall to CDN IP ranges only

Even if a bypass hostname is removed from DNS, attackers can find your origin IP directly via Censys, Shodan, or historical CT log entries. The hard fix is to make your origin refuse traffic that does not come from your CDN. Major providers publish their egress IP ranges:

• Cloudflare: cloudflare.com/ips/ lists IPv4 and IPv6 ranges for all traffic from Cloudflare to your origin. Allow only those ranges in your origin firewall (security group, iptables, ufw, etc.).
• AWS CloudFront: ip-ranges.amazonaws.com/ip-ranges.json with service: "CLOUDFRONT" lists CloudFront IPs.
• Fastly: api.fastly.com/public-ip-list returns the current edge IPs.
• Akamai, Imperva, Sucuri: contact your account team for their current ranges.

Combine this with header-based authentication (a shared secret in a custom header set by the CDN, validated at origin) for defense in depth. Cloudflare's Authenticated Origin Pulls (mTLS) is the strongest version of this.

3. Remove the bypass hostname entirely

If admin.yourdomain.tld or dev.yourdomain.tld is no longer in use, delete the DNS record. Each public hostname pointing at your origin is a discovery vector for attackers.

Check for historical exposure

Closing today's bypass paths does not erase yesterday's. If your origin IP has ever been public, attackers may already have it indexed.

• Search Censys, Shodan, and SecurityTrails for your domain and your origin IP. Anything they have is publicly known.
• Search crt.sh for old certificates issued to internal-looking subdomains. These often leak origin hostnames.
• If your origin IP is heavily exposed and you cannot rotate it, treat the firewall allow-list as your primary defense rather than DNS hygiene.

Verify the fix

• From outside your network, run curl -sI -H "Host: yourdomain" http://<origin-ip>. With the firewall properly locked down, this should fail to connect (timeout or refused).
• Run curl -sI https://api.yourdomain.tld and curl -sI https://admin.yourdomain.tld. Look for CDN/WAF identifying headers (CF-Ray, X-Amz-Cf-Id, etc.). If you see no provider headers and the response is served, the bypass is still open.
• Re-run the RedScore lookup. The verdict moves to pass when no sensitive subdomain bypasses the front door.

Common pitfalls

• Allow-listing CDN IPs in origin firewall but forgetting to update when ranges change. CDN providers add and remove IPs continuously. Use their published JSON or text feeds and automate the firewall update; a static allow-list goes stale and starts blocking legitimate CDN traffic.
• Hiding the origin hostname in DNS but leaving the IP exposed at a different hostname. Origin discovery rarely depends on a clean DNS record; CT logs, IP scan tools, and content fingerprinting all surface the IP regardless. Lock the firewall.
• False-positive bypass for providers not in the detection list. If api.yourdomain.tld is behind Vercel or Netlify, the check may flag it as bypass even though it is protected. Verify manually with curl.
• Sensitive bucket misclassification. The check classifies hosts into web, api, admin buckets by hostname pattern. Subdomains that do not match those patterns (analytics.yourdomain.tld, status.yourdomain.tld) are reviewed but not flagged as bypass risks. Audit them yourself.
• Restricting origin firewall while CDN cache or page rules still allow direct origin pulls. Some CDN configurations let customer rules disable origin authentication. Audit your CDN configuration alongside the firewall.
• Trusting that a brand-new IP is safe. Cloud IPs are recycled. A new EC2, Cloud Run, or Droplet IP may have been someone else's origin yesterday. Apply the firewall lockdown immediately on any new origin host.