WordPress security tips
Secure your blog
Using the most popular blogware also means using an attractive target for the bad guys out there. In fact, WordPress does not have the best security records which is, at least partially, a result of its popularity. Developing a successful method to exploit it, opens up a huge number of possibly vulnerable target sites and is therefore much more attractive than exploiting a software used by only a small number of sites. It is pretty much like using a very popular operating system (Windows) or browser (IE, Firefox) - the most popular ones always get the most attention not only by users but also by the bad guys.
That said, no reason for a panic attack. With a few simple rules, you can significantly decrease the chance that someone will break into your blog.
1. Secure your server and PHP installation
Obviously, this should always be the first step. If your server or PHP installation has major security holes, no WordPress-specific security tip can really help. However, this is out of scope for this article, because it is a very complex topic, one on which you could easily write a few hundred pages. Anyway, here are a few links you may want to read:
As it is always the case with restrictive settings, some of these tips may conflict with WordPress. For example, Some features of WordPress need a way to open remote files by means of fopen(), so setting allow_url_fopen to off can break these features. However, allow_url_fopen can be a security risk and the general opinion is that you should not enable it. If your PHP has curl support (which it should), then you should definitely disable allow_url_fopen, because WordPress can (and will) use curl if available.
2. Use strong passwords
Cannot be stressed often enough. Your birthday in the form of 20111432 is NOT a strong password. The name of your girlfriend or wife isn't either. In fact, no real word that exists in any language can be considered a strong password. If you really want to use an existing word, at least obfuscate its spelling (use random upper/lowercase letters or append/prepend some numbers for example).
Better: Use a random password, something like 8edfk223f. If you think, it is too hard to remember, use a trick that works well for many people: Combine the first letters of one of your favorite quotes, sentences, song texts or similar phrase that you'll always remember. Don't make it too short though, as a rule of thumb, a password should have at least 6 characters (but that's really the lowest limit, more is always better).
DON'T use the same password for everything (ftp login, database connection, blog admin login). DON'T use the password you've selected for your blog for anything else (i.e. your email account).
Here is a good article about choosing passwords and the do's and don'ts.
3. Basic WordPress-specific tips
Don't use the default table prefix name
By default, WP sets the table prefix to wp_ which you should change at installation time. The reason is simple: Most exploits trying to access your database will have to know (or guess) the table names. If you use the default prefix, the table names are easy to guess (e.g. wp_users). If you use a custom prefix, it will be MUCH harder to launch successful SQL injection attacks. Use something that is hard to guess like a random password consisting of numbers and letters.
It is possible to change the table prefix at a later time, but this is a bit more tricky. Here is a step-by-step HOWTO. Make sure to backup your site and database before.
By the way: This isn't a WordPress specific tip - it applies to all web applications using configurable database prefixes. Never use the default.
Fix file permissions
No matter what many guides will tell you about file permissions and about chmod'ding everything to 0777 (thus making the files writable by the web server process) - it's wrong. As a basic rule: Any accessible file or directory on your web server that does not HAVE to be writable should NOT be writable. PHP scripts in particular should be read-only, unless they HAVE to be writable (which they only need to be in a few rare cases). What needs to be writable is your uploads directory and possibly wp-content/plugins and wp-content/themes. Personally, I prefer to have nothing except uploads writable by the web server and install themes or plugins by uploading them via sftp. It certainly is a bit less user friendly, but also more secure.
Also, caching plugins usually need at least one writable directory for storing cached pages and objects. Where this directory has to be located depends on the caching plugin and is usually documented in the plugin's readme.
Keep your software up to date
This should be standard procedure anyway, but it seems that a lot of people simply don't care enough. Remember that running a site also means to take at least some responsibility, so don't act totally careless. Allowing the bad guys to hijack your site, because you failed to install important security fixes does not only hurt yourself - it might also hurt others, because such exploits are often used to install backdoors with the potential to infect your visitor's PCs on your site. The only thing you need in most cases is to keep your blog software and your plugins up to date. Unless you run your own dedicated server, you probably don't have to care about the system software - that's usually the job of the hosting provider.
Keeping WordPress and a few plugins up to date isn't a tough job and doesn't require a lot of your time. And it may save you from quite a few of troubles.
Secure the uploads directory
This is often overlooked and can be a potential threat. Configure your web server so that it will not execute PHP scripts from the default wp-content/uploads and any of its subfolders. By default, it most likely will execute PHP scripts from any subfolder inside your site root directory and this includes wp-content/uploads. While WordPress will not allow you or your users to upload PHP scripts by restricting uploads to a limited number of allowed file extensions, there is always the possibility of an unknown security hole which could open a way to upload scripts. You don't really want them to be executable, do you?
You can easily test this:
First, write a simple PHP script, something like:
<?php phpinfo(); ?>
Output of phpinfo()
Save it as test.php and upload the script to your wp-content/uploads directory, then use your browser and navigate to http://your.blog.site/wp-content/uploads/test.php. If your browser offers you to download the script as test.php, you should be safe. If you, however, see the output of the script and it looks like the screenshot here, you are not, because this output indicates that your server will actually execute scripts from the uploads folder.
Side note: Don't ever leave a script that executes phpinfo() on your server. The function is intended to be used for testing or debugging purposes only and disclosures a lot of things which nobody except you needs to know. If you need such a script to test your server setup, delete it as soon as it is no longer required.
