WordPress Security on Application Layer

Once you have your server ready, you’ll need to set up the application that you wish to host there. This application in my example is WordPress and all of the different plugins, themes, and custom code you add to it.

The decisions you make here have the biggest impact on the overall security of your WordPress site.

In fact, the majority of the WordPress hacking incidents happen because something in this layer failed.

What to focus on in the application?

The biggest difference between WordPress websites that either “make or break” the security boils down to the installed software stack.

WordPress core itself is actually very secure; it’s been around for 20+ years, and thousands of developers and security experts have gone over the codebase.

The same can’t be said about most of the plugins & themes that you install on your WordPress applications.

The more popular the plugin is, the more developers have looked at its code, but since plugin development happens in a more closed manner (compared to core), most of them are built by just a few (or even just one) developers.

WordPress is a content management system, so it’s built for people to make it easier to manage content. And as soon as people get involved, you’re opening Pandora's box of access management.

Choosing the right WordPress stack

One of the most important decisions you need to make is what plugins to use for a specific WordPress site. Even when it’s just about adding a simple form to your site, you have dozens of different plugins to choose from.

I would highly recommend choosing your stack based on:

1. Functionality: Every plugin you add adds weight. Plugins that drift away from their intended functionality often become bloated. Bloat is bad for performance and often adds complexity, which can introduce unexpected vulnerabilities.
2. Code quality: Code that is well-maintained and documented is less likely to include bugs and security vulnerabilities. The code should follow the WordPress codex, have clear licensing, and not rely too much on third-party code.
3. Security practices: Plugins should have a security point of contact and should release security patches without delay. Clear communication is equally important, so the users would know to update.
4. Reputation: It’s important to choose a plugin that is built by a trusted developer. Great developers are active and support their users. You don’t want to end up relying on a plugin that gets abandoned by its developer.

Try to stick with the same stack on different websites you build. Use only the ones you really need and keep the overall number of installed plugins/themes as low as possible.

Make sure you’re also subscribed to each of the plugin's official communications.

Maintenance and vulnerability monitoring

WordPress core and every plugin/theme need maintenance. Developers release new versions that include new features, bug fixes, and security updates. Sometimes, updates are also needed to stay compatible with the new WordPress core updates.

If you’ve selected your plugins based on the criteria’s listed above, then you should be able to worry less about breaking changes and have better insights into which updates can wait, and which ones need to be prioritised ASAP.

The most important thing to watch out for is security updates.

Unfortunately, not all plugin developers are transparent with security fixes, so using a third-party vulnerability monitoring solution can really save your day.

Vulnerability management and mitigation

Even if you’ve turned on auto-updates or turned on auto-updates only when security fixes have been detected in a new version (you can do that with Patchstack), then you still need to keep in mind that ~30% of published vulnerabilities don’t receive fixes in time.

Security vulnerabilities in plugins can become mass-exploited in a matter of hours. If you don’t update to a fixed version before that or if a fixed version is not released by the developer at all, then chances are that your website will get compromised.

To reduce such risk, you can get help from security services that create vulnerability-specific virtual patches that can be activated on a website automatically without any code changes or disruption and can instantly mitigate the vulnerability.

Access management

Not every user on the site needs administrator rights. Administrator accounts should also not be used on a daily basis for content management.

Unfortunately, we see that admin accounts are being used all of the time.

If possible, developers should avoid giving admin accounts to the users of the website.

In most cases, the Author role is more than enough for people who work on the website content. If there’s more than one person who might collaborate on the same content, then you can assign Editor roles.

If you have not noticed yet, it’s also a year 2024 already, so if you’re still not enforcing 2FA on all privileged accounts (anything contributor or higher), then you should go and do that immediately.

I personally hope that this year we’ll finally see 2FA being introduced into the WordPress core.

If you want to secure your access management, look into Fortress, which offers 2FA, session protection, password security, and login protection. You can also look into Solid Security for that (they have been advocating passkeys, which is great).

It’s also a really good practice to log out of your account when you’re done, and ask (or enforce) others to do the same.

Conclusion

If you look at the amount of code that makes a WordPress application run, then in many cases, WordPress itself is the smallest part of it. WordPress is popular for the endless possibility for customisation. But this is also what can make it the most vulnerable.

Choose your stack wisely, don’t slack on maintenance, and make sure you’re not left in the dark when it comes to security vulnerabilities.

Don’t rely only on the plugin developers either – take security into your hands by making sure the vulnerabilities get mitigated (virtual patched) as soon as they are published.

WordPress is for content management, and different people may be working on the content over the years. Avoid giving out admin accounts and make sure old accounts are deleted. If you’re not already using 2FA yet, then set it up now.

Resources:

• WordPress vulnerability database: https://patchstack.com/database/
• What is WordPress virtual patching: https://patchstack.com/articles/virtual-patching/
• WordPress roles: https://wordpress.org/documentation/article/roles-and-capabilities/
• Fortress: https://github.com/snicco/fortress/blob/beta/docs/readme.md
• SolidSecurity: https://solidwp.com/security/