WordPress Security Myths: What Actually Matters

This is the most common reason site owners don't bother with security — and it's based on a misunderstanding of how WordPress attacks work.

Most WordPress attacks are not targeted. Attackers don't look at your site and decide to hack it specifically. They run automated tools that scan millions of sites simultaneously, looking for any site with a known vulnerability. It doesn't matter if you have 100 visitors a month or 100,000. If you're running an outdated plugin with a published CVE, the scanner will find you.

Small sites are actually more attractive in some ways. They're more likely to be running outdated software (less active management), less likely to have security monitoring, and more likely to be on shared hosting where a compromised site can spread to neighbouring accounts.

The question isn't whether you're valuable enough to be worth targeting. The question is whether you're easy enough to be caught in the automated net.

Your host is responsible for the security of the server your site runs on. You are responsible for the security of the WordPress installation running on that server.

This is a genuine and important distinction. Your host will patch the operating system, maintain the PHP version, and (usually) run server-level malware scans. They will not update your plugins, manage your WordPress configuration, or prevent you from installing software with known vulnerabilities.

Think of it like renting an office. The building management takes care of the locks on the front door and the fire safety systems. But it's your job to keep your office locked, not leave sensitive documents on your desk, and not prop the fire door open.

Most WordPress hacks happen at the application layer — through vulnerable plugins, weak passwords, or misconfigured settings. All of that is entirely outside what your host can protect.

Security plugins like Wordfence, iThemes Security, and Sucuri are useful tools, but they're not a complete solution, and many site owners treat them as a set-and-forget shield.

The core problem: security plugins do some things well (firewall rules, login attempt blocking, file change detection) and other things poorly or not at all (checking your headers, scanning installed plugins against external CVE databases, identifying server-level misconfigurations).

More importantly, a security plugin that's out of date is itself a vulnerability. There are documented cases of widely-used security plugins having their own CVEs. The irony of getting hacked through your security plugin is real.

Security plugins are one layer of protection, not a complete solution. The fundamentals still apply: keep everything updated, check your configuration, and scan regularly with a tool that checks what your security plugin doesn't.

HTTPS means the connection between your visitor's browser and your server is encrypted. That's it.

It doesn't mean your site hasn't been hacked. It doesn't mean your plugins are up to date. It doesn't mean your admin login is protected. It doesn't mean your files are safe from unauthorised access. HTTPS protects data in transit; it says nothing about the security of your WordPress installation.

The padlock icon in your browser's address bar tells you that the connection is encrypted. It says nothing at all about whether the site on the other end of that encrypted connection is clean.

HTTPS is necessary but nowhere near sufficient. Every WordPress site should have it — but having it doesn't let you skip any of the other security steps.

The things that genuinely reduce your risk aren't exotic or expensive. They're the same unglamorous fundamentals that security professionals have been recommending for years:

Keep your plugins, themes, and WordPress core updated. The majority of successful WordPress attacks exploit vulnerabilities that have already been patched — the update just wasn't applied.

Remove what you don't use. Every inactive plugin and theme is a potential attack surface. If you're not using it, delete it.

Use a strong, unique password for your WordPress admin account. A password manager makes this easy.

Close the common misconfigurations: hide your PHP and WordPress versions from the public, disable directory listing, block XML-RPC if you don't need it.

Scan regularly. Weekly automated scanning catches new plugin vulnerabilities as they're disclosed, so you can update before attackers exploit them.

None of this is complicated. Most of it takes less than an hour to set up and then runs in the background with minimal ongoing effort.