Do I need both Cloudflare and a security plugin?

For most sites the strongest setup is a small amount of both. The edge absorbs attack traffic before your server pays for it, and a plugin handles jobs only software inside WordPress can do, such as malware scanning and file integrity checks. What you can usually drop is the overlap: plugin features that try to block traffic.

Which plugin features become redundant behind Cloudflare?

The traffic-facing ones: login attempt limiting, IP blocking, rate limiting, firewall rules, and CAPTCHA on forms are all done earlier and cheaper at the edge. Features that inspect your WordPress installation itself, such as malware scans, file change detection, and update reminders, stay useful.

Why does it matter where the blocking happens, if the attack gets blocked either way?

Cost and exposure. A request blocked by a plugin has already consumed your server: PHP booted, the database answered, and under a flood that alone can take a site down. A request blocked at the edge never arrives. The plugin also runs on the same machine it defends, so a flaw in WordPress or the plugin itself can be attacked directly; the edge sits outside that blast radius.

Are all security plugins the same in this respect?

No. Plugins differ widely in what they do and how well they do it, and some pair with their own cloud firewalls that also act before traffic arrives. The point of this guide is not that plugins are bad; it is that anything running inside WordPress starts after your server has already answered the door.

Security Plugins vs the Edge: What Runs Where

Every security tool you can install answers one question differently: at what point in a request's journey does it act? Follow one malicious request from a botnet to your database and the trade-offs become obvious, along with the setup that gets you the best of both worlds.

The journey of one malicious request

A bot fires a password guess at your site. Before it can do harm, it has to travel: first to whatever stands in front of your website, then to your server, where the web server accepts the connection, PHP boots WordPress, and WordPress loads its plugins, and only then does a security plugin get its turn. Each stage costs you something. The whole argument about plugins versus the edge is really about one question: how far down that road do you let the attacker walk before turning them away?

What a security plugin can and cannot do

A plugin lives inside WordPress, and that position cuts both ways. It sees things no outside service can see: your files, your database, your user accounts, your plugin versions. That makes it genuinely good at inside jobs, such as scanning for malware, detecting changed files, flagging outdated plugins, and enforcing login policies.

The same position is its weakness against traffic. By the time a plugin evaluates a request, your server has already paid for it: the connection was accepted, PHP booted, and often the database answered. The attempt gets blocked, and the bill was paid anyway. Multiply that by an automated flood and blocking traffic becomes the most expensive place to do it. The plugin also defends the very machine it runs on, so under a flood it drowns together with the site.

What the edge can and cannot do

An edge service like Cloudflare stands in front of your website, on infrastructure that is not yours. Attack traffic is evaluated there, against firewall rules, rate limits, and bot checks, and what gets blocked simply never arrives. Your server does zero work for it. Scale is the other half: the network absorbing the flood blocks around 230 billion cyber threats a day, and its DDoS protection is unmetered even on the free plan.

What the edge cannot do is look inside WordPress. It cannot scan your files for malware, notice a backdoor a compromised plugin installed, or tell you that a plugin needs updating. It filters the road, and it does not inspect the house.

So what runs where? A sensible division of labor

Edge: everything traffic-shaped. Brute-force and DDoS floods, bot filtering, rate limiting on wp-login.php, blocking xmlrpc.php, spam pressure on forms. Our guides cover each: login brute force, xmlrpc, and comment spam.
Inside WordPress: everything state-shaped. Malware scanning, file integrity, update discipline, least-privilege user accounts. One lightweight plugin, or your host's tooling, covers this.
Drop the overlap. With the edge in place, plugin firewalls, login limiters, and CAPTCHA features do work that was already done one step earlier, and every plugin you remove is less code to keep updated.

How do I see the difference in practice?

Put the edge layers in place and open Cloudflare's Security → Events after a day. The blocked and challenged requests listed there are the attacks your plugin used to meet in person; your server no longer knows they happened. Owners usually notice it in small ways first: the login-alert emails stop, the spam queue empties, and the server feels lighter at the same traffic.

Want the full division of labor, mapped for you?

The ebook Cloudflare for Website Owners builds this layered setup from scratch: 22 chapters across the WAF, rate limiting, bot management, and caching, with a complete WordPress case study that puts every rule in place, with real dashboard screenshots. See the WordPress edition of the pitch or the full overview.

Sources: Cloudflare 2026 Threat Report (~230 billion daily blocked threats). Figures rounded. Cloudflare is a trademark of Cloudflare, Inc.; this guide is by 8grams and is not affiliated with Cloudflare, Inc.