I recently wrote about our startup that failed and it’s prompted many, many questions about WordPress and our solution. Our product solved the speed, security and scaling problems of the platform while letting users continue to use it for content administration. At last count, I’ve had over 80 emails and messages on the subject — including questions from major hosting companies.

WordPress has developed the most popular platform in the world for creating websites so I want to explain the key criticisms in more detail. I’ve been a WordPress advocate for many years (I attended WordCamp in San Francisco in 2010!) and have built more WP sites than I remember. Nothing I say is meant to diminish their achievements but rather raise the profile of the significant and growing security issues around managing this platform.

For non-technical users, WordPress is by far the easiest tool for building a website and people love it. One of the reasons our product focused on WordPress was that we wanted users to keep using it — talking to WP enthusiasts, it’s clearly their preferred way to manage web content. We saw an opportunity here to allow people to continue using their favorite CMS while our product handled the security and delivery issues separately.

This article is meant to provide some perspective on where we are in 2018 because the landscape is changing. My warnings about WordPress are nothing to do with the UI, admin, backend, themes or plugins ecosystem, or the committed work of thousands of devs. Technology has changed dramatically since WordPress was first developed and sophisticated threats have since evolved.

If you are a business user of WordPress or you have a site that’s more than a hobby blog, you need to understand the risks because here be dragons.

Vulnerabilities aren’t the problem. It’s all about the blast radius.

WordPress is an open source product with a vibrant community of smart developers. Like any popular piece of software, it’s a target for hackers because of its omnipresence. If you chart the number of vulnerabilities discovered, it compares with other popular FOSS products:

These problems occur at many levels — one analysis in 2016 showed plugins were the preferred way into most sites. The exact breakdown is hard to measure but with 30,000 plugins and thousands of themes, these obviously represent the most dangerous part of the system. Beyond that, there are numerous insidious ways into a target site.

Source: WordFence

One clear weakness is running old versions of WordPress, which this year became much more likely since WP 4.9.3 broke the auto-update feature so people who depend on the auto-update might not even realize it stopped working (most of our beta sites had stopped updating at 4.9.3). Since WordPress by default publishes its version in the page metadata, it’s trivial to find sites running out-of-date, vulnerable versions.

Vulnerabilities in themselves are not fundamentally a measure of software being “bad” — in fact, it’s great that bugs are found and fixed. That’s not the problem. The difficulty for WordPress is that there’s no control over the blast radius when Bad Things Happen. It’s like having your wallet stolen and then finding you’ve also lost your house and 401k.

Every WordPress risk is potentially an existential one.

DevOps people know that all software is vulnerable all the time, and there’s a constant stream of zero-day exploits and embarrassing holes in even revered applications. Controlling production systems is not so much about eliminating these problems, which would be close to impossible, but managing the fallout when Bad Things Happen — a.k.a. managing the blast radius.

The problem has nothing to do with picking on WordPress or preferring another CMS (I don’t) — it’s that every security hole turns into an existential crisis that can cause loss of control of the server, theft of all the data, or malware taking over. And this is the nut of the problem — any of the plugins, themes and WordPress versions you use can be harboring bugs or malicious code that create an existential risk to your site — and your business. There is no control over the blast radius.

In WordPress, there is no sandboxing of plugins and themes — when their code executes, they have full access to everything the main WordPress process can see. This includes every database record and every file in the application. Even in multi-site mode, the themes and plugins can operate across the entire installation. This is why you are always one bad plugin away from total disaster. Even with the best maintenance and malware scanning available, this blast radius creates a huge business risk.

Any theme or plugin could run code like this.

If you compare this to how your phone’s OS works — which is also a core-plus-plugin environment — apps are limited in both what data they can access and what actions they can perform, and how they interact with other apps. When bad apps occasionally make their way through the app stores, they don’t brick your phone or release all your banking information. If phone apps used the same security model as WordPress, smartphones would be unusable. By limiting permissions, smartphones ensure that when Bad Things Happen to apps, the blast radius is typically small.

The risks today have much greater consequences.

Back in the early days of WordPress, it probably didn’t matter if your site got hacked. It was annoying for sure, embarrassing and time-consuming, but in most cases wouldn’t cause any sort of panic. You would likely notice quickly because the favorite hacker activity was defacement — one minute your site is showing off restaurant menus, the next it’s sponsoring militia groups in Thailand.

