It isn’t uncommon for people to claim that server level security should be relied on instead of using a security plugin to help secure a WordPress website. Like most WordPress security advice, what we have yet to run across is anyone that was actually providing evidence to back that claim up. The reality is that server level security isn’t able to provide protection that a well-developed firewall plugin can. To help explain that, we will look at a fairly serious vulnerability that was disclosed in a WordPress plugin earlier this year, where two firewall plugins provided protection before the vulnerability was even disclosed, while server level security wouldn’t protect against it.

Automattic’s WPScan disclosed an authenticated option update vulnerability that had been in the plugin Themeflection Numbers, which they credited “dc11” with having found. Alongside disclosing that, they provided a proof of concept that with an older version of the plugin would allow anyone logged in to WordPress to change WordPress settings. So they could create new WordPress accounts with the Administrator role. Not surprisingly, based on what can be easily done with that, we saw what appeared to be a hacker probing for usage of the plugin a week after the disclosure.

The best way to protect against a vulnerability once it has been fixed is to update to the fixed version. With this vulnerability it was fixed weeks before WPScan’s disclosure. The developer disclosed the new version included “security updates”. But what about a situation where the vulnerability hasn’t been fixed? Being warned about it could be useful, but oftentimes, providers, including WPScan, will tell you the vulnerability has been fixed, when it hasn’t. In a worst -case scenario earlier this year, a vulnerability was widely exploited months after it had been “fixed”.

Being warned about a vulnerability requires that the provider warning about vulnerabilities knows about it. This vulnerability had been in the plugin for 7 years and it could have been found by a hacker first. Other vulnerabilities are.

Writing a firewall rule for a specific vulnerability, whether for use by a WordPress firewall plugin or something at the server level, also requires knowing about a vulnerability. Despite that, two WordPress firewall plugins protected against this vulnerability before it was even disclosed. How they do that shows why server level security doesn’t provide important protection that a firewall plugin can.

Here is the POST data that would be sent when using the proof of concept provided by WPScan:

action=tf_numb_save_licenses&data[addon_0][key]=users_can_register&data[addon_0][val]=1&data[addon_1][key]=default_role&data[addon_1][val]=administrator

There isn’t anything that is obviously malicious about that which could be blocked on its own. Even if you would guess based on that information that WordPress settings were being changed, you wouldn’t know if the request is coming from someone that should be able to do that. So server level security wouldn’t be able to block this without having a reasonable possibility of blocking legitimate requests. There also wouldn’t be an easy way to override the block for a legitimate request in many cases, because of the server level nature of the protection.

WordPress firewall plugins have the ability to make a decision whether to block the request based on additional information. With both firewall plugins that provide protection against this type of vulnerability, they take advantage of two additional pieces of information. First, they hook into the process of updating a setting, so they know what settings are being changed and have the ability to block the request right before it is changed. Second, they know what level of access a WordPress user has. Someone who is an Administrator should be able to change the settings being changed, but lower-level users shouldn’t.

One of the firewall plugins simply stops all requests to make certain changes to settings if not done by an Administrator. The other blocks requests if the change to certain settings is made by someone other than an Administrator and the change is specified by user input in the request. Both approaches have upsides and downsides.

Look for Evidence of Protection

So server level security protection isn’t a replacement for a good WordPress firewall plugin. But with both server level protection or a firewall plugin, you are not guaranteed to get good protection (or even any protection). With the example above, only two WordPress firewall plugins offer protection, but those are far from the only WordPress firewall plugins or plugins that claim to provide firewall like protection.

What you should look for before considering any security solution is evidence, preferably from independent testing, that the solution provides effective protection.