In the third and last part of this series we will explore additional ways of securing our self-hosted WordPress installation. This includes some security tips regarding the database, plugins and themes, and maintaining WordPress up to date.

Move wp-content out of its default location

Since version 2.6 of WordPress you can move the wp-content directory out of its default location. The objective is, as we did with the wp-config.php file in the second installment of this series, Securing a new WordPress installation, part 2: Login process and Admin area, to prevent attacks by obscuring the location of the files. Note that in this case, as the contents of the directory must be public (that is, accessible from the web server) we can’t move the wp-content directory outside the web root as we did with the wp-config.php file. But we can change it’s name/location, which is good enough to discourage a bit more a possible intruder.

Keep in mind that this can easily present some problems with badly programmed plugins that use hard-coded directory routes, which nobody should be using anyway but, hey, you never know.

The process of moving wp-content is quite simple and involves creating (modifying, actually) the WP_CONTENT_DIR and WP_CONTENT_URL variables in wp-config.php. You can see the details at the WordPress Codex Page.

Database security

It serves no purpose to have an tightly secured WordPress environment if the database is not also protected. WordPress stores all its data, ranging from post contents to the blog configuration, including users information and passwords, in a database. Therefore, if a malicious user gains access to the database, he is basically allowed to do whatever he wants with the site, even without the need of accessing WordPress itself.

The first conclusion is that the database used by WordPress to store its data needs a non-obvious username and a secure password. The second and most important security tip for the database system is not to use the default prefix for the tables that WordPress creates, which is wp_. A malicious user may try to pass a SQL query on to WordPress trying to obtain or modify some the site’s stored information due to a bad sanitation of the input. By changing the prefix, we change the name of the tables that WordPress is using, making extremely difficult to develop an attack of this kind.

Changing the prefix is trivial on a new install: during WordPress’ initial configuration screen you will be asked for the new table prefix. Just enter a random combination of letters and numbers and you are good to go.

If the site is already online, the process is a bit trickier. It involves renaming the tables inside the database, and then change the configuration accordingly in wp-config.php so that WordPress acknowledges the changes. You can see the whole process, along with some extra tips, on Sherif Elsisi’s 6 Simple Steps to Change Your Table Prefix in WordPress.

Remember, shit happens

As they say, if something can go wrong, it will. Consequently, another important step in preventing surprises and catastrophes is making frequent backups. Thereby, if your site is hacked or lost because of a hardware or software problem, you can have your site up and running again in no time.

Unfortunately, making a backup of WordPress site is not as simple as backing up the files contained in the WordPress installation. Almost everything of value except plugins, themes and modifications to the software is not there, it’s stored in the database. So, in addition to backing up your files, you must do regular backups of the database contents. There are several plugins that can help you with this, you can find the list in the WordPress site under WordPress Backup Plugins.

One feature that I particularly appreciate is to have the backup sent automatically to my email account. For small sites, the size of the backup coupled with the almost infinite capacity of GMail allows for storage of an automatic daily backup without problems. You can easily configure a GMail filter so the daily backup avoids the Inbox altogether. There are several plugins like WordPress Database Backup that offer this daily backup to email feature.

There’s lots of additional information about WordPress and backups in the WordPress Codex.

Updating WordPress

If your WordPress installation is not up to date with the latest version, you really need to update it. Now.

Automattic releases major WordPress updates every 3 or 4 months, and minor updates usually once a month. All of them usually include lots of bug fixes and security updates, so you really need to maintain you WordPress installation up to date if you want to be protected against malware and malicious users.

There is an official release notification mailing list where you can subscribe so the WordPress developers send you a friendly message whenever a new stable release is published.

Install plugins and themes from reputable sources

There’s a risk present when installing plugins and themes from sites other than the official WordPress Plugins and Themes repositories.

At best, plugins and themes downloaded from shoddy places can insert unwanted URLs building incoming links in an attempt of elevating PageRank for the destination URL. Because these links are often hidden, such behavior can provoke a decline in the ranking of your own site in search engines.

At worst, they can include malicious code in an attempt to regain information about the host itself, as a first step towards a full hacking of the site, or even regain sensible information about your site’s visitors.

Therefore it’s recommended to install plugins and themes only from the WordPress repositories itself or from very reputable authors and sources.

Information shown to Search Engines

There are many ways in which Google and other search engines can be used (or abused) to find out information about sites that are disclosing unnecessary information or are vulnerable. Luckily for us webmasters, it’s easy to control what information Google’s spiders recover from our website using the file robots.txt.

The robots.txt file is the basis for the Robots exclusion standard, which is only advisory but is used by all major search engines. This file basically contains a list of locations in the web site that the web spider is not allowed to crawl.

This is the example robots.txt file as show in the WordPress Search Engine Optimization Codex section. It’s wise to use it not only because of the security implications, it’s also good for SEO purposes, like avoiding being penalized by search engines because feeds and search results with duplicated content are being indexed by them.

Sitemap: http://www.example.com/sitemap.xml

# Google Image
User-agent: Googlebot-Image
Disallow:
Allow: /*

# Google AdSense
User-agent: Mediapartners-Google*
Disallow:

# digg mirror
User-agent: duggmirror
Disallow: /

# global
User-agent: *
Disallow: /cgi-bin/
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/cache/
Disallow: /wp-content/themes/
Disallow: /trackback/
Disallow: /feed/
Disallow: /comments/
Disallow: /category/*/*
Disallow: */trackback/
Disallow: */feed/
Disallow: */comments/
Disallow: /*?
Allow: /wp-content/uploads/

There are other restrictions you can add but you must be careful as the wrong settings on this file can hurt SEO quite easily.

Additional information and other interesting tips

You can find general information about security and hardening WordPress on the WordPress Codex. It’s an excellent resource, created by the WordPress’ developers themselves.

One very interesting book is WordPress 3 Ultimate Security by Olly Connelly (Packt Publishing, 2011). The book presents lots of security tips for novice and intermediate WordPress users, ranging from basic Windows and Internet security for safe browsing to advanced WordPress security tips, like some of the ones we explore in this series.

In conclusion, implementing these tips on your WordPress blog will improve its security and hopefully drive hackers away to more feasible targets.