User:ringmaster/Hardening WordPress

This article is a ROUGH DRAFT. The author is still working on this document, so please do not edit this without the author's permission. The content within this article may not yet be verified or valid. This information is subject to change.


WordPress security matters a great deal to people who are deal with sensitive information and controversial topics, but should be one of the forefront issues for all bloggers and site administrators whether they are using WordPress or some other blogging tool.

WordPress developers take security very seriously. As with any other system, there are potential security issues that may arise. We will go through some common forms of vulnerabilities and how to deal with them.


This article is not the ultimate quick fix to your security concerns. This advice comes from a few people who know a bit about WordPress and security, and is by no means the definitive answer for all security woes. If you have specific security concerns, you should discuss them with people whom you trust to have sufficient knowledge of security or WordPress in relation to your specific concerns.

Not all of the variables mentioned in this guide can normally be controlled except by people who are running their own server. If you do not run your own server and you suspect that your server is not as secure as you would need it to be, you should contact your host or ISP and discuss with them what measures can be taken to improve the security of your site.

What is Security?

Fundamentally, security is not about perfectly uncrackable systems. Such a thing might well be impossible to find and/or maintain. A secure server protects the privacy, integrity, and availability of the resources under the control of the server's administrator. As such, you should find a host you can trust to provide you with the software tools and support to adequately meet your needs.

Qualities of a trusted host might include:

  • Readily discusses your security concerns and what security features and processes they offer with their hosting.
  • Provides the most recent stable versions of all server software.
  • Explains their choice of configuration for your server.
  • Provides reliable methods for backup or recovery.

Decide what security you need to apply to your server by determining what your server needs to run and what software and data needs to be secured.

Security Themes

Keep in mind some general ideas while considering security for each aspect of your server:

Limiting access 
Making smart choices that effectively lower the possible entry points available to a malicious person.
Defense in Depth 
If a weak point in your installation is found by a malicious person, your system should be configured to minimize the amount of damage that can be done once inside your system.
Keeping backups, knowing the state of your WordPress installation at regular time intervals, and documenting your modifications all help you understand your WordPress installation. Having a plan to maintain and recover your installation in the case of catastrophy can help you get back online faster in the case of a problem.

Common Vulnerabilities

This list is not complete because no list can be complete for the security needs of every computer. These items simply provide some general advice for keeping common aspects of your WordPress hosting secure.

Vulnerabilities on Your Computer

The computer you use to add new posts to WordPress is just as susceptable to malicious attack as any other computer on the internet. Software that compromises the security of your desktop system can become a gateway to malicious users to access your server.

Make sure the computers you use to post to WordPress are free of spyware, malware, adware, and virus infections. Run secure, stable versions of your applications.

For example, none of the other advice here is worthwhile if malicious software running on your desktop system transmits your server passwords to the enemy.

Vulnerabilities in WordPress Itself

WordPress could have vulnerabilies as a result of how the program is written that allow an attacker to compromise the security of your server. This can be done by requesting improperly handled querystrings, bad HTTP arguments, form input, etc. If WordPress does not handle the request properly, it could lead to a security issue.

There are two ways to deal with these potential problems:

Upgrade WordPress

The WordPress developers do not maintain security patches for older WordPress versions. Once a new version has been released or the vulnerability has been fixed then the information required to exploit the vulnerability is almost certainly in the public domain, making any old versions more open to attack by a 7-year-old with Google and a penchant for mischeif.

The latest stable version of WordPress is always available via the main WordPress website. The official stable release is not available from other sites -- do not install from a location that is not provided from the main WordPress site.

Use the WordPress Dashboard to keep informed about security issues in WordPress should they arise. By the time these issues appear on the Dashboard, a fix should be available for download. Read the entry in the Dashboard or the WordPress Developer Blog to determine what steps you must take to remain secure.

Report Bugs

If you find what you think is a bug, report it. See Submitting Bugs for more information and the process. You might have uncovered a vulnerability, or a bug that could lead to one.