Today this has changed considerably. The rise of automation means all sites are targeted, not just the high profile ones, because it’s not a hacker in a hoodie sat behind a keyboard. Just one defacement hack in 2017 resulted in 1.5 million affected WordPress sites. Now when hackers succeed, the payloads are often hidden, secretly Bitcoin mining, sending spam, scraping personal data or leaving backdoors for future visits. One security blog claims that 90% of WordPress site owners didn’t notice after being hacked, and many never determine the root cause even after discovery.

GDPR brings a whole new level of legal risk. Even with basic form collection on your website, a vulnerability can make your business run afoul of mismanaging personally identifiable information (email addresses are PII). The penalties for GDPR violations include a whopping 4% of global revenue, which means you now have to take these vulnerabilities much more seriously. A breach on your website could put you out of business. And if you think the popular WordPress GDPR plugin can help you, it too was hacked.

If you’re running WooCommerce, a popular ecommerce plugin for WordPress, all your transactions are living in the same database that all plugins and themes have access to. You are a few lines of malicious PHP away from having all that transaction and order history scraped, sent to the bad guys and your entire business potentially getting wiped out because there is no limit to the blast radius. Or maybe, worse yet, the hackers just install code to silently scrape payment data and you don’t notice for months.

Managing WordPress is now an activity for professionals.

If you install WordPress using the famed ‘5 minute installer’ there are a slew of additional tasks you must complete to provide even a minimum level of security. Many web agencies we encountered did not know how to do this, having a profound confidence that the installation process is good enough and turning to plugins for every other need. We repeatedly found serious holes in their sites.

Unless you know some Linux, you can get yourself into trouble in getting the basics right. For example, leaving your wp-config.php in a readable state exposes all your site secrets and the admin database login, yet with some basic Google dorking we discovered thousands of sites with this problem:

Again, all your site’s secrets are written into a PHP file in /var/www/html, just a chmod away from becoming publicly readable and — boom — there’s that blast radius problem again.

While there are security plugins that you should use, ironically many have had their own vulnerabilities and others cause known performance issues. In the top list of plugins that commonly appear across thousands of sites, almost all have had major security problems in 2018 — Jetpack, WooCommerce, WPForms, Smush, Yoast SEO, the list goes on and on.

The latest core release of WordPress to version 5.0 itself included a serious bug that allowed Google to index the site’s user passwords. And this was only 1 of another half dozen major security flaws in processes that should be fairly mature by now. This was barely a week after the news that a botnet of 20,000 WordPress sites was actively attacking other sites using the XML-RPC service. Unless you understand how to manage and secure various advanced features of WordPress like the REST API or XML-RPC service (did you know they even existed?), you are wide open to these kinds of problems. Oh, the REST API had one of the “worst WordPress-related vulnerabilities” too.

We developed a hardened build of WordPress on Amazon EC2 for our company because we occasionally deploy the CMS for clients. Beyond the dozens of implementation details that secure everything from file permissions to MySQL’s default install, we used AWS Security Groups to limit access, automate snapshots with EC2, push the database to Aurora for better performance and automated backups, and put CloudFront in front to provide enterprise-grade WAF and DDoS protection without exposing the instance. These are all elements that often don’t exist in standard hosting.

But even with the AWS approach, configuration drift is a real issue — if you allow auto-updates, a previously ‘safe’ configuration might now harbor malicious code, and if you manually push updates, it’s incredibly time consuming and you could be slow to implement urgent patches. We also dared not put multiple clients on the same instance because of the shared data problem — there was no way to segregate their data without some huge custom effort — so we end up managing a fleet of EC2s.

Consequently there is an ever-evolving level of complexity in managing sites that simply didn’t exist a few years back. We cataloged a list of issues and identified 80+ major items from implementing security headers to OAuth, blocking brute-force logins, IP-blocking and correctly configuring SSL certificates. In the companies we talked to, most had implemented nothing — not even WordFence.

We don’t even offer this service anymore because we don’t have the resources to continuously spend time on monitoring and maintenance. Nor did we want to become a hosting company. For this reason, we advise clients that if they want to use WordPress they should:

Hire a Managed WordPress provider like Pagely, Kinsta or LiquidWeb. These companies understand the nuances of the WordPress environment and can secure your site reliably. Do NOT use generic hosts, cheap shared hosting or hosts with no reputation specifically in WordPress (you know, the ones that are everywhere).

like Pagely, Kinsta or LiquidWeb. These companies understand the nuances of the WordPress environment and can secure your site reliably. Do NOT use generic hosts, cheap shared hosting or hosts with no reputation specifically in WordPress (you know, the ones that are everywhere). Let your internal IT manage WordPress : if you have the resources, use internal DevOps to manage your WordPress install since they have the variety of platform and security skills needed to successfully lock it down. Don’t just give it to your agency who will likely not have the skills needed to protect your site (or farm it out to a cheap host).

