The Misconception
IP allowlisting involves configuring your origin server to accept connections only from specific IP addresses – in this case, Cloudflare’s IP ranges. The logic seems sound: by allowing only trusted IPs, you reduce the risk of unauthorized access. Unfortunately, this method overlooks several attack cases that can be exploited.
My Observation
Over the years, I’ve noticed numerous security professionals advocating for IP allowlisting as a primary defense mechanism when using Cloudflare. On platforms like LinkedIn/Medium I’ve commented under such recommendations, pointing out the flaws in relying solely on this method. Below a collection of two recent cases. Despite these discussions, the misconception remains widespread and in real world it can be seen in many environments. For Cloudflare it would be possible to alert their customers about this misconfiguration in their console as they could detect it and I do hope by shining light on this design flaw something will change how the below mitigations are touted.
Attack Case 1: Bypassing IP Allowlisting via Cloudflare’s Services
This method effectively turns Cloudflare’s network into a vehicle for attacks against your own server. The origin server, trusting traffic from Cloudflare IPs, unwittingly becomes vulnerable to exploitation.
- Abusing Cloudflare Workers and Other Services: Cloudflare Workers and similar services allow users to execute custom code and send HTTP requests through Cloudflare’s network.
- Originating Malicious Requests from Cloudflare IPs: Since these requests are routed through Cloudflare, they originate from Cloudflare’s IP addresses, thus bypassing the IP allowlist on the origin server.
Attack Case 2: Overwriting Victim’s Configurations with Proxy Mode
By pointing their own proxy-enabled domain to the victim’s origin server using DNS configurations and disabling security features on their Cloudflare account, an attacker can route malicious traffic through Cloudflare to the victim’s server, effectively overwriting the victim’s configurations and bypassing their security measures.
Visualizing the Attack
Victim Domain Attacker Domain
(example.com) (malicious.com)
| |
| |
[Cloudflare Proxy] [Cloudflare Proxy]
| |
| |
[Origin Server] <----------------- [Attack Requests]
^
|
[IP Whitelisting (Cloudflare IPs)]- The attacker sets up malicious.com with a CNAME record pointing to example.com.
- Both domains are behind Cloudflare’s proxy.
- Requests to malicious.com are proxied through Cloudflare to the origin server of example.com.
- The origin server accepts the requests because they come from Cloudflare’s IP addresses and the Cloudflare-wide Origin Certificate is presented.
By pointing their domain to the victim’s origin and disabling WAF features on their Cloudflare account, the attacker can send requests that bypass the victim’s WAF rules. This setup allows bypassing all security mechanisms (WAF, DDoS, Page-Rules, Workers, possibly even Access.) the Victim configured on the Cloudflare Proxy as the attacker can overwrite them in his Cloudflare account. With nowadays design where more and more logic is being shipped to the Cloudflare edge servers this is a critical risk.
Interestingly, this attack can bypass IP allowlisting and even Authenticated Origin Pulls if Host Header verification is not enforced and the default Cloudflare-wide certificate is used for Origin Pulls.
Part 1/2 of the Solution: Authenticated Origin Pulls
Authenticated Origin Pulls ensure that traffic from Cloudflare to your origin server is authenticated using TLS client certificates.
This authentication becomes particularly important with the Cloudflare Web Application Firewall (WAF). Together with the WAF, you can make sure that all traffic is evaluated before receiving a response from your origin server.
As a mandatory recommendation it is important to use Custom Certificates for authenticated origin pulls instead of the default Cloudflare-wide certificate. Custom certificates add a layer of authentication specific to your domain, preventing attackers from using generic Cloudflare certificates. This approach authenticates the Cloudflare Zone (or your account) rather than just verifying that the request comes from Cloudflare. Make sure that you use a custom certificate per Cloudflare Zone or per Account to prevent against the attack case described by Certitude.
Part 2/2 of the Solution: Host Header Validation
Host Header Validation works by configuring your web server to accept only requests that contain the specific Host header matching your intended domain, rejecting any requests with mismatched or unexpected host headers (e.g. “malicious.com“).
Disable Default Virtual Hosts
Ensure there’s no default server block that catches all requests. If such a block exists, modify it to reject all traffic.
# Default server block to reject all other requests
server {
listen 80 default_server;
listen 443 ssl default_server;
server_name _;
# Reject all requests
return 444;
}Strict Host Header Validation
Configure your web server to respond only to requests with your specific Host header.
server {
listen 443 ssl;
server_name example.com www.example.com;
# SSL configuration
ssl_certificate /path/to/certificate.crt;
ssl_certificate_key /path/to/private.key;
# Enforce strict Host header validation
if ($host !~* ^(example\.com|www\.example\.com)$ ) {
return 444; # Close connection without sending a response
}
# Rest of your configuration
location / {
# Your application logic
}
}Don’t even think about implementing this logic on a Cloudflare Worker, as an attacker would have this logic already bypassed and directly sent the request to your origin server.
Verify the Host Header validation
To test yourself the host header verification is working, you can simply run the following curl requests against your origin server.
curl -I -H "Host: example.com" https://your-server-ip/Should return your website’s content.
curl -I -H "Host: malicious.com" https://your-server-ip/Should return a 444 No Response (Nginx) or 403 Forbidden (Apache).
First public acknowledgement
Initially, when these vulnerabilities were reported by Certitude, Cloudflare categorized them as “informative” and considered them to be a result of design choices rather than security flaws. The the first attack case described by Certitude was already known by some experts, but the second attack case described by Certitude was a new kind, as it allows to bypass the protection provided by authenticated origin pulls if the Cloudflare-wide certificate is being used instead of Custom Certificates (e.g. per zone / per account). The report by Certitude resulted in updated Cloudflare Developer Docs as it can be seen below:
Current Mitigation chosen by Cloudflare
The current mitigation chosen by Cloudflare is to mention this design flaw in their developer documentation. However, in the Cloudflare console, if you have a vulnerable setting applied, it displays in green text: “Current encryption mode: Full (strict). Your encryption mode is set to Cloudflare’s recommendation,” which ultimately provides a false sense of security. I would have hoped for a clearer alert, similar to what they do with other DNS settings – for example, when an MX record is leaking the origin server’s IP, there are clear warnings. But just addressing a design flaw in a developer’s guide is not sufficient, in my opinion. From my testing experience, due to this long-existing design flaw, there is a significant history of environments out there not being properly protected and just relying on a flawed IP allowlisting approach.
Also, when you follow the page and click on the link for “additional security measures for your origin,” there is no mention of Host header verification which needs to happen on the Origin server itself. Instead, more Cloudflare-dependent security mitigations are recommended, such as using the Page Rules feature, adding Transform Rules, or Workers to add an HTTP Auth Header – but most of those solutions can only detect attacks if the attacker’s request is being proxied through the victim’s Cloudflare configuration. The catch is, if an attacker bypasses the proxy altogether, all these Cloudflare-based mitigations become ineffective, leaving the origin server exposed and those defenses essentially worthless.
Conclusion
In conclusion, while IP allowlisting can serve as a supplementary defense-in-depth measure, it is insufficient on its own. Without implementing the essential measures of Authenticated Origin Pulls with Custom Certificates and Host Header Validation, your origin server remains vulnerable to exploitation. IP allowlisting is mostly good to reduce the noise of automated scanners, which are scraping the IP-Range. From the Cloudflare console, there’s no information indicating that even when Authenticated Origin Pull is enabled, there’s a shared responsibility to implement strict host header verification. This lack of transparency can lead to a false sense of security, as many assume that enabling Authenticated Origin Pull is sufficient on its own.