If you think you have found a serious security flaw email m@wordpress.org with the information first. The extra time you save in not publicizing the flaw could buy the developers enough time to publish their patch and maintain security on many servers.

Server Vulnerabilities

The webserver running WordPress, the database with the WordPress data, PHP and any other scripting/programming language used for plugins or helper apps could have vulnerabilities. Therefore, make sure you are running secure, stable versions of your web server, database, scripting interpreter, or make sure you are using a trusted host that takes care of these things for you.

Disable those functions on your server that are unused. If a piece of software is not needed for your entire server, do not install it. Turn off services and daemons that you don't need. Regardless of whether these services are used by you, they can offer a weak spot that can be exploited.

For the services that must run to enable your server's functionality, be sure you have locked them down. If a program should not be initiated from the web, be sure that this program cannot be accessed by the user account allocated for your web server.

With whatever file transfer system you use for deploying files to your server, be sure to limit the access that the transferring account has. For example, an FTP login account used for uploading files to a public web site directory should not also have access to read or write files from anywhere else on the server. The permissions on the account should contain it within a designated area of operations.

Network Vulnerabilities

The Internet is an insecure place by nature.

The network on both ends -- the WordPress server side and the client network side -- should be trusted. That means updating firewall rules on your home router and being careful about what networks you work from. A busy Internet cafe where you are sending passwords in cleartext over an unencrypted wireless connection is not a trusted network . For example, if you blog by email, consider securing access to your blog over ssh tunnels. Your host should make ure their network is not poisoned by hackers, and you should do the same. Network vulnerabilities allow passwords to be intercepted via sniffers and other sorts of havoc (such as man-in-the-middle attacks) to happen.

If you use FTP to transfer files to your system, consider using SFTP instead. Unlike SFTP, plain FTP transmits your password in clear text, and can be easily intercepted! Also, any file transmissions are unencrypted, and if these files contain login information (such as an uploaded wp-config.php file), they could provide easy access to your server if intercepted. Other possibly more secure solutions than using vanilla FTP include SCP or tunneling FTP or rsync through SSH.

If you access the shell account to execute commands on your server remotely, you should consider using an SSH client. Like FTP, telnet sends and receives everything in clear text that can be intercepted at any point between the client and the server. Depending on your server configuration, using SSH may also enable secure tunneling. Secure tunneling allows a typically insecure protocol (like FTP) to operate through an encrypted transmission tunnel between your desktop and the server.


Some vulnerabilities can be avoided by good security habits. An important element of this is choosing a password.

Things to avoid when choosing a password:

  • Any permutation of your own real name or username.
  • A word from a dictionary, in any language.
  • Any numeric-only or alphabetic-only string of characters.

Your goal with your password is to make it as difficult as possible for a human to guess or for a computer to generate algorithmically. Using numbers and varying capitalization make it more difficult statistically to determine a password by brute force. Choosing a password that is hard to guess is particularly important if you do not rename the administrator account.

In that case half the puzzle is already solved for malicious users as they know what username will give them significant privileges to edit files and databases. The Automatic Password Generator can be helpful in generating reasonably complex passwords.

File Permissions

Some of WordPress' cool features come from allowing some files to be writable by web server. However, letting an application have write access to your files is a dangerous thing, particularly in a public environment. A malicious user could find a way to exploit poorly configured permissions, allowing them to alter files on your server and gain control over it.

It is best, from a security perspective, to lock down your file permissions as much as possible and to loosen those restrictions on the occasions that you need to allow write access, or to create special folders with more lax restrictions for the purpose of doing things like uploading images.

Here is one possible permission scheme.

