Our take: most security plugins add risk instead of removing it
Why a security plugin on a website is more code on the thing being attacked, what it can and cannot do, and where protection actually comes from.
The short answer
A security plugin is installed on a website to protect it, and it runs inside that website with the same privileges as everything else on it. That is the problem. A flaw in the plugin is a flaw in the site, and security plugins have a long public record of their own vulnerabilities, some serious, made worse by their installation on millions of sites, which makes them exactly the kind of target attackers invest in. A compromise of the site can disable the plugin that was meant to detect it. And the useful things such plugins do, limiting login attempts, filtering bad traffic, setting headers, scanning for changes, alerting, all belong outside the site, in the network layer in front, on the platform and in the pipeline, where they cannot be switched off by the thing they protect and do not add code to it. Our take is that a site with the fewest moving parts, no server code running per visit, and protections applied from outside is safer than any site with a security plugin, and that adding a security plugin to a fragile site treats the symptom while adding to the disease.
Inside versus outside
| Protection | Done by a plugin inside the site | Done from outside the site |
|---|---|---|
| Login rate limiting | Runs after the request reaches the site; can be bypassed or disabled | At the network layer, before the request arrives |
| Bad bot and attack filtering | Pattern matching in site code, consuming server resources | Managed rules at the edge, absorbing floods |
| Security headers | Added by the plugin, lost if it breaks | Set at the platform or the edge, always present |
| Malware scanning | Signature scanning by code that can itself be compromised | Version control makes every unexpected change visible; static files cannot host server malware |
| Second factor for admin | Plugin-implemented, with its own flaws | Platform identity, or no public admin at all |
| Update reminders | Notifications inside the admin | Dependency scanning and automated updates in the pipeline |
| Alerts | From inside the site, silent when the site is down | External monitoring that notices when the site is down |
| Backups | Stored on the same server by default | Platform snapshots and the repository, stored elsewhere |
What we do instead
- Build static where the site allows it, so no server code runs per visit and there is no public admin.
- Put a network layer in front for filtering, rate limits, bot management and a firewall where warranted.
- Set headers and policy at the edge or the platform, versioned in the repository.
- Scan in the pipeline: dependencies, secrets, static analysis, on every change.
- Monitor from outside: uptime, certificates, DNS, content changes, with alerts to people.
- Keep everything in version control, so any unexpected change to the site is visible as a diff.
- On traditional platforms we inherit: minimise plugins, update weekly, apply the outside protections, and remove the security plugin once they are in place.
Where this leaves traditional platforms
A site that must run on a plugin-based platform can still be run responsibly: a short plugin list, weekly updates, a network layer in front, headers at the edge, second factors on accounts, external monitoring and off-server backups. In that arrangement the security plugin adds little, and its own vulnerability history counts against it. What a security plugin cannot do is make a site with forty plugins and no maintenance safe, however green its dashboard.
What this means for you
A security plugin is more privileged code on the site it protects, with its own vulnerabilities and the ability to be disabled by the compromise it should catch. Apply the same protections from outside: network layer, platform, pipeline, external monitoring, version control. Build static where you can so there is nothing for a plugin to protect. And treat a green security dashboard on a site with dozens of plugins as reassurance, not protection.
Frequently asked questions
Are you saying security plugins do nothing?
They do things: they block some login attempts, scan files for known malware signatures, set some headers, and send alerts. The problem is where they do it. They run inside the site, on the same server, with the same access as everything else, so they can be disabled by the compromise they are meant to detect, and they are themselves code that has flaws. The same protections applied from outside the site, at the network layer, on the platform, in the pipeline, work without those weaknesses.
Our site is on a traditional platform. Should we remove the security plugin?
Not without replacing what it does from outside first: a network layer in front for rate limits, bot filtering and a firewall; headers set at the platform or the edge; a second factor on admin accounts; a pipeline or at least a schedule for updates; monitoring from an external service. Once those are in place, the plugin is doing little that is not done better elsewhere, and every plugin removed is attack surface removed. Keep the plugin count minimal, and keep every plugin updated the week its update appears.
What is the alternative for a business site?
An architecture that does not need a plugin: a static site with no server code running per visit and no public admin, served through a network layer that handles filtering and rate limits, built by a pipeline that scans dependencies and secrets, with headers set at the edge and monitoring from outside. There is nothing for a security plugin to protect, and nothing for it to break.