Large WordPress logo featuring an armour shield with a checkmark inside, a lock, password illustration, five stars, and plug.

Securing WordPress and Building Trust While You Do It

by | January 7, 2021



As someone who has worked professionally with WordPress websites for 15 or so years, the most common question I have heard from clients, coworkers, and even other colleagues in digital is some variant of: “Is WordPress secure?” 

The simple answer is yes, WordPress is secure. But “WordPress” websites are built with more than just the core, open-source CMS provided by Site administrators tend to build up their WordPress websites with additional, 3rd-party plugins and themes that are not governed or managed in the same way to the same standards as the CMS core. This practice opens sites up to vulnerabilities. Additionally, because WordPress is so user friendly, it has grown to immense popularity. Many site administrators are not, therefore, trained security architects, or otherwise don’t necessarily keep up with the latest security news and best practices. This lack of knowledge and awareness also contributes to security vulnerabilities developing and especially going unnoticed for prolonged periods. 

 A computer showing a screen that reads "under construction" implying that a website is being built.


I have written this article for WordPress site admins that want to harden the websites under their purview. If you take to heart the strategic and tactical advice I offer, you will dramatically decrease your risk of being hacked, while dramatically increasing your confidence in WordPress as a viable, secure platform on which to build sites today and in the future.

WordPress Websites Are Vulnerable

If you do nothing to proactively manage your WordPress site’s security, your site will be considered insecure. Why is this? The first thing you have to understand is just how popular WordPress is and why it's repeatedly attacked. It is the dominant CMS powering millions of websites. With a market share of 63.6% amongst all CMS-powered websites, or 39% of all websites, no other platform comes close. It powers both large scale commercial sites and tiny, individual user blogs. And because of this varied and wide-spread usage across every type of use case, it comes under attack more often, from every angle, than any other system. For the sake of comparison, Drupal, another PHP open source CMS, drives only approximately 2.5% of CMS-powered websites

WordPress websites are made up of three layers: 

  1. WP Core: the source code for the barebones, public CMS
  2. WP Plugins: add-ons to Core providing additional functionality written and shared by anyone in the community 
  3. WP Themes: the front-end of the website, interacting with both users, Core, plugins and the backend dashboard

Figures vary, but somewhere between 80-98% of all vulnerabilities stem from the second and third layers, plugins and themes. I’m going to focus on talking about plugins, but my advice applies to all three layers.

There is nothing unique about WordPress’s vulnerabilities. They are the same general risks faced by all websites, CMS-powered or otherwise: 

  • Brute Force Attacks
  • DDoS
  • File Inclusion Exploits
  • SQL Injections
  • Cross Site Scripting
  • Malware

Whereas Core is maintained and supported by a relatively small subset of active users, with extensive testing and reporting, plugins are offered as is with no warranty and little to no oversight. With over 58,042 plugins listed in the directory and little in the way of vetting, it’s not surprising that this is where the vulnerabilities lie. 

Interestingly, it’s the extremely popular plugins on one end and the extremely unpopular plugins on the other that come with the highest risk, but for very different reasons. Ubiquitous plugins like the Next-Gen Gallery and WooCommerce are repeatedly probed by hackers looking for new vulnerabilities simply because they are so popular. Popular plugins like these are actively monitored; however, when issues do arise, everyone in the community is made aware and updates are released quickly. On the other hand, plugins that are not actively maintained or reported on, do not get the same support and monitoring from the community. So when vulnerabilities emerge in them, no one is around to notice, let alone fix them. 

So while WordPress itself is just as secure as Drupal, Drupal has a positive reputation as the security-first CMS. This is a well-earned reputation. For instance, every Wednesday, the Drupal Security Team releases notifications of known vulnerabilities for both Core and contributed modules. The notices rank all vulnerabilities on a common threat scale and provide recommended resolutions. The content for these notices is mostly provided by members of the community, and it’s this active, unified Drupal community that maintains the regular, consistent communications schedule. 