All files should be owned by your user account, and should be writable by you. Any file that needs write access from WordPress should be group-owned by the user account used by the webserver.

  • / -- the root Wordpress directory: all files should be writable only by your user account.
    • EXCEPT .htaccess if you want WordPress to automatically generate rewrite rules for you
  • /wp-admin/ -- the WordPress administration area: all files should be writable only by your user account.
  • /wp-includes/ -- the bulk of WordPress application logic: all files should be writable only by your user account.
  • /wp-images/ -- image files used by WordPress: all files should be writable only by your user account.
  • /wp-content/ -- variable user-supplied content
    • /wp-content/themes/ -- theme files. If you want to use the built-in theme editor, all files need to be group writable. If you do not want to use the built-in theme editor, all files can be writable only by your user account
    • /wp-content/plugins/ -- plugin files: all files should be writable only by your user account.
    • other directories under /wp-content/ should be documented by whatever plugin / theme requires them. Permissions will vary.

Each file to which you allow writable access could provide an additional vector of entry for a malicious user. Keeping the number of files with write access to a minimum can reduce this risk.

Be especially careful with the .htaccess file, since it contains directives that control Apache's behavior, and could be used very easily to exploit your server. Recent updates in WordPress running on recent server software should make it unnecessary to leave this file writable except for the first time it is modified. Usually this is affected by adding new Pages to WordPress. If you set your .htaccess to read-only and are still able to create and view Pages via WordPress, then it's likely you do not need a persistently writeable .htaccess.

When in doubt, restrict permissions. You can always go back and increase permissions later, having only been temporarily inconvenienced. If someone gains access because the permissions were too loose, you could already have lost everything on that machine, maybe others.

Database Security

Like your server itself, your MySQL database is secured by usernames and passwords. Using a different username and password for your database than for your server or for your WordPress admin user might help reduce the damage caused if one type of account is compromised.

If you run multiple blogs on the same server, it is wise to consider keeping them in separate databases each managed by a different database login. This is best accomplished when performing the initial WordPress installation. This is a containment strategy: If an intruder successfully cracks one of WordPress installation, this makes it that much harder to alter your other blogs.

If you administer MySQL yourself, ensure that you understand your MySQL configuration and that unneeded features (such as accepting remote TCP connections) are disabled. See Secure MySQL Database Design for a nice introduction.

SQL Insertion Vulnerabilities

A common type of problem in relation to database security is SQL insertion. Unsecure scripts can allow malicious users to insert extra commands into a statement executed on your database. Using clever methods, these statements could add new users to your blog with high permissions, allowing them to make changes to your site or worse.

WordPress developers endeavor to eliminate these vulnerabilities in the WordPress source, but WordPress is not the only vector for these attacks. Be sure that the authors of other software and scripts that you run on your site have taken the steps necessary to reduce the likelihood of this kind of attack.

An extension module for Apache called mod_security is available to help reduce the risk of this type of attack. While modules such as these aren't foolproof, they do offer an extra layer of protection in the case that an undiscovered or unpatched vulnerability exists.

Securing wp-admin

First, we need to dispense with a major myth: A login page implies a secure administrative area. A login page does not mean a secure administrative area. Restricting access via a simple login is not the most secure method of locking users out of your WordPress administration area, because the connection between you and your admin area is still insecure. An attacker using a man-in-the-middle technique could poison your communications with your server, or could obtain from your own computer the cookies that WordPress uses to keep you logged in. An attacker that has this information would not know your password, but could craft a cookie that would convince WordPress that they were you.

The following discussion on securing the wp-admin area to enable access over SSL describes a number of ways of protecting your administration area. Methods like this provide additional layers of security for your login by encrypting the transmission between your browser and the server.


Plugins That Need Write Access

If a plugin wants write access to your WordPress files and directories, please read the code to make sure it is legit or check with someone you trust. Possible places to check are the Support Forums and IRC Channel.

Code Execution Plugins

Part of the goal of hardening WordPress is containing the damage done if there is a successful attack. Plugins that allow arbitrary PHP or other code to execute from entries in a database effectively magnify the possibility of damage in the event of a successful attack. As an example of how far-reaching this security issue is, assuming that a malicious user only has access to modify database entries, allowing anyone to execute code from the database, such a user could insert code that gives them much more control over the server, possibly capturing credentials of users with more permissions.

