Does a CloudFront HTTP request with a spoofed Host header bypass my WAF and CloudFront Function and get routed to another AWS customer's distribution?

Question

Hi, I'm trying to understand a specific CloudFront routing behavior related to Host Header Injection, which was flagged as a vulnerability during a recent penetration test.

**My setup:**
* A CloudFront distribution serving `www.test.dev`
* AWS WAF attached with a rule to block requests where the `Host` header is not in my allowed whitelist
* A CloudFront Function on the Viewer Request event that also validates the `Host` header against the same whitelist (returns `403` for unauthorized domains)
* Viewer Protocol Policy: **Redirect HTTP to HTTPS**
* Origin Request Policy: **Managed-AllViewerExceptHostHeader**

**The behavior I'm observing:**

When I send a plain HTTP request with a spoofed `Host` header pointing to a domain that is NOT mine, I receive a `200 OK` response — and the response headers indicate it's coming from **AmazonS3**, not my origin:

```text
curl -I -H "Host: blackhat.com" http://www.test.dev

HTTP/1.1 200 OK
Content-Type: text/html
Server: AmazonS3
X-Cache: Miss from cloudfront
Via: 1.1 d0f73d242b023619d4e4df51e5950fac.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: MRS52-P6
```

**What I understand so far:**

For HTTPS requests, CloudFront's Domain Fronting Protection correctly compares the SNI against the `Host` header and returns `421 Misdirected Request` when they don't match — so HTTPS is protected.

For HTTP requests (no TLS handshake, no SNI), my theory is that CloudFront uses the spoofed `Host` header to perform its **internal routing lookup**, finds another AWS customer's distribution that has `blackhat.com` registered as an Alternate Domain Name (CNAME), and routes the request to **that distribution** — completely bypassing my WAF and CloudFront Function.

**My questions:**

1. Is my understanding correct? When an HTTP request arrives at a shared CloudFront IP with a `Host` header pointing to a different AWS customer's domain, does CloudFront route it to that customer's distribution instead of mine?

2. If so, does this confirm that the `200 OK` response in my test is **not** being served by my origin or infrastructure at all?

3. Since I've already set the Viewer Protocol Policy to **Redirect HTTP to HTTPS**, does this fully mitigate the issue? Or is there still a risk that the HTTP-to-HTTPS redirect itself doesn't fire because the routing happens before my distribution is selected?

I need to understand this clearly so I can properly classify this finding as a **False Positive** in my security audit report — the scanner assumes the `200 OK` is coming from my application, when it appears it's actually coming from an entirely different AWS customer.

Any official clarification or documentation reference would be greatly appreciated!

Florian Turnwald · Accepted Answer

**In short: Yes, CloudFront routes based on the Host header, bypassing your distribution entirely**

The observed behavior is a function of the AWS shared infrastructure routing and not a misconfiguration of your distribution. No data from your origin is exposed, and your security controls (WAF/Functions) remain effective for all traffic intended for your domain.

So, your understanding is correct. This behavior is an inherent characteristic of how CloudFront (and most shared CDNs) handles request routing for the HTTP protocol.

**1. Routing Logic (The "Why"):**

Because CloudFront uses shared Anycast IP addresses, the IP itself does not identify your specific distribution. For plain HTTP requests, CloudFront relies exclusively on the Host header to map the incoming request to a distribution ID.
- Since you are sending Host: blackhat.com, CloudFront’s edge logic routes the request to the distribution that has blackhat.com configured as an Alternate Domain Name (CNAME).
- Consequently, your WAF and CloudFront Functions are never triggered because the request is logically out-of-scope for your distribution.

**2. The "200 OK" Response:**

The 200 OK and Server: AmazonS3 headers confirm that the request was successfully processed by the other customer's origin. You are essentially using your distribution's IP as a proxy to reach a completely different AWS resource.

**3. Mitigation & Audit Classification:**

- **False Positive:** This is a False Positive for your application. The "vulnerability" the scanner sees is not your application responding to an invalid host, but rather CloudFront correctly routing a request to a different intended recipient.
- **HTTPS Protection:** As you noted, for HTTPS, Domain Fronting Protection prevents this. Since modern web traffic is almost exclusively HTTPS, the risk of a malicious actor using your IP to mask traffic to another domain is mitigated by the TLS handshake requirement (SNI/Host match).
- **Redirect Policy:** Your "Redirect HTTP to HTTPS" policy applies only to requests that CloudFront has already matched to your distribution (i.e., requests with Host: www.test.dev). It cannot intercept requests that CloudFront has already routed to another customer based on a spoofed header.

Does a CloudFront HTTP request with a spoofed Host header bypass my WAF and CloudFront Function and get routed to another AWS customer's distribution?

Add your answer

Relevant content