Every article in this series has secretly been about security. The Frankenstein theme full of code nobody audits.
The page builder whose grip determines how fast you could respond to a crisis. The plugin diet that shrinks your attack surface with every removal. The maintainer count that predicts which of your update channels goes dark or changes hands. The supply chain those channels form. It was all one subject wearing different clothes, and this final article says the quiet part out loud.
Security is a posture, a set of habits you keep every day, and a product can only ever be one piece of it. That difference explains why so many compromised sites had a security plugin installed and dutifully green. Too many site owners trust that checkmark, because somebody sold it to them as the whole answer and they paid for it in good faith.
Can a security plugin make WordPress secure by itself?
The fantasy goes like this: install the right plugin, see the green checkmark, and security is handled, the way installing a contact form handles contact. It’s a comforting model, and the security industry happily sells to it, because products are billable and postures aren’t. (See also PHP2Shell, the 22-year-old PHP flaw AI cracked in two days)
A security product is a component. It scans, it filters, it blocks known-bad patterns, and good ones do this well. What no product can do is make the decisions that determine your actual exposure: what you install, what you keep, who you trust upstream, whether anyone would notice a file that doesn’t belong, whether the backup restores.
A product is one component; the decisions that set your exposure are made continuously by a person.
Those are choices, made continuously, by a person. The plugin is a smoke detector. The posture isn’t storing gasoline in the living room.
Security is a posture, a set of habits you keep every day, and a product can only ever be one piece of it.
My own incident, the one that started this series, makes the point cleanly. A scanner caught the payload the instant it landed, and I’m glad it did. But the scanner was only the last line. The defense was everything around it: knowing what belonged on the server so the alert meant something, having the incident traced instead of just deleted, and having already decided, years earlier, that something automated would always be watching. The product performed for thirty seconds. The posture had been performing for years.
What does a security posture look like?
Posture sounds abstract, so let me make it concrete with the practices that run on my own sites. None of this reveals anything an attacker can use, because none of it is secret. It’s just discipline, visible in outline and boring in execution. That’s what real security looks like.
Something watches, always. Automated scanning examines what lands on the server, because the attack that matters arrives dressed as something that belongs, and humans don’t catch that class of problem. Layers matter here: no single scanner sees everything, and the compromise my host caught might have slipped a different net. On my own sites, a major security plugin downloads new signatures every day, and my host quarantines anything executable that lands on the site before it can run.
Events leave records. Logins, changes, administrative actions: logged, timestamped, reviewable. When something odd happens, the difference between an afternoon and a catastrophe is whether you can reconstruct what occurred. An audit trail is the cheapest forensics you’ll ever buy, and you buy it before you need it or not at all. Late in 2024, a plugin on my site started alerting on break-in attempts, and I watched them in real time. They came over VPN from Russia, China and India with different usernames. It was obviously one person, because the attempts were seconds apart. They all failed. I’ve since moved the site behind Cloudflare.
When a small business site gets compromised, the first people hurt are its visitors: the prospect redirected to a scam page, the customer who types a card number into a form an attacker planted. They trusted the name on the site. An owner with no logs and no scanning finds out when one of those visitors complains, and by then that visitor’s trust is already spent.
The uninvited get less surface. Traffic from places I’ll never do business with doesn’t reach my sites. That removes a startling fraction of the automated hostility before any other defense has to think about it. Reducing who can even knock is arithmetic. I moved all 20 of my domains to Cloudflare after people tried to hack me, and the transfer took under ten minutes. Everything comes through Cloudflare’s front door now, and there’s no back door anymore. My pages also score 100 on Google PageSpeed every time, because Cloudflare caches every page.
Access is boring. Strong unique passwords, two-factor authentication, no shared accounts, admin access for the people who administer and nobody else. Nothing on this list is clever. Attackers don’t need you to be careless, but they profit a lot when you are.
I had Claude help me write my Cloudflare security rules. They’re complicated, and doing them alone would have taken me weeks, and I’d have gotten them wrong. Claude got them wrong too at first, but we fixed them. Cloudflare’s own streaming video product is expensive, so I don’t use it. I store almost 100GB of video there anyway, and it costs me well under a dollar a month.
Recovery is rehearsed. Backups exist, live off the server, and have been restored as a test. An untested backup is only a hope. This is the one practice that answers every failure mode at once, including the ones nobody has invented yet. And the stack stays small and known. Which returns to everything this series has argued: fewer components, chosen deliberately, from living projects, with exits priced in advance. A site you fully understand is a site where anomalies are visible. Complexity is where compromises hide.
That goes for code I write myself. I wrote an AEO plugin with Claude’s help, and then I had to run a security audit on it. It found a couple of security problems. Then I ran a performance audit, and that found a big performance problem. Now it’s really cool, and I’m having a blast. My site runs over 100 plugins now, and nearly all of them are ones I built.
| Habit | What it looks like | Why it matters |
|---|---|---|
| Something watches, always | Automated scanning in layers, daily signatures, host quarantine | Humans don’t catch the attack dressed as something that belongs |
| Events leave records | Logins, changes and admin actions logged and timestamped | You can reconstruct what happened when something odd occurs |
| The uninvited get less surface | Block traffic from places you’ll never do business with | Removes much automated hostility before other defenses act |
| Access is boring | Strong unique passwords, two-factor, no shared accounts, limited admins | Attackers profit a lot when you are careless |
| Recovery is rehearsed | Off-server backups that have been restored as a test | Answers every failure mode, even ones not yet invented |
| The stack stays small and known | Fewer components, chosen deliberately, from living projects | Anomalies stay visible; complexity is where compromises hide |
| Your own code gets audited | Security and performance audits on plugins you build | Audits found security problems and a big performance problem |
What is the security posture test?
If you want to assess your own site, skip the plugin checklist and answer five questions, and don’t give yourself the benefit of the doubt on any of them.
Could you list everything running on your site right now, and would you notice an addition?
What would tell you something landed on your server at three in the morning? If your site started serving spam under your name today, how would you find out, and how long would it take? When did you last restore a backup, not make one, restore one? And who maintains each piece of software you depend on, and when did you last check?
Every one of those questions is about awareness and habit. You can’t answer a single one by purchasing anything. That’s the argument in miniature. Owners who answer these with the name of a product are the ones I worry about. If you can’t answer the backup question with a date, nobody knows whether your site would come back after an attack, and that includes you.
My take
Security comes from habits, and no plugin installs those. Keep access tight, keep the stack small and known, and rehearse recovery. If you can’t answer the backup question with a date, you don’t know whether your site would come back after an attack. Neither does anyone else. Run the five-question test without giving yourself the benefit of the doubt. If your answers are product names, I’d worry.
The beacon, kept lit
This series opened with a frame I want to close on. Your website is your beacon: the place your credibility lives, serving the handful of visitors who matter enormously. Everything in these seven articles, the theme surgery, the builder divorce, the plugin diet, the maintainer arithmetic, the supply chain vigilance, and finally this posture, is in service of that one asset, the trust those visitors place in you.
The work is unglamorous and continuous, and nobody selling you a plugin will say so. Security never ends.
You practice it the way you lock a door every night, without ceremony. Practice it yourself with the questions above, or hand the practice to someone who has done it for decades. Either way, keep the beacon lit. The people it was built for are watching it to decide about you.
Security doesn’t end, it’s simply practiced, the way you lock a door every night without ceremony.Share on X
Frequently Asked Questions
- Multifactor Authentication, Cybersecurity and Infrastructure Security Agency (CISA)
- Securing WordPress, University of British Columbia, Office of the CIO