There are no counterparts to this workflow for WordPress. Though the WordPress Security Team of 50 engineers manage the security updates for Core, there is no infrastructure in place to provide consistent updates for plugins or themes. There is no objective scale against which to rank threats. It’s up to the publishers of the plugins and themes themselves to release updates. When updates are released, site publishers are notified that a new version is available, but are not necessarily immediately informed of any risks that updates are meant to solve. 

In the organizations I’ve worked with, the above situations lead to frustration and stress because they can make it feel like you are constantly reacting, and constantly being asked to perform updates, updates which cost money and come with their own risks. Whereas Drupal provides a regular North Star to orient your course toward a more secure future for your website and business, reacting to WordPress updates is akin to adjusting sails based on every gust of wind -- you’ll keep moving, but you have no where you’re going. 

In essence, I suggest each WordPress admin construct their own security apparatus, their own strategies, workflows and best practices to keep their sites up-to-date and secure. I will now discuss and describe the apparatus I have built and adapted in my time as a Product and Project Manager of WordPress builds. 

All of my practices fall into the following three strategies: 

  1. Prevention through the adoption of best practices
  2. Use trusted, essential plugins and a system to track them
  3. Critically evaluate and strategically update 

Prevention through Adoption of Best Practices

Whenever possible, leverage managed hosting providers who have experience managing WordPress, firms such as Pantheon and WP Engine are well regarded in this area. If you do decide to host in the cloud in your own AWS or similar environment, ensure that your DevOps team understands the given cloud’s security tools and practices. 

Next, register for a security monitoring service. There are several highly rated security tools you can leverage, but I recommend Sucuri and WordFence. Both come with a plethora of features, including enforcement of strong passwords or 2FA, and WAF (Web Application Firewall). These two features alone help to reduce the most common attacks against WordPress sites. When installed and configured on your website, you will be able to not only prevent successful attacks, but determine where and how your site in particular is vulnerable.

If you’re able, adopt and promote a password policy in your organization that requires strong passwords and requires that they be changed and updated on a regular basis. At Kalamuna, we use 1Password company-wide. This also gives us the added ability to quickly add users when onboarding new staff and clients, and quickly remove users when there is turnover. 

One major win you can achieve quickly is to reduce the number of Administrator accounts on your website. It’s not uncommon for many organizations to look at WordPress user roles as an extension of job titles. Just because the Chief Marketing Officer approved the budget for the development of the website, it does not mean that that person should have an Administrator account on the website de facto. A practice I employed at a previous firm was to remove all Administrator accounts from brand websites, except for one, which was held by the DevOps team and controlled in 1Password.

No matter how secure the code on the site, users themselves represent a massive security vulnerability, so anything you can do to remove easily guessable passwords and shore up permissions, the better. Server permissions must also be managed, however. Lock down the file system so that it can’t write outside of /wp-uploads and to cache, and you help minimize another major weakness. Lastly, restrict access to admin routes (/wp-admin, /wp-includes, /wp-login) to IPs accessible only within a restricted range. In other words, require the use of a VPN to access the backend of the site. 

These preventative measures, taken together, immediately reduce the risk of being affected by the major security vulnerabilities noted above by orders of magnitude. 

Use trusted, essential plugins and a system to track them

A screenshot of the WordPress dashboard, open to the Plugins screen. Two common, popular plugins are seen on the screen.


My general philosophy around plugins is that you should use the fewest possible, only installing one to cover functionality that you can’t otherwise build or cover off in some other 3rd party manner. If not, you can pretty quickly find yourself with dozens of installed plugins, which can be a nightmare to manage when each requires regular updates. 

If you decide you need functionality not covered by your theme, nor by WordPress Core, and you are not in a position to custom build it, plugins are your only option. Despite my suggestions throughout this article, I am not opposed to 3rd-party plugins. They are necessary tools to perform key functionality and there are many offering functionality you would never want to pay to build from scratch (Yoast, anyone?) because the plugins are so well trusted and supported. 

