Yes, yes you should. Really, you should. It’s a must. What are you waiting for?! Do it!
What is Origin Lockdown?
Locking down your web servers prevents anyone who might still have an old IP address — whether by accident (cached) or malicious intent (via third-party services, edited hosts files, or direct curl requests) — from bypassing Cloudflare.
In short, Origin Lockdown ensures only Cloudflare can access your website’s server directly.
Why Does This Matter?
You’ve just spent a few dollars on a Web Application Firewall (WAF) to protect your custom website — written 15 years ago in a version of PHP that hasn’t been updated in three years — because it has a critical flaw exposing customer data.
Great, you’re protected now, right?
Errr… not really.
If someone knows your origin IP, they can bypass Cloudflare entirely by using tools like curl or by modifying their local hosts file on Windows, Linux, or macOS. That means all those shiny WAF rules you created are completely ignored.
It’s like locking your front door but leaving the window wide open. Sure, most people won’t notice — but the ones who want to break in definitely will.
How to Stop This
Ideally, when onboarding your site to Cloudflare, you should restrict traffic to your web servers so that only Cloudflare and other trusted systems can connect directly. Everyone else should get an “Access Denied” or timeout error.
Here are a few approaches:
- Allow Only Cloudflare IPs
Configure your server or reverse proxy (Apache, Nginx, IIS, Varnish, etc.) to only accept inbound traffic from Cloudflare’s IP ranges. The list can be found here. - Change the IP Address
If possible, change your web server’s IP after enabling Cloudflare.
This is especially useful if your previous IP has been leaked or is under attack.
Keep in mind: if you’re limited to a small subnet (e.g. /28), attackers may find your new IP address. If you are using AWS, then if you can, change the IP address. - Use Authenticated Origin Pulls
Cloudflare can present a TLS certificate to your origin, proving the request really came from Cloudflare. If the certificate doesn’t match, your server rejects the request. This method offers strong security but can add some maintenance overhead — especially if you have internal APIs or scripts that call your origin directly.
TL;DR
Don’t stop at “just using Cloudflare.”
Lock down your origin — otherwise, all that WAF goodness can be bypassed within a few minutes
It’s a small configuration step that makes a huge difference.
Bonus points: Negitive testing is cool. If your monitoring system allows you to force an IP address for the HTTPS request, then why not configure it to make an http request and then if it comes back with a ‘403 access denied’ then accept that as ‘working’. Any other status codes such as ‘http 200 OK’ then create an alert and get someone to fix it. It will save your bacon if someone did a migration and forgot the IP restirctions or someone truned them off to debug an issue and forgot to turn them back on afterwards.
