How To Do WordPress & Security

Security in the context of WordPress is a topic I see being misrepresented often. Misrepresented in the way that “just install our solution” is presented as the golden ticket. It’s not.

Let’s get this out of the way first: installing a “WordPress security plugin” doesn’t make your site secure.

Most of the WordPress solutions out there create a false sense of safety while adding layers of unnecessary bloat. They scan endlessly, pretend failed login attempts are an indication your site is secure, they load scripts you don’t need, and try to “hide” your login URL like it’s 2011.

Obscurity is not security.

If you’ve been relying on a single plugin to “handle” security for you, it’s time to rethink the approach entirely.

Security Is Not a Feature

Security, just like WordPress performance, is not something you can bolt on after the fact. It’s a system of layers, each with its own holes, like the famous Swiss cheese model used in aviation and medicine.

Each layer has weaknesses, but when you stack them properly, the holes no longer align. That’s what true security looks like.

So, instead of one bloated “security” plugin that tries to do everything poorly, you want multiple layers, each doing one thing well.

Layer 1: Hosting

The best security decision you can make for WordPress starts before you even install it: choose a good host.

A solid WordPress host (like Servebolt, Kinsta, WP Engine, or WP.Cloud) already handles the big threats like intrusion detection, DDoS protection, firewalls, and always choosing to have the latest and greatest of defences in place.

A well-architected hosting platform isolates sites, restricts file access, enforces strong permissions, and updates PHP as soon as security patches are released. That’s far more effective than anything a plugin can retrofit later.

If you’re rolling your own setup on AWS, Linode, or a VPS, the burden shifts to you.

That means hardening your stack:

• Keep your OS and PHP versions patched.
• Use firewalls at the server and network level.
• Disable unnecessary services.
• Lock down SSH and database access.

In short: make sure everything that should be secure is secure before you even get to WordPress. And coming from someone who’s maintained his own servers for over a decade, I say this to you: that’s not worth it for me anymore. I much rather have that in the hands of specialists: DevOps.

Layer 1 covered, let’s look at the application level security; Level 2.

Layer 2: Application-Level Security

Once WordPress itself is running, focus on securing access to it, not hiding it.

• First things first: keep WordPress core, plugins, and themes up to date. Always.
• Use Two-Factor Authentication (2FA): The same one used on WordPress.org, the Two-Factor plugin, is lightweight and reliable.
• Enforce Strong Passwords: No one should be using Admin123. Use a password manager and enforce long, random passwords for all users. This is where the many WordPress security plugins have their place.
• Limit User Roles: Give people only the permissions they need. Your copywriter doesn’t need to be an Administrator.
• Disable XML-RPC if you don’t use it.
• Obviously have the site running with HTTPS

If you absolutely must use a general-purpose security plugin, go with Solid Security (the modern evolution of iThemes Security). It focuses on the fundamentals, hardening common vulnerabilities, enforcing 2FA, and monitoring logins.

Why won’t hiding the login URL do it? Well, first of all, it’s simply the wrong focus. You want to focus on avoiding and blocking that traffic, and the traffic that hits your application (WAF), your WordPress site, needs to have it be impossible to login (2FA).

Why I Don’t Recommend Wordfence

Let’s talk about the elephant in the room.

I don’t recommend Wordfence.

Not because it’s inherently malicious or useless, but because it simply isn’t good enough for what it promises to do. It’s heavy, it slows down your site, and it tries to do too many things from inside the same environment it’s supposed to be protecting. That’s like locking the door from the inside while the burglar is already in the room.

When I worked at a hosting company, I saw this play out constantly. A site would get hacked, and guess what was installed almost every single time? Wordfence.

It didn’t stop the intrusion. It didn’t alert in time. It just sat there, scanning logs after the fact. Now, I’m not saying it caused the hack, but I am saying I’ve seen it be part of the mix too many times to consider a serious solution.

So yeah, that’s not protection that’s postmortem analysis. And you don’t need that living inside your WordPress environment, eating CPU cycles and pretending it’s your firewall.

Layer 3: A Real Web Application Firewall (WAF)

A WAF is one of the most effective defenses against external attacks, especially bots and zero-day exploits.

But don’t confuse plugin firewalls with actual WAFs. The real protection happens before traffic ever reaches your WordPress install.

Use a service like Cloudflare or Sucuri. Both operate at the edge, filtering malicious traffic and blocking known exploit patterns long before they hit your server.

Cloudflare’s free plan already offers basic protection, but the Pro plan adds a proper managed ruleset and bot mitigation that’s worth every cent for any site that matters.

And just so I’m super clear, anything and everything you can do at the edge, meaning that layer that sits in front of your WordPress site and server, you should do at the edge. Caching (in a performance optimized fashion, of course) and Security are two great examples of this.

Layer 4: Hardening WordPress

Now we’re down to the WordPress layer itself. This is where you lock down what’s left, file permissions, authentication, and runtime behavior.

And this is where Fortress changes the game.

Fortress isn’t another plugin pretending to be a security suite. It’s a complete application security framework for WordPress that brings enterprise-grade, Laravel-style security controls into your site, without you needing a dedicated DevSecOps team. I know, I know, big words. But it’s doing exactly that.

You see, instead of patching symptoms, Fortress actually rewires how WordPress handles authentication, authorization, and sensitive operations. It takes the core principles of secure software design, least privilege, explicit trust boundaries, and event auditing, and makes them native to WordPress.

Here’s what that looks like in practice:

• Granular Role & Capability Control: Define precisely what each user, plugin, or API call can do. No more “admin or nothing” security.
• Request-Level Authorization: Every action in your application can be vetted through Fortress’ middleware-like authorization rules, the same model used in modern frameworks like Laravel.
• Powerful Login Hardening: Fortress replaces WordPress’ default authentication layer with a hardened, extendable system that blocks brute-force attempts, mitigates credential stuffing, and integrates directly with 2FA.
• Immutable Audit Trail: Every sensitive action, from login attempts to plugin activations, is logged with full context. No more wondering “what happened?” after an incident.
• Code-Level Security Hooks: Developers can add explicit security policies right in their code, giving total control over who can execute what and when.

And crucially, Fortress is built for speed and transparency. It doesn’t inject front-end scripts, spam you with meaningless alerts, or consume server resources with endless scans. It just makes your WordPress application harder to exploit, by design.

It’s the first tool that finally treats WordPress security like a first-class application concern, not an afterthought you fix with a plugin checkbox.

Now, you may think by now that this post is sponsored by Calvin Alkin, the creator of Fortress, but that’s not the case. I’m simply listing what I see as the best solutions out there for what the need to do. And Fortress is just that. It comes at a costs, but I promise you, the cost of your sites hacked is much much higher.

What About Patchstack?

Even with a secure host and a WAF in front of your site, there’s one more essential piece that often gets overlooked: knowing what’s vulnerable before it’s exploited. That’s where Patchstack comes in.

Patchstack continuously monitors WordPress core, plugins, and themes for known vulnerabilities, and does it at a depth few others can match. Its team tracks CVEs, plugin repository updates, and even zero-day disclosures across the ecosystem.

Some security plugins use that data for their scans, for instance. This is where security stops being reactive. Instead of waiting for an exploit to happen, Patchstack’s data lets you:

• Identify vulnerable components in your site immediately.
• Understand which vulnerabilities are actively being exploited in the wild.
• Patch or remove affected plugins before attackers start scanning for them.

It’s another slice of the Swiss cheese model, real-time intelligence that fills the gaps between static code and your edge defenses.

While Fortress secures how your application behaves, and Cloudflare keeps bad traffic out, Patchstack makes sure you’re not running code that’s already compromised. Together, they form a feedback loop of prevention, not cleanup.

How Security and Performance Are Two Sides of the Same Coin

One of the biggest misconceptions in WordPress is that performance and security are competing priorities, that securing your site means slowing it down. The reality is that a properly secured site almost always performs better.

When you eliminate insecure configurations, you also remove a lot of unnecessary processing, database lookups, and unpredictable server behavior.

Take these examples:

• Strong authentication reduces brute-force load. Every failed login attempt triggers database queries, session writes, and PHP execution. By enforcing 2FA and using a real WAF, those requests get filtered out long before they reach WordPress. That’s fewer requests, fewer PHP processes, and faster response times.
• Minimal plugins mean a smaller attack surface and faster load times. Every plugin you install adds potential vulnerabilities and more PHP to execute. When you stop depending on bloated “security” plugins and move toward infrastructure-level protection, you’re removing both attack vectors and performance drag.
• Proper caching and CDN layers double as protection. Tools like Cloudflare or NitroPack don’t just accelerate delivery, they also absorb bot traffic and mitigate DDoS attempts. You’re not just caching content; you’re filtering garbage.
• Fewer background scans, more predictable CPU cycles. Many security plugins constantly scan your filesystem and database, consuming I/O and CPU resources. Moving that responsibility to your host or edge firewall instantly makes your site more stable and responsive.

In other words, every performance optimization that reduces server work also tightens your security posture, and every security improvement that stops bad requests frees up resources for legitimate visitors.

Good security and good performance both come from the same mindset: a lean, layered architecture where everything unnecessary is stripped away.

You can learn more about how to make WordPress faster, the right way in my course.

Understanding How WordPress Sites Actually Get Hacked

It’s worth understanding how WordPress sites are compromised in the real world, because it’s often not how you think. Thomas Raef blogged about how cookie hijacking is an overlooked attack vector in WordPress compromises. One of the biggest, actually.

Over the past month, actually September, we removed malware from 111,354 websites.

21,752 had 2 security plugins installed. Both installed before the infection. Neither stopped it or detected the infection. 1,377 had Solid Security on them also. None used the passkeys. When the hackers breached the site, the one plugin they deactivated was Solid Security. 1,112 sites had deactivated Solid Security. None deactivated the other 2FA testament to which plugin they fear the most.

Thomas Raef

In many cases, attackers don’t brute-force your password or exploit an outdated plugin. Instead, they intercept or steal valid session cookies from logged-in users, allowing them to impersonate administrators without ever touching the login screen.

That’s why securing your WordPress session, using HTTPS everywhere, short session expirations, and 2FA, matters so much.

It also underscores why “login lockdown” plugins don’t protect you from the modern threat landscape. Most attacks bypass the login form entirely.

The Multi-Layer Mindset

Security is not a product you install. It’s a mindset, a layered architecture of responsibility.

A good host covers the infrastructure.

A WAF covers the edge.

2FA and strong passwords protect user accounts.

A lean, developer-minded framework like Fortress handles internal monitoring and hardening.

Everything else is noise.

So, if you want a secure WordPress version, don’t start by searching for “best WordPress security plugin.”

Start by understanding where the holes are, and then stack the slices properly.

Because real security isn’t about hiding your login page. It’s about making sure that when one layer fails, the next one catches what gets through.

That’s how you build a truly secure WordPress version.