Ask yourself several questions when deciding on a plugin: 

  • Is the plugin updated frequently?
  • When was the last time it was updated?
  • Is it updated to the current Core version? 
  • How many total times has the plugin been installed? 
  • What is the plugin’s rating? What do the reviews say? 

I recommend avoiding plugins that are not updated frequently or recently; that have a low number of installs; a low or no rating; and few or no reviews. 

If you manage a collection of WordPress sites, each with many different plugins, all needing updates at various times for various reasons, you’ll understand how tiring it can become just trying to stay on top of the process. At Kalamuna, we’ve started using MainWP as a tool to help consolidate our management of plugins across our network into one, singular dashboard. If you don’t have too many sites, you can log in to each and keep track directly from the Plugins dashboard. Note that there’s no set schedule by which plugins need to be updated, every one of them is on its own schedule. 

Before moving onto the third recommendation, I want to pause and draw attention to some sources of information and connections with the larger security community. In order to stay current with news and updates from the community, I have a few recommendations. First and foremost, from WordPress itself, I suggest keeping up-to-date with their news feed: WordPress News. Then, there are a number of quality blogs and sources for updates on plugins, themes and related vulnerabilities. You don’t need to be a client of either Sucuri or WordFence to take advantage of their security teams’ excellent advice and analysis, just read the Sucuri Blog and Wordfence Blog. From these sources, you will discover others you wish to follow, but these three should become weekly reading. 

Critically evaluate and strategically update 

A chessboard with two rows of pieces lined up waiting to move


It’s important to note that not all updates are security-related; however, non-security related updates can introduce security vulnerabilities. This is why you should always review the description of the update provided by the plugin or theme’s publisher, as well as any community posts about it. I would contend that it’s not always good to be the first to apply an update, a fact that thousands of site owners learned when they updated WordPress Core this past summer. Unless the notice says that it is absolutely essential to update and the community agrees, set it aside to update on your schedule.

At Kalamuna, we review all plugin update notices when they come in, and anything not absolutely urgent for security reasons is scheduled for the next “Update Day” -- a day each month where all updates are performed on our WordPress sites. When performing mass updates, remember the following:

  1. Back-up everything! Hopefully you are using source control like GitHub or Bitbucket or similar and can export a copy of your database just in case. Hosting environments like WP Engine and Pantheon make creating backups a breeze.
  2. Update WordPress Core first
  3. Perform all updates on a local copy of the site or branch
  4. Deploy updates to a test or dev branch first
  5. Test the site to ensure the update was successful

It is quite likely that auto-updating plugins and themes will cause no issues, but I’ve always found that when you update things manually, you get a stronger appreciation for what these plugins and features are doing for your website. You may also start to question whether you can live without some of them!

Security as a State of Being and a State of Mind

There are so many combinations of vulnerabilities and new risks emerging every day for an ever-growing CMS that there will likely never be a complete guide to WordPress security, at least not one that would be easy to read, to understand, and to apply to every possible website and business use case combination. And the cold reality is that sometimes, even if you do everything in your power, you could get hacked. 

Proactive and consistent communication is critical to fostering a genuine, organization-wide feeling of security. I suggest going further than just circulating your process. Go beyond by regularly sharing interesting tidbits you read in blogs, consider starting a security newsletter, or Slack channel to keep people updated in real-time, explain the security benefit to each change you bring in (like changing passwords quarterly, which can often be faced with strong resistance). Communication reduces anxiety and builds trust. It will go a long way toward building up that sense of security your organization will have in WordPress and in you as the steward of good security.

Thinking about securing your current site? Kalamuna can help as we offer a wide range of development, support and security services for WordPress, Drupal and custom CMSs. Let’s talk!

Sean Lehane

Sean Lehane

Senior Project Manager

Why have we affectionately nicknamed our talented TPM, Sean, “The King”? It could be reflective of his expert leadership across both products and projects, which began when he built and sold his first website at 13. Though, we may have been inspired by his very regal desk chair and proficiency in Latin and Ancient Greek. Either way, he wields his power with humor and grace, leaving a trail of success and delight in his wake.