: if you have the resources, use internal DevOps to manage your WordPress install since they have the variety of platform and security skills needed to successfully lock it down. Don’t just give it to your agency who will likely not have the skills needed to protect your site (or farm it out to a cheap host). Seriously consider SquareSpace or Wix. Also take a look at Strattic, a newer service also using serverless tech to solve the problems.

It might sound obvious but we repeatedly found that clients were not familiar with the risks of running WordPress themselves in the modern IT environment. They had way too much confidence in claims from cheap web hosts or vanilla plugins, and usually didn’t understand the technical elements well enough to detect when Bad Things Happen.

Why do businesses have websites in the first place?

So here’s the thing — the vast, vast majority of WordPress sites I have seen are brochure sites. They consist of a dozen pages, modified infrequently, and maybe have an email collection form or some other limited interactivity. There has been a decline in the popularity of including blogs in your business site, or allowing comments, so many sites are now just static content.

Working backwards from what the customer wants, if this is what the majority of businesses have in 2018, using WordPress is the proverbial sledgehammer cracking a walnut. For organizations just wanting a collection of static pages, it’s overkill to have an entire LAMP stack to maintain and secure. While this was not an option when WordPress was first created, today we have S3, Netlify, Google Cloud Storage, and a dozen other options for hosting zero-maintenance and virtually unhackable static pages.

WordPress (and many other CMS systems) originated in last decade’s tech and are anchored in the LAMP stack. While they have fought off the bad guys admirably, nobody would ever design their solution with modern application approaches. The difficulty is that WordPress is now so entrenched and there’s such a huge ecosystem of providers, the better technical approach is going to take a while to break through.

Scaling is another huge problem for WordPress. Managed providers can handle it with some nifty engineering but out-of-the-box it doesn’t scale well, mainly because it was never designed to scale horizontally. You might think this doesn’t apply to your business but we discovered that we could effectively DDoS many client sites with around 1000 concurrent http requests. Considering web pages often consist of 150–200 http elements on a single page, that’s not much traffic. (We found this accidentally with a Lambda web scraper that scaled a little too enthusiastically and knocked over a number of our testing sites.)

There’s a better approach coming.

We built our failed product as a stop-gap solution — it allowed customers to keep using WordPress but we used serverless delivery mechanisms to overcome the security, speed and scale problems. This of course is sub-optimal when you could just find a better way to build websites. We’re basically offering to put your horse and cart on the back of a truck, when you should just get a car.

But the car is coming. I’ve been watching static site generators from the sidelines for years and while there have been some impressive developments, they are still targeted firmly at a technical audience. Recently, I’ve become excited about Gatsby which looks to be a genuine contender to plug the gaps in this space and for JS/React developers, it’s an obvious next step. Vue/Nuxt looks to be right behind, both offering a similar solution to the same problem.

Both use the JavaScript/API/Mobile approach — the so-called JAMstack — which solves most of the serious security problems in the WordPress world. It also addresses many of the speed issues that Google now ties to SEO rankings since the sites are blisteringly fast (see Airbnb’s engineering site) and they are perfect for high-performance, spiky-demand ecommerce sites (see Stitch Fix) because they scale automatically at the speed of cloud. Ultimately, WordPress will give way to something better.

Full, dynamic ecommerce site Stitch Fix is built on Gatsby.

WordPress is not best choice for most companies anymore.

While the content management UI makes it easy for non-technical users to manage a site, the security problems make it equally easy for bad guys to take over. As a business you have to balance the risk-reward of using WordPress but given the legal and financial dangers, for most business sites I no longer believe WordPress is the right choice.

Strong words are needed to call attention to the numerous and growing security issues that mean over 70% of WordPress installations are vulnerable to hackers. I don’t hate on WordPress at all but I stand by my original comments — it is an outdated piece of software with a massive attack surface and an ever-changing list of vulnerabilities. It is a nightmare to manage from a security perspective. As a business, unless you are willing to employ external expertise or internal IT and recognize the complexity of managing it, you are asking for trouble.

My biggest fear with the platform is the blast radius is uncontrollable when Bad Things Happen. For anyone coming from the modern IT world where we spend considerable time thinking up ways to minimize the blast radius — because Bad Things Happen all the time — it’s completely shocking. In the next few years, it seems natural that JAMstack alternatives will fill this space but in the meantime if you stay on WordPress, you should expect hackers to give you 100% of their attention. Please at the very least seek the expertise needed to protect your site.