The standard WordPress security advice is to install a security plugin and cross your fingers, which is a band-aid on a broken leg. In 14 years of development I have seen sites running five different hardening plugins get gutted by a plain SQL injection, because the architecture underneath was a mess.
Core itself holds up well. Patchstack’s 2024 report puts nearly 97% of vulnerabilities in third-party plugins and themes, with the core software accounting for 0.2% of issues. So if you are worried about the site getting broken into, the thing to audit is your stack, not the CMS.
Why most WordPress security advice fails
Most developers treat security as a checkbox. Run a scan, see green lights, ship it. Real WordPress security is about shrinking the attack surface instead. Every helper plugin you add for one minor feature is another window opened in the house, so the first step to a secure site is deleting the code you do not need rather than adding more of it.
I wrote before about how security is more than just running a scan. It means thinking like an architect: watching your transients, clearing out old database tables, keeping user roles tight. A contractor who only needs to edit posts does not get an Administrator account.
How I harden a site
If you manage your own server, the basics are not enough. One of the mistakes I keep finding is the built-in file editor left switched on. Anyone who gets admin access can rewrite functions.php from the dashboard, and at that point it is over. One line in wp-config.php takes that risk away.
Security headers are the other easy win. They stop basic XSS and frame injection before the request reaches any WordPress logic. A PHP filter is a clean way to set them:
<?php
/**
* Hardening WordPress security with custom HTTP headers.
*/
function bbioon_add_security_headers( $headers ) {
$headers['X-Content-Type-Options'] = 'nosniff';
$headers['X-Frame-Options'] = 'SAMEORIGIN';
$headers['X-XSS-Protection'] = '1; mode=block';
$headers['Referrer-Policy'] = 'strict-origin-when-cross-origin';
return $headers;
}
add_filter( 'wp_headers', 'bbioon_add_security_headers' );
When a managed platform is the answer
Clients who have no interest in playing sysadmin usually get pointed at a platform like WordPress.com, where SSL, the WAF and DDoS mitigation are handled at the edge and there is much less room for human error. If you are building something custom instead, watch for the mistakes that lead to failing security standards while you are still in the build phase.
The maintenance checklist
- Automate minor updates with WP-CLI.
- Turn on 2FA for every admin account, without exceptions.
- Keep an activity log so you know who changed what. A plugin that updates itself unexpectedly is worth investigating the same day.
- Take off-site backups in real time. That is what you fall back on when everything else has failed.
If WordPress security is eating your dev hours, hand it to me. I have been wrestling with WordPress since the 4.x days.
Where to put the effort
WordPress is a secure engine. The insecurity myth sticks around because people treat it like a toy instead of an enterprise application. Follow the official security guidelines, keep the plugin list short, and you are already safer than 90% of the web. Skip the hunt for a magic security plugin and put the hours into clean, well-maintained code.
