Going Static — A Novel Approach to Securing Your WordPress Website
By Kyle Rankin
WordPress is a very popular platform for managing many different kinds of websites, from blogs to storefronts, because its user interface and large numbers of themes and plugins make it easy to build a site and manage content without having to be an expert in web design, HTML, or web programming.
Unfortunately, its popularity has attracted quite a bit of negative attention over the years, as it has become a popular target for hacking. After all, if you can find an exploit in WordPress, you can immediately compromise thousands of websites.
Many articles have been written over the years about how to harden WordPress, yet WordPress sites continue to get hacked. In fact, some security experts consider WordPress to be an instant liability. But secure WordPress sites can be built, so I tend to disagree with that claim.
Still, I’m not going to retread all the same recommendations from past articles and write a how-to based on steps that might become outdated relatively soon. Instead, I will direct most of my focus on a different, much more secure architecture built on static pages that you should be able to adapt to most versions of WordPress.
But first, I’ll start with a general overview of some of the basic WordPress hardening steps.
Standard WordPress Security Conventions
Whenever WordPress security comes up, a few standard bits of advice always get mentioned. While these are steps that all site administrators should do, many don’t; either because they don’t have time, don’t know what to do, or sometimes can’t (for instance, because they rely on a plug-in, theme or their own code that would break with an update).
It can be hard to keep up with security. Sometimes even when you follow all conventional wisdom and best practices, you may still get hacked. An attacker may find an unpatched vulnerability and exploit it before an update comes out. You did everything you were supposed to do, but your WordPress site still got compromised.
So, while I’ll talk about a better way to approach WordPress security shortly, let’s revisit the basics.
The first and most important advice for WordPress security is to keep your WordPress installation up to date. The single best way to protect your site from being hacked is by keeping up on WordPress patches. Recent versions of WordPress have automated patch updates, and will prompt an admin when an update is available. It’s important to pay attention to and apply these updates whenever you see them.
The second thing you should do as a WordPress administrator is to keep your use of third-party plug-ins to a minimum and keep up to date the plug-ins you do use.
As the core WordPress platform has received more security scrutiny, hackers have shifted their attention to vulnerabilities in popular plug-ins. Many of the attacks on WordPress these days come not through the core WordPress code but via plug-ins.
Each plug-in you install might add a vulnerability to your system, so be very selective in which ones you use. Try to favor plug-ins that have been around for some time and — ideally — ones that have a decent security track record.
Next, you should lock down admin access to WordPress. Pick strong passwords for any admin accounts, long passwords (ideally 20-plus character) randomly generated by and stored in a password manager. Your admin password should be unique; if you manage multiple WordPress sites, each one should have its own distinct password. Also, get an TLS certificate for your site and enable HTTPS, so you can make sure your password isn’t intercepted when you send it to your server.
You can also use the web server itself to add extra security around the admin account. First you can change your web server configuration file to restrict access to admin only from approved IPs. If IP-level restrictions aren’t possible you may want to consider using classic HTTP Basic Auth (the old password protection method built into web servers) to add an additional password to the admin section of your site. By doing this, you prevent hackers from accessing that section even if there is a vulnerability in core WordPress code.
Static Site Security
The fundamental security problem with WordPress is a flaw with all dynamic sites: if you accept any kind of input from the outside world and your page generates its own content on the fly, an attacker may be able to figure out a way to send input that exploits a weakness in the site’s programming.
Some people blame WordPress’s woes on the fact it’s written in PHP. While it can be more difficult to write secure code in PHP, it’s not impossible. And this problem is not exclusive to PHP. You’ll find it in any dynamically-generated website designed with any language.
The real question is, does your website really need to be dynamic?
In the early days of the web, websites were just a collection of static HTML files.Turns out a site full of static HTML files is rather difficult to hack. Since the website doesn’t accept any direct input, the hacker is left fishing for vulnerabilities in the web server software or some other service on the system.
Not only are static sites much harder to hack, they deliver content much faster! It takes way fewer server resources to serve a static HTML file than to execute code, communicate with a database, and generate a web page each time someone visits your site.
Why Not Both Static and Dynamic Content?
The whole point behind WordPress is that it makes it easy to build a modern website from your web browser without advanced HTML or web programming knowledge. So while you could certainly make hand-crafted, locally-sourced static HTML pages to serve to your visitors, you picked WordPress specifically because you didn’t have to do that!
The question, then, is how to accommodate both easy site updates and the security of static pages. Here’s your answer:
If you’re one of many who may use WordPress to create content, you may not need the site itself to be dynamically generated for every page load. In fact, you can find and follow many optimization guides that use WordPress plug-ins (or even external software like Varnish) to create a cache of your dynamically-generated pages to help reduce load on your web server.
And it turns out you can use some of these caching tools to convert your dynamic site into a collection of static pages while still keeping the backend of the site dynamic to make it easy to change content.
Some forethought and planning are needed, of course, before you convert your site to static files. First, you’ll have to determine whether this conversion will actually work for your type of website. Some sites lend much better to static files than others.
For instance many blogs only update a few times a day at most and otherwise don’t see many changes. In general, if a visitor that goes to your site in the morning would load the same exact page in the evening, it is probably a good candidate for static files. Conversely, if your site allows user logins and users see different content based on their preferences, it is probably not a great candidate for static files.
It should come as no surprise, then, that comments are one of the main features that can cause problems when you want a site to be static. By their very nature, user comments make a page dynamic.
The way comments are typically handled by WordPress requires you to allow visitors to submit comments, store them in the local database, and display them dynamically the next time the page loads. If you want static pages with comments as your only dynamic content, you could use one of the many third-party services like Disqus that manage online comments. These typically only require a bit of JavaScript embedded on your static page.
Other features on a site, such as ad generation or a search feature, may need to be dynamically loaded. Similar to comments, however, if you can serve this dynamic content via third-party JavaScript, you may still be able to have a site that looks and feels dynamic even though the core page is static HTML. Yours wouldn’t be the first site to rely on outside services to function “dynamically,” so there’s a good chance you could replace that local feature with third-party JavaScript.
Implementing Static Files
So, how do you convert a dynamic WordPress site to a series of static pages? In a number of ways.
If you are familiar with shell scripting you could set up a wget — mirror job that crawls your site and creates a local static mirror of content. Unfortunately the upkeep on this kind of script can be difficult, since it would end up crawling your entire site (possibly) multiple times per day, which would demand you having to seamlessly switch from the previous mirror archive to the latest one.
Fortunately, WordPress has a number of different plug-ins that allow you to create static pages out of your site. A quick search on “static” from the WordPress plug-in page will provide a selection of popular plug-ins that either use static files for caching or for security, including WP Static HTML Output, Simply Static, WP Fastest Cache, and WP Super Cache. Try out a few of these plugins to see which are compatible with your version of WordPress and works best for your particular site.
An advantage of static content is that even if your version of WordPress is out of date, you don’t have to worry as much about vulnerabilities, as long as you keep the dynamic parts of the site away from the public.
The downside of static content is that if you are running an old version of WordPress, some of these handy static plug-ins may not be available. That said, plug-ins that create static content have existed for quite some time. With a bit of research you should be able to find one that’s compatible with your version.
Each of these plug-ins operates in a slightly different way, so instead of walking through how each of them work, I’ll describe two different overall architectures you can adapt to your particular plugin.
The first architecture is simpler and assumes that you will host from a single server everything from the admin pages to the site content. In this case, you may just need to follow the installation steps for your plug-in. By installation’s end, your site will be solely and purely static files. In other cases, you may have to trace through how your plug-in generates static files and then, reconfigure your web server to point to these files directly.
Either way, the key is to make sure that once your website is serving static files, you make sure that the dynamic parts of your site are firewalled from the public. In particular, it’s critical that the admin section of your site is protected from the public via web server rules that either restrict which IPs can access it or require a password with HTTP Basic Authentication. Your plugin might take care this for you, or you may have to go into your web server config file and add it yourself.
The second architecture is a bit more involved but significantly more secure because it splits the static site and the WordPress installation into two separate servers. The idea here is that you can more easily lock down your WordPress site so that only you can access it, and then copy the static pages up to a second server that’s visible to the public.
This approach makes it even harder for a hacker to compromise WordPress, since it’s not even running on your public site. This approach also lends itself well to cloud providers that make it easy to serve static files.
The downside to this approach is that you will have to create some mechanism to synchronize the local static files on the WordPress server to the public site. That mechanism might be as simple as an rsync command that’s run periodically or as sophisticated as a custom plugin you write and incorporate into WordPress, so it triggers the synchronization automatically when the site is updated.
The Prospect of Going Static
I hope you’ve found this revert-to-static-for-security approach to WordPress helpful and a little different from the hardening advice you’ve seen in the past. While static WordPress sites may not be possible for everyone, I recommend you explore the possibility.
Because if you can figure out a way to make “going static” work for your WordPress site, it will result not only in a site that’s incredibly hard to attack, but also — as an added benefit — one that is significantly faster. Secure and fast? Who doesn’t want that?
About the blogger: Kyle Rankin is an award-winning IT journalist and author, who has written or contributed to more than a dozen books on open-source nuts and bolts, including the Knoppix Hacks series, The Official Ubuntu Server book, and DevOps Troubleshooting. His latest, Linux Hardening in Hostile Networks, has recently been published by Prentice Hall.
He is a columnist at Linux Journal magazine and speaks frequently on security and open-source software, including at O’Reilly Security Conference, BSidesLV, CactusCon, SCALE, OSCON, Linux World Expo, and Penguicon.
A specialist in Linux administration, automation and security, Kyle’s expertise as a senior systems administrator comes in handy at his regular 9-to-5 as Vice President of Engineering Operations at Final, Inc.
You can stay current with Kyle’s latest tips, tomes, presentations and Perl scripts at kylerank.in or @kylerankin.
Please feel free to share below any comments, questions or insights about your experience with using WordPress and/or securing your website. And if you found this blog useful, consider sharing it through social media.
WordPress docs in our library:
Install WordPress on Ubuntu 16.04
