A question recently came in from a client…

“At a board meeting today, one of our board members with some cyber background asked about security measures for our website. He contended WordPress is more hackable than Drupal and wanted to know what measures had been taken to secure the site, given that [our organization] is an obvious target. I said that you are an expert in security and made security of the new site a focus during its design.“

“I’m sure I’ll get follow-up questions on this. Could you give me a rundown on how your team has approached security for the new site, what protective measures are in place, what kind of monitoring goes on to detect/thwart hacking attempts, and so on? I am not by any means an expert in this area; a little information from you would help us respond to the inevitable questions to follow.“

This was our response…

I think it would be helpful to put things into context. WordPress powers more than half of the world’s websites, approximately 75 million.  Drupal, on the other hand, only powers about 1 million websites.  Given the greater number of websites powered by WordPress, there will be an inherently greater number of hacked WordPress websites.  But, if you go by the percentages, WordPress does not necessarily have a greater rate of hacks.

Also, it is important to remember that both WordPress and Drupal are community powered websites.  So, if a vulnerability is discovered then the community of developers crowdsource the problem.  Just like there are 80 times as many WordPress websites as Drupal, there are significantly more developers concerned with keeping WordPress secure. WordPress has a greater Army of soldiers helping to protect and defend it.  Having said that, WordPress is a larger target so hackers are more likely to try to hack into WordPress than Drupal.

There is an app called CVE that monitors and measures security vulnerabilities.  It has tracked 287 vulnerabilities for WordPress and 177 for Drupal. As you can see from CVE results, your board member is correct, Drupal has fewer vulnerabilities than WordPress.  

What Drupal does that WordPress does not is containerization.  With Drupal, you can more easily limit the damage any one user role has with regard to scope and access.  However, WordPress does have plugins that will emulate what Drupal does out-of-the-box.  But, we also need to remember that if a hacker gets root, system, or admin access then they most likely have access to everything anyway.  Containerization gives almost a false sense of security.

It is also important to realize that while people recognize WordPress may be slightly less secure than Drupal, they still prefer WordPress anyway because it provides a much more pleasant user experience for content managers and is less expensive to build and maintain.  People choose WordPress over Drupal despite the inherent security disadvantage.
When you look at the core, i.e., WordPress core vs Drupal core, both are pretty secure.  Where vulnerabilities lie and where hackers come in can be categorized into two main buckets:

1. Human error
   
2. Modules, Plugins, and Extensions

Human error would be when people fall for phishing attacks.  It doesn’t matter if we are talking about Drupal or WordPress or Gmail, none of them are secure if the user allows his or her userid and password to get into the hands of hackers.  So, your organization needs to maintain a culture of security.

While Drupal security for Drupal modules seems to be generally tighter than WordPress security for WordPress plugins, the real issue is in the choice, selection, and configuration of those modules and plugins. Honestly, I think the modules we were using in the previous Drupal website were riskier than the plugins we selected in the current WordPress website.

BOTTOM LINE: While no website on the planet is absolutely secure,  the website has multiple layers of security, monitoring, and protection including Cloudflare, New Relic, and multiple secure socket layers (SSLs).

Hese are the additional steps we have taken to secure the website:

Architecture:

The architecture has been designed so there is no direct access to the application or database server.Instead of hosting everything on a single server or what is worst, a shared server with other websites, the website follows a micro-services architecture.

In the front, we have Cloudflare to serve HTML content, so we take advantage of their layer to filter identified malicious IP address and block common hacking attempts. To serve files, images, and assets in general we have Amazon CloudFront. Behind Cloudflare is located the cache server, that acts as a proxy to the application server. The database lives on a separate server. The application server (where WordPress lives)  is on a separate server too.

App, Cache, and database server are not visible and are completely closed, so only Cloudflare can see Cache server. 

If a visitor tries to get access to those individual servers won’t be able to do it. We have only allowed access to these servers through a third server that follows strict security authentication policies through LDAP and 2-factor authentication.

Media and static content are hosted on Amazon CloudFront with copies around the world so It’s served from the most convenient data center.
SSH access and access through any port are restricted to specific IP addresses.

WordPress security and updates:

• We apply security updates to the servers, WordPress, and plugins twice a month or immediately if a vulnerability is discovered.
  
• Following security best practices like:
  
• Right files permissions.
  
• Strong usernames and passwords.
  
• Database obfuscation.
  
• xmlrcp.php restriction (target of most of the attacks).
  

Monitoring:We have monitors configured for the servers, so we can check the health anytime and receive notifications to Slack if something is not good.

Malware scan:We run an automatic weekly scan for malware to the server.

Disaster recovery:

Even if we are super secure, there is always a risk, and we need a way to revert the site in case of a successful hacking attempt:

• We have configured daily backups of the app, and database servers on the provider level (Linode)
• Hourly backup of database and files using UpdraftPlus service.