If we were to ask you, which of these people had a secure site, what would your answer be? 

Are they all right? Are some of them right? Are a combination of them right? Who should you listen to, to secure your site, data, visitors, customers, revenue, etc?

Unfortunately, if you answered A? Wrong answer. 
If you answered B? Wrong. 
If you answered C? Wrong.
If you answered D? Wrong. 

Even if you took a risk and answered all of the above? Still wrong.

Each of the items in that list is on a WordPress security checklist that every admin should follow. But these steps are not enough to prevent your site from being hacked. 

There was no good way to evaluate security

The truth of the matter is that, until WP-Radar, there was no definitive way to evaluate WordPress security. We used to rely on signals rather than evidence to evaluate security.

Bad metric: quantity over quality

A firewall is often judged on the number of attacks it has blocked. The more attacks a firewall blocks, the better and more effective it must be.

But the focus here should not be the number of attacks blocked, but the types of attacks blocked. WordPress attacks span a spectrum, and some attacks are orders of magnitude more severe than others. 

For example, an attack that targets a vulnerability is 100x worse than a brute force attack trying to guess a password; which in turn is 100x worse than a content scraper bot used by another site. Just because a firewall is able to block 1000s of brute force and scraper bots, doesn’t mean it will block an SQL injection attack or a remote code injection attack successfully.

In full transparency, we at MalCare have also used the number of attacks blocked to signal the effectiveness of our firewall. We’re not proud of contributing to the problem. 

Bad metric: never had malware

As security providers, we also hear this refrain painfully often: “My site has no malware, and has never been hacked. Therefore my security must be good.” 

Honestly, this makes us happy to hear, but we also know that this is not because site security is necessarily good, but that the site doesn’t currently have a vulnerability. 

Concurrently, it certainly doesn’t guarantee that the site will never have a vulnerability. Installing a new plugin could add a vulnerability. Upgrading to a new version could add a vulnerability. Changing the theme could add a vulnerability. 

In fact, saying your site has never been hacked is proof of good security is very much like saying a house has never been burgled is proof of good security. If there is a good fence, good locks, and a good alarm system, then yes, there is merit to that statement because it can be tested against thieves. Can you say the same about hackers?

Bad metric: self-reporting

Apart from a firewall log that says that this request is good and that one is bad, how do you know whether the request was actually good or bad? 

Perhaps if an admin is locked out of their own site, they can point to the good-but-marked-bad request and say that it was flagged incorrectly. But can anyone point to a bad-but-marked-good request with the same conviction? 

There is no way for a site owner to know what kinds of attacks their firewall can and cannot block. Assuming your firewall is blocking all malicious traffic, based on the information the firewall itself gives you, is confirmation bias.

Unless a site admin uses penetration testing—which is frankly out of the scope of most individuals—or a tool that can unequivocally give them that assurance. 

A tool that didn’t exist for WordPress security till we created it: WP-Radar.

WP-Radar: Test WordPress security empirically

Obviously you want the best security for your site. And up to this point, you had to rely on often conflicting security information and opinions, and wade through a whole lot of misinformation to get some vestige of security. 

Now we present an alternative: WP-Radar. 

WP-Radar is a security testing tool for WordPress sites. It tests the effectiveness of your security stack: whether it is a plugin, firewall, web host, or a combination of them. It is 100% open source and therefore 100% transparent. 

Don’t listen to anyone; us included. WP-Radar equips you to get your own answers and make good, informed decisions about your site security.

What WP-Radar does 

WP-Radar puts your site security to the test. Since 95% of WordPress hacks occur because of vulnerabilities, WP-Radar tests if your site would get hacked if those vulnerabilities existed on your site. 

Let’s break it down a little more.

Hackers target particular vulnerabilities on WordPress sites and create requests to exploit them. If the site security blocks these requests, the attacks are thwarted. However, if a request reaches a site, it can exploit the vulnerability on the site and therefore compromise it. 

WP-Radar creates requests that mimic attack requests. For example, WP-Radar crafts a dummy attack request for a particular vulnerability, like an SQL injection vulnerability, and sends it to your site. If your site’s security is able to flag WP-Radar’s request as an SQL injection attack and block it, your site is safe from that class of hacks. 

The critical difference is that WP-Radar’s requests are harmless. They cannot change anything on your site. They merely retain the superficial similarities to a real attack request in order to test site security. 

In this way, WP-Radar tests against all high-severity vulnerabilities that could seriously damage your site. 

How WP-Radar works 

WP-Radar evaluates site security by recreating a real threat scenario, but in a safe and controlled environment. 

Think of crash test dummies used in car collision tests. The test results are only valid if the dummies match real human beings as much as possible, but obviously without endangering actual human beings. 

In the same way, WP-Radar keeps the same variables of a hack, but removes all the danger of one. It is so safe, you can run WP-Radar on your production sites. The only part of your site that will feel any stress is its security. 

Authentic testing with a unique two-plugin setup

As we explained, WP-Radar is designed to mimic the hacker-site process, so it is set up over two sites: one site is the target for evaluation, and the other acts as a hacker. This is the most authentic way to test site security, as the dummy attack request must come from a different server. 

