Each layer has weaknesses, but when you stack them properly, the holes no longer align. That\u2019s what true security looks like. <\/p>\n\n\n\n
If you’d like to know more about this Swiss chees model, I did a podcast with Calvin Alkan diving specifically into the layers<\/a>. Lots to learn there.<\/p>\n<\/div>\n\n\n\n So, instead of one bloated \u201csecurity\u201d plugin that tries to do everything poorly, you want multiple layers, each doing one thing well.<\/p>\n\n\n\n The best security decision you can make for WordPress starts before you even install it: choose a good host.<\/strong><\/p>\n\n\n\n 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. <\/p>\n\n\n\n A well-architected hosting platform isolates sites, restricts file access, enforces strong permissions, and updates PHP as soon as security patches are released. That\u2019s far more effective than anything a plugin can retrofit later.<\/p>\n\n\n\n If you\u2019re rolling your own setup on AWS, Linode, or a VPS, the burden shifts to you.<\/p>\n\n\n\n That means hardening your stack:<\/p>\n\n\n\n In short: make sure everything that should<\/em> be secure is<\/em> 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. <\/p>\n\n\n\n Layer 1 covered, let’s look at the application level security; Level 2.<\/p>\n\n\n\n Once WordPress itself is running, focus on securing access to it, not hiding it.<\/p>\n\n\n\n If you absolutely must use a general-purpose security plugin, go with Solid Security<\/strong><\/a> (the modern evolution of iThemes Security). It focuses on the fundamentals, hardening common vulnerabilities, enforcing 2FA, and monitoring logins. <\/p>\n\n\n\n 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). <\/p>\n\n\n\n Let\u2019s talk about the elephant in the room.<\/p>\n\n\n\n I don\u2019t recommend Wordfence<\/strong>.<\/p>\n\n\n\n Not because it\u2019s inherently malicious or useless, but because it simply isn\u2019t good enough for what it promises to do. It\u2019s heavy, it slows down your site, and it tries to do too many things from inside the same environment it\u2019s supposed to be protecting. That\u2019s like locking the door from the inside while the burglar is already in the room.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n It didn\u2019t stop the intrusion. It didn\u2019t 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.<\/p>\n\n\n\n So yeah, that\u2019s not protection that\u2019s postmortem analysis. And you don\u2019t need that living inside your WordPress environment, eating CPU cycles and pretending it\u2019s your firewall.<\/p>\n\n\n\n A WAF is one of the most effective defenses against external attacks, especially bots and zero-day exploits.<\/p>\n\n\n\n But don\u2019t confuse plugin firewalls with actual WAFs. The real protection happens before<\/em> traffic ever reaches your WordPress install.<\/p>\n\n\n\n Use a service like Cloudflare<\/strong> or Sucuri<\/strong>. Both operate at the edge, filtering malicious traffic and blocking known exploit patterns long before they hit your server.<\/p>\n\n\n\n Cloudflare\u2019s free plan already offers basic protection, but the Pro plan adds a proper managed ruleset and bot mitigation that\u2019s worth every cent for any site that matters.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n Now we\u2019re down to the WordPress layer itself. This is where you lock down what\u2019s left, file permissions, authentication, and runtime behavior.<\/p>\n\n\n\n And this is where Fortress<\/strong><\/a> changes the game.<\/p>\n\n\n\n Fortress isn\u2019t another plugin pretending to be a security suite. It\u2019s 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. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n Here\u2019s what that looks like in practice:<\/p>\n\n\n\n And crucially, Fortress is built for speed and transparency. It doesn\u2019t 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.<\/p>\n\n\n\n It\u2019s the first tool that finally treats WordPress security like a first-class application concern, not an afterthought you fix with a plugin checkbox.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n Even with a secure host and a WAF in front of your site, there\u2019s one more essential piece that often gets overlooked: knowing what\u2019s vulnerable before it\u2019s exploited<\/strong>. That\u2019s where Patchstack<\/a> comes in.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019s data lets you:<\/p>\n\n\n\n It\u2019s another slice of the Swiss cheese model, real-time intelligence that fills the gaps between static code and your edge defenses.<\/p>\n\n\n\n While Fortress secures how your application behaves, and Cloudflare keeps bad traffic out, Patchstack makes sure you\u2019re not running code that\u2019s already compromised. Together, they form a feedback loop of prevention, not cleanup.<\/p>\n\n\n\n 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<\/strong>.<\/p>\n\n\n\n When you eliminate insecure configurations, you also remove a lot of unnecessary processing, database lookups, and unpredictable server behavior.<\/p>\n\n\n\n Take these examples:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Good security and good performance both come from the same mindset: a lean, layered architecture where everything unnecessary is stripped away.<\/p>\n\n\n\n You can learn more about how to make WordPress faster<\/a>, the right<\/em> way in my course<\/a>.<\/p>\n\n\n\n![\"Swiss](\"https:\/\/remkusdevries.com\/wp-content\/uploads\/2025\/10\/swiss-cheese-1280x853.png\")
<\/figure>\n\n\n\nLayer 1: Hosting<\/h2>\n\n\n\n
\n
Layer 2: Application-Level Security<\/h2>\n\n\n\n
\n
Why I Don\u2019t Recommend Wordfence<\/h3>\n\n\n\n
Layer 3: A Real Web Application Firewall (WAF)<\/h2>\n\n\n\n
Layer 4: Hardening WordPress<\/h2>\n\n\n\n
\n
What About Patchstack?<\/h2>\n\n\n\n
\n
How Security and Performance Are Two Sides of the Same Coin<\/h2>\n\n\n\n
\n
Understanding How WordPress Sites Actually Get Hacked<\/h3>\n\n\n\n