Site Hardening · Part 8
Every plugin is someone else’s code
A typical small-business WordPress site runs twenty to forty plugins. Each one is software written by someone you have never met, running with full access to your site, updated on their schedule, and abandoned whenever they lose interest.
Most are fine. The problem is arithmetic. Every plugin adds code that can have a flaw, an owner who can sell it, and an update you have to track. Forty plugins is forty of each.
The site you are reading this on runs none.
What zero plugins looks like
From the case file. After the compromise, provae.com was rebuilt with no active plugins at all. The jobs plugins usually do are done by a small amount of code the owner wrote and controls:
- Search engine settings — titles, descriptions, canonical addresses and structured data — come from a single must-use file that reads a small settings file for each page. The settings files are made by PageMaker, a small tool he built himself, which runs on his own computer; the finished files go up over SFTP. No SEO plugin.
- Buttons and calls to action come from one short function in the theme, so the wording and links live in one place and are never pasted into pages.
- Security at the door is handled mostly at the edge, as Part 3 describes. Inside the site, two more short must-use files of his own do what security plugins usually do: one locks out repeated login attempts, the other closes WordPress’s REST API to outsiders.
That isn’t a recommendation that everyone write their own. It is proof of how little a typical brochure or service site actually needs.
The plugins you can’t see
The plugins page isn’t the whole picture. WordPress also loads must-use plugins — files in a separate folder that run automatically, can’t be deactivated from the dashboard, and don’t appear on the normal plugins list — and drop-ins, special files that replace parts of WordPress itself, such as how it talks to its database.
From the case file. That is where the intruders hid the machinery. A must-use loader was quietly repointed from a legitimate file to their own. A database drop-in let the hidden WordPress install run from a single file instead of a database. And they edited a plugin’s own uninstall routine so that removing it would never remove their drop-in. None of it showed on the plugins page.
Your hosting company may add must-use files of its own, too. In this case one of them — the host’s installer helper — was flagged as suspicious early in the investigation and turned out to be completely genuine. So know which must-use files you put there, which your host did, and treat anything else as a question.
Counted honestly, this site’s must-use folder holds four files: the owner’s three — the search settings loader, the login lockout and the REST lockdown — and the one his host installs. Four files, each one explainable. That is the whole point of keeping the list short.
A plugin you stop using isn’t gone
Deactivating a plugin stops it running. Its files stay on the server, reachable, unexamined — and anything it connected to may keep trying to talk to your site.
From the case file. A security plugin was installed during the fighting and later deactivated. Its outside service was still contacting the site six months afterwards. Its heavy traffic during the fight had also been misread at first as a backdoor — more than two hundred unusual requests from eighteen addresses, which turned out to be the plugin’s own scanner, switched on less than a minute earlier.
So: delete what you don’t use, don’t just deactivate it. Disconnect it at the service’s end too. And write down what you install, when, and why, so its activity in a log doesn’t turn into a false alarm later.
How to get down to a few
Most sites can’t go to zero overnight, and don’t need to. Go through the list one plugin at a time:
- Is it doing anything? Many sites carry plugins installed for a job finished years ago. Delete them.
- Does WordPress already do it? Sitemaps, image sizes, basic redirects and a lot of formatting are built in now.
- Is it a few lines of code? Tracking snippets, small tweaks, simple shortcodes — these belong in your own theme or a must-use file you control.
- Can the edge do it? Login protection, bot blocking and caching are often better done in front of the site than inside it.
- Is it essential and well kept? Then keep it — from a maintained source, actually updated, and on your written list.
The honest trade
Fewer plugins is not free. Code you write is code you maintain. There is no update button that fixes it for you, and if you stop paying attention, it ages like any abandoned plugin.
What you gain is knowledge. Every file on the site is one you can explain, and a new one is immediately suspicious. In this case, two file-manager plugins were added to one site a minute apart and nobody noticed, because on a busy plugins page, two more looks like nothing. On a site with none, one is an alarm.
Hidden plugins and drop-ins don’t appear anywhere in the dashboard. A recovery review checks the folders the plugins page never shows.
Start a Recovery ReviewPaid assessment · scope agreed up front
Back: Locking Down .htaccess Without Breaking Your Site
Next: Automatic Updates: Why We Turned Them Off, and What That Costs
Hub: Site Hardening Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.