We recommend setting up a staging site or using a tool that spins up an instant WordPress site for this purpose. 

To build on our crash test dummy analogy from before, this setup is akin to making sure that the test matches a real-world traffic scenario.

Easy testing with a vulnerability sandbox

Hackers attack sites by targeting a particular type of vulnerability. Therefore, one of the ways to test if your site security defends against said vulnerability is to install a plugin with it. And then attempt to exploit it from outside your site. 

For instance, to test if your firewall or security plugin can block a privilege escalation attack, your site must have a privilege escalation vulnerability on it for the hacker to target. You would then take the place of the hacker, and send requests to your site in an attempt to bypass your firewall and exploit the vulnerability. 

For obvious reasons, this is not safe, or recommended. Plus if it sounds daunting to do, that’s because it is. It is also well outside the scope of many WordPress admins. 

WP-Radar precludes all that fuss and bother, by emulating the vulnerability on your site, without creating one. So when the external WP-Radar plugin looks for a vulnerability to exploit on your site, the internal WP-Radar plugin presents a dummy target. If WP-Radar’s dummy attack request reaches WP-Radar’s dummy target, the site’s security has failed to protect it from that type of attack. 

For a crash test dummy to truly represent a human being, it needs to be in the car during a massive collision. Only then can we measure the efficacy of the seatbelt and airbags. Under no circumstances, it is possible or even desirable to put a real human being in that scenario.

Tests for vulnerabilities past, present, and future

WP-Radar is developed to test for classes of vulnerabilities and their associated attacks, not specific vulnerabilities in particular plugins or themes. 

As we discussed previously, a site without a vulnerability is simply a snapshot in time. It is not an enduring state that remains unchanging. 

We have seen that vulnerabilities can exist for years before they are discovered by white hat security researchers. This distinction is important, because it often means that the same vulnerabilities are actively exploited by hackers. Good security should protect a site from being exploited from vulnerabilities, regardless if they are known or not. 

WP-Radar is not a vulnerability scanner; our plugin MalCare does an excellent job of pointing out if installed plugins or themes have vulnerabilities. It can even help you update those vulnerable add-ons, which is a critical aspect of security. However, the absence of known vulnerabilities does not equal no vulnerabilities. The goal is that your site should be protected, regardless. 

More importantly, WP-Radar checks site security for exploits not just against past and current vulnerabilities, but also ones that haven’t been discovered yet. This is the only way to gain a real sense of security.

How WP-Radar adds a new dimension to WordPress security

The best part about WP-Radar is that it polices site security, without changing the actual site in any way. WP-Radar is an attack sandbox, and is completely safe to use on even live sites. Testing site security will not disrupt other site operations at all. 

Furthermore, we have implemented critical guardrails to ensure that WP-Radar is 100% secure and cannot be misused under any circumstances. 

WP-Radar in action

For example, let’s consider a very common scenario with WordPress sites. An attacker is trying to take control of a site by trying to create an admin account on it.

The hacker’s request will target a vulnerability on a site, and attempt to fool the site’s security by disguising itself as a legitimate WordPress request.

WP-Radar replicates this request, but changes it slightly. On the surface, it looks exactly like a hacker’s attack request. This is to make sure the site’s security treats it like it would a hacker’s request.

Therefore, if a hacker sent a request and it was blocked, WP-Radar’s request will also be blocked. The converse is also true, so if WP-Radar’s request is allowed through, so will the hacker’s. 

The key difference between the two requests lies inside the request. We have altered some key parameters within WP-Radar’s request, and thus ensured that it will not affect anything on the target site.

If WP-Radar’s request is allowed to reach your site, you will get a notification that the attack was successful. But your site won’t get a new admin account as a result. As a matter of fact, nothing will change.  

Why we made WP-Radar open source

We believe that real accountability is needed in the WordPress security space. Along with misinformation that spreads like wildfire, several vested interests have made the end WordPress user even more insecure than before. 

Our research has led us to put the power of transparency in the hands of people who most need it. Security researchers and experts in the field can all examine WP-Radar code to ensure that it does what we say, and that there is no hidden threat. Further, as an open source tool, we hope researchers will contribute their own test cases to further improve WP-Radar for the good of the entire ecosystem.

In fact, we also tested sites that had MalCare’s firewall, and found gaps thanks to WP-Radar. It led us to rebuild our security from the ground up. We hope that by building a robust testing tool, we hold the entire industry accountable—including ourselves.

Test your site security and make your own decision

We’ve designed WP-Radar to put your site security through its paces. You have full control, and for the first time ever, you will have an objective assessment of the efficacy of your site security. 

It is deliberately designed as a two-sided plugin, so it will not make any changes to your site. Install one plugin on a dummy or staging site, and the second on your target site. 

Then, sit back and get a clear report on the state of your site’s security. For better or worse, you will get an answer. In fact, try out all the other security mechanisms, and see if they can block attacks effectively. We’ll wait. 

When you have your answer, keep coming back as we update WP-Radar with more of our research into WordPress vulnerabilities.