Why Cloudflare Alone Won’t Protect Your WooCommerce Store
The Short Version
- Cloudflare not enough by itself is a gap we see constantly: “I turned on Cloudflare” does not automatically mean a site is protected.
- Cloudflare only protects traffic that actually travels through it. There are two common ways traffic goes around it.
- Some attacks, like card testing, target the checkout directly and never touch the edge at all.
- Real protection is layered: the edge, the origin server, and the application itself. Any one layer alone leaves gaps.
- Having Cloudflare is worth confirming, not assuming: is it actually proxying, can your server be reached around it, and is your checkout protected where the edge cannot reach.
What’s In This Post
Why “I have Cloudflare” is not the same as “I’m protected”
Cloudflare is excellent. We use it every day, on sites we manage across the board.
But we hit the same misconception constantly: “I turned on Cloudflare, so my site is protected.” It is not that simple, and for online stores in particular, that assumption can leave a serious gap.
Cloudflare only protects the traffic that actually goes through it. It sits in front of your site, filtering bad traffic before passing the good along. That only works for traffic that travels through it in the first place, and there is more than one way for traffic to skip that step entirely.
Quick Reference: Real Protection Is Layered
- The edge. Cloudflare actually proxying your traffic, with the right rules turned on.
- The origin. Your server locked down to only accept traffic that comes through Cloudflare, closing the back door.
- The application. WordPress and WooCommerce hardened directly: login protected, checkout protected.
Two common ways traffic goes around Cloudflare
Way 1: The proxy is not actually on
Cloudflare has a per-site toggle for whether it is actively protecting traffic, called “proxied,” or only handling DNS and standing aside, called “DNS-only.” It is easy to leave that toggle in the wrong position.
When it is off, all the security rules go with it, even though the dashboard still looks active. We have found sites where everyone assumed they were protected, and they were not. Nobody had done anything wrong on purpose. The toggle was sitting in the wrong spot the entire time.
Way 2: Attackers go straight to your server
Every site sits on a server with its own address. If an attacker finds that address, they can connect to it directly and skip Cloudflare entirely, unless your server is specifically configured to only accept traffic that comes from Cloudflare.
Cloudflare being switched on does not close this door by itself. Your server has to be told to only listen to Cloudflare, or the front door being locked does not matter much when the back door is standing open.
Some attacks do not happen at the edge at all
Even a perfectly configured Cloudflare setup only sees web traffic. Some attacks are not web traffic problems.
Card testing, where fraudsters run stolen card numbers through a store’s checkout to see which ones still work, targets the checkout and payment gateway directly. A firewall sitting out front cannot tell a fraudulent order from a real one. That protection has to live at the checkout itself, not at the edge.
This is exactly why layered protection matters. The edge catches what the edge can see. It was never going to catch everything.
Real protection is layered
Real protection is the edge, the origin, and the application, working together. Any one layer by itself leaves gaps.
We saw this play out directly with a client site that took a sudden flood of bot traffic. Here’s what properly configured edge protection looked like in practice, catching the flood before it ever reached the server. That is the edge layer doing its job. It still is not the whole picture on its own.
- Edge: Cloudflare actually proxying your traffic, with rules tuned to your site.
- Origin: Your server closed to anyone who is not coming through Cloudflare.
- Application: WordPress and WooCommerce hardened where the edge cannot reach, especially login and checkout.
The bottom line: Cloudflare not enough by itself
Cloudflare is a great layer. It is not a force field.
“We have Cloudflare” is worth confirming rather than assuming. Confirm it is actually switched on. Confirm your server cannot be reached around it. Confirm your checkout and login are protected in the places the edge cannot reach.
Not sure where your own setup actually stands? Our free Uh Oh Score scan checks for exactly this kind of gap, no strings attached.
Frequently asked questions
What is the difference between Cloudflare “proxied” and “DNS-only”?
Proxied means Cloudflare actively sits in front of your traffic, filtering it and applying your security rules before anything reaches your server. DNS-only means Cloudflare is only handling domain lookups and stepping aside for everything else, so none of the security rules apply even though the account is active.
How can I tell if my server can be reached without going through Cloudflare?
If your server’s own address is publicly known or discoverable, and nothing is configured to reject traffic that does not come from Cloudflare’s IP ranges, then yes, it can be reached directly. This usually requires a firewall rule at the server level rather than anything inside the Cloudflare dashboard.
Does Cloudflare protect against card testing attacks?
Not on its own. Card testing targets your checkout and payment gateway directly, which is application-level traffic that looks like normal store activity to an edge firewall. Stopping it requires protection built into the checkout itself, alongside whatever Cloudflare is doing at the edge.
If I already have Cloudflare, do I still need WordPress security hardening?
Yes. Cloudflare covers the edge layer, but your login page, your checkout, and your server configuration are separate layers that Cloudflare was never designed to reach. A site can have excellent edge protection and still have an open door at the application level.
How do I lock my server down to only accept Cloudflare traffic?
This is typically done with a firewall rule at the server or hosting level that only allows connections from Cloudflare’s published IP ranges, combined with keeping your origin server address out of public DNS history where possible. It is a server configuration task, not a Cloudflare dashboard setting.
Is Your Cloudflare Setup Actually Doing Its Job?
Most sites have Cloudflare turned on. Far fewer have confirmed it is proxied, that the origin is locked down, and that the application layer is hardened too. Our care plans check all three, not only the one that is easiest to see. We manage 105+ active client sites, and this is part of the baseline for every one of them.
