Cloudflare is by far one of the best web services out there for securing websites. They offer DDOS protection, CDN, and a load of other performance-enhancing features that can make your website load faster, but there are some pitfalls you should be aware of before leaving your infrastructure's uptime in Cloudflare's hands.

Image source: Cloudflare.

Firewalling Cloudflare

When you sign up for Cloudflare, all you need to do is change your nameservers over to them and your visitors will soon be accessing Cloudflare's servers instead of your own. The only issue with this is that your origin's old IP address is still known to anyone that has visited your website before, so if a malicious actor is able to use a tool like SecurityTrails' DNS history tool, it can be trivial to obtain the origin IP address.

The best way to protect against this is by setting up a firewall at the provider level. By offloading the IP filter to your provider, instead of relying on iptables (which is fine if your cloud service doesn't offer a firewall) you won't have to deal with potential transport layer DDOS attacks overwhelming your server itself.

Doing this depends on your provider, but i've created guides for some popular providers:

You can find all of Cloudflare's IP addresses at if you use a different provider.

Host header protection

Firewalling your server to only allow Cloudflare is only half the battle. If your service has a dedicated IP address, you need to make sure you are only responding via your service's correct HOST header.

Threat Model

  1. Attacker knows your website has an origin IP of (via DNS history tools) but you firewalled Cloudflare like above so they can't directly make requests
  2. Attacker signs up for Cloudflare and adds their own domain
  3. Attacker adds your origin IP to their DNS tab (and enables the Proxy/Orange Cloud)
  4. Attacker now makes malicious requests to their own domain

In the above scenario, Cloudflare will not apply any of the settings from your CF account to the requests (eg WAF, firewall rules) since it doesn't know your website is part of the equation. If your origin responds to any Host header with your website's main configuration, the attacker is now able to access your origin without Cloudflare's protections kicking in.

Graphviz representation. Graph code

To fix this, you need to make sure there is a "default" host set up that can't access your application. If you use an AWS Application Load Balancer (ALB), This can be done by setting up a rule on your listeners:

When using nginx, you need to make sure that your current server block has the correct server_name directive with your hostname in it. Then, you simply make another server block, but this time you set server_name to something like an underscore _ and have it return nothing or a 400 (bad request) error.

When dealing with SSL and nginx, use a snakeoil certificate or self-signed certificate.

server {
	listen 80 443 ssl;
	ssl_certificate /snakeoil.crt;
	ssl_certificate_key /snakeoil.key;
	server_name _;
	return 400;
server {
	listen 443 ssl;
	ssl_certificate /examplecom.crt;
	ssl_certificate_key /examplecom.key;
	location / {

Since Cloudflare itself protects against HOST header spoofing, there is no way for an attacker to get around your site's Cloudflare configuration and protections. The Host header can't even be changed with workers.