A way to avoid using such a plugin is to use custom page templates that call the function. Part of the security this affords is active only when you disallow file editing within WordPress.

Security Through Obscurity

Security through obscurity is typically thought to be an unsound primary strategy. However, there are areas in WordPress where obscuring a bit could help with security:

Do Not Advertise WordPress Versions

If you are running an old WordPress version with known vulnerabilities, it is unwise to display this information to the public. Why not simply hide the WordPress version entirely? Even if you update packages as quickly as you can, there will be lag between the version release and your deployment, potentially enough time for a malicious person to carry out an attack.

Editing out all the places where WordPress advertises its version string in your theme can be a pain, but it might be worth it to hunt down. WordPress typically stores the version number in a variable named $wp_version. Searching for this variable in your theme templates might help you remove the version notices. It will not be useful to remove the version number from the /wp-includes/version.php file, since you should upgrade to the most recent stable release rather than tweak this number.

It is still always best to make sure you are running the latest WordPress version.

Rename The Administrative Account

The security implication here is that an account is likely to exist in your WordPress installation that has administrative powers, and the username of this login account is well known, "admin". Changing the default admin username might help mitigate the possibility of an attacker using it to compromise your system.

The WordPress admin account is difficult to manage, since you cannot change the admin username via the user editor in WordPress, nor can you reduce the admin user permissions below the maximum. In the case that you want to change the administrator's account name (this is 'admin' in a default WordPress installation), you can do so by modifying the users table directly using a database editing tool such as phpMyAdmin, or by executing the following query directly in MySQL, replacing "new_username" with the username of your choice:

UPDATE wp_users SET user_login = 'new_username' WHERE user_login = 'admin';

This will only work if your username is currently the default value of "admin". But you can change your current username by changing the "admin" part of this query to your current username.

Rename The Administrative Account (for non techies)

If you want a simple way to fix the Admin account issue - direct from the Wordpress Admin panel... here goes. (you will "ideally" require 2 email addresses)

1) Create a new user with admin rights. Wordpress will insist that this new user has a different email address to the default 'admin' account. If you do not have 2 email addresses then create an imaginary one as follows wordpress@mydomain.com - where mydomain.com is the domain you are hosting your wordpress blog on.

2) Logout of the 'admin' account and then log back in as your new user.

3) Delete the 'admin' account. Because your new user also has admin rights, then Wordpress will allow this.

4) For those who didn't have 2 email addresses...

4a) Now change the email address for your new user. Since the original 'admin' was deleted, Wordpress will now allow you to use that email address for your new account.

4b) Now change the password for the new user - remember that you made-up an imaginary email address... well the password for the new user was sent to that address. Best to change that password now - just incase someone actually received that email!

Thats it! All done. Now you have an admin account without the default name 'admin'.

Data Backups

Backup your data regularly, including your MySQL databases (see Backing_Up_Your_Database). Data integrity is critical for trusted backups. Encrypting the backup, keeping an independent record of MD5 hashes for each backup file, and/or placing backups on read-only media (such as CD-R) increases your confidence that your data has not been tampered with.

A sound backup strategy could include keeping a set of regularly-timed snapshots of your entire WordPress installation (including WordPress core files and your database) in a trusted location. Imagine a site that makes weekly snapshots. Such a strategy means that if a site is compromised on May 1st but the compromise is not detected until May 12th, the site owner will have pre-compromise backups that can help in rebuilding the site and possibly even post-compromise backups which will aid in determining how the site was compromised.

You should consider keeping copies of your backups offline or on another server in the case of catastrophic server failure. Remember, security is not compromised only by intruders but by failed equipment. In this case, you would be able to restore your server with more ease than if the backups are located solely on your server.


This article is marked as in need of editing. You can help Codex by editing it.