Ten years of brute-force attempts, fake crawlers and log files larger than the database. At some point the choice was simple: keep tuning someone else’s WordPress security plugin, or write the layer I actually wanted.
What I wanted
Filtering before WordPress boots. A log a human can read. No upsell banner in the admin. No cloud dependency for a decision that can be made on the server. Those four requirements ruled out most of the market for me.
What I refused
Feature creep. A security plugin that also does backups, SEO and popups is a plugin with three more ways to break. I kept the scope narrow: requests, bots, login, logs.
Five lessons
- Early filtering beats clever filtering. A request refused before PHP costs almost nothing.
- Logs decide whether you can tune the thing at 3 a.m.
- False positives are the real enemy: one blocked checkout costs more than a hundred bots.
- Every feature needs an off switch and an allowlist.
- Maintenance is the product. A security tool that stops updating becomes a liability.
What it costs
Time. Updates, compatibility with caching and CDNs, new bot patterns, support. A custom plugin is not free because you wrote it; it is free until the first WordPress release breaks it.
When to use an existing plugin
If you need one site protected and no unusual requirements, take a maintained plugin with a clear changelog. Build your own when the requirement is specific, you can maintain it, and you enjoy the problem. Otherwise you are buying a second job.
Before you write your own
- You can maintain it for years, not months.
- You need behaviour no maintained plugin offers.
- You can test it under load and read the logs.
- You have a rollback plan for a broken update.
- You accept the support burden.
- You are not doing it to save money.
Three questions I get
Is a custom plugin safer? Only while it is maintained. An abandoned custom plugin is worse than a supported one.
Can I use it on client sites? Only with a support plan and a documented update process.
How often does it change? As often as WordPress and the bot traffic do. Security code is never finished.
I built mine because I wanted that job. That is the only honest reason to start.
How I test a release
Every release runs the same list: a clean WordPress install, a cached page, a checkout, a login with a wrong password, a known bot user agent and a real browser. If a rule blocks any of the first four, it does not ship. The list lives in the repository, not in my head.
What is out of scope
Backups, malware cleanup, SEO and site speed. A security plugin that does everything becomes the thing that breaks everything. I keep the boundary and tell clients where to get the rest.
What I would do differently
Start with logs, not rules. The first version blocked too much and the logs were unreadable. A week of read-only observation would have saved two releases.
When a WordPress security plugin is worth writing
A plugin makes sense when the gap is structural: requests that must be dropped before PHP runs, logs you can read at 3 a.m., rules that survive an update. For most sites a maintained plugin is cheaper. The WordPress plugin directory is the place to start before writing your own WordPress security plugin.
Every rule you add is a rule someone has to debug at 3 a.m.
Related reading: The best WordPress security plugin: what actually matters and BotBlocker Security: a WAF that starts before WordPress.