Hardening WordPress « WordPress Codex

WordPress.org

Search the Codex Go

● Home

● Showcase

● Extend

● About

● Docs

● Blog

● Forums

● Hosting

● Download

Codex Codex tools: Log in / create

account

Hardening WordPress ● Home Page

● WordPress Lessons
Security is an interesting topic, with a lot of shades of gray. WordPress developers take security very seriously,
● Getting Started
but as with any other system, there are potential security issues that may arise and there are always trade offs
● Working with
when balancing security and convenience. We will go through some common things you can do to keep WordPress

http://codex.wordpress.org/Hardening_WordPress (1 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex
your WordPress installation secure.
● Design and Layout

● Advanced Topics
What is security? Fundamentally, security is not about perfectly uncrackable systems, which might well be
● Troubleshooting
impossible to find and/or maintain. Security has more to do with trust and responsiveness. For example, a
● Developer Docs
trusted host runs a stable, patched branch of their webserver (be it Apache, IIS, or whatever). They should tell
● About WordPress
you this, test their configuration themselves, and let you determine it for yourself. An untrusted host does not

apply patches when they are released and does not tell you what server versions they are running.
Codex Resources
● Community portal
Several themes run through this guide:
● Current events

1. Limiting access: Making smart choices that effectively lower the possible entry points available to a ● Recent changes

malicious person. ● Random page

2. Containment: If a weak point in your installation is found by a malicious person, your system should be ● Help

configured to minimize the amount of damage that can be done once inside your system.

3. Knowledge: Keeping backups, knowing the state of your WordPress installation at regular time

intervals, documenting your modifications all help you understand your WordPress installation.

Vulnerabilities on your computer

Make sure the computers you use to post to WordPress are
Contents
free of spyware, malware, adware, and virus infections;
[hide]
and are running secure, stable versions of your
1 Vulnerabilities on your computer
applications. For example, none of the following makes the ●

slightest difference if there is a keylogger on your PC. ● 2 Vulnerabilities in the WordPress package itself

● 3 Server vulnerabilities

Vulnerabilities in the WordPress ● 4 Network vulnerabilities

package itself ● 5 Passwords

WordPress could have vulnerabilities as a result of how the ● 6 File permissions

program is written that allow an attacker to pass HTTP ❍ 6.1 Regarding automatic upgrade

http://codex.wordpress.org/Hardening_WordPress (2 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex

arguments, bad URI strings, form input, etc, that could ● 7 Database security

cause Bad Things to happen. ● 8 Securing wp-admin

● 9 Securing wp-config.php

There are two ways to deal with this problem:

● 10 SSL Encryption Security

● 11 Plugins
1. Keep up to date with the latest WP version: The
❍ 11.1 Security Plugins
WordPress developers do not maintain security patches
❍ 11.2 Firewall Plugins
for older WordPress versions. Once a new version has
❍ 11.3 Plugins that need write access
been released or the vulnerability has been fixed then
❍ 11.4 Code execution plugins
the information required to exploit the vulnerability is
● 12 Security through obscurity
almost certainly in the public domain making any old
● 13 Data backups
versions more open to attack by a simple script kiddie.
● 14 Logging
If you are an administrator in charge of more than one
15 Monitoring
WordPress installation, consider checking out all copies
●

15.1 Monitoring your logs

of WordPress via Subversion Installing/ ❍

Updating_WordPress_with_Subversion, and using an ❍ 15.2 Monitoring your files for changes

accompanying script to keep all checkouts up to date ❍ 15.3 Monitoring your web server externally for malware and changes

en mass [[1]]. ● 16 Resources

2. Report bugs: If you find what you think is a bug,

report it -- See Submitting_Bugs. You might have uncovered a vulnerability, or a bug that could lead to one. If

you think you have found a serious security flaw see the Security FAQ for information on how to report the flaw.

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.

http://codex.wordpress.org/Hardening_WordPress (3 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex

It should also be mentioned that if you're on a shared server (one that hosts other people besides yourself)

if someone else is compromised, then it's very likely you could be compromised too even if you follow everything

in this guide. Be sure to ask your web host what security precautions they take.

Network vulnerabilities
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 (The following article describing how to secure your email when using a wireless connection in

a public place can be extended as a way of securely accessing you blog over ssh tunnels). Your host should

be making sure that 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.

Passwords
Some vulnerabilities can be avoided by good security habits. An important element of this are passwords: do not

use your own name for your password, do not use a dictionary word (from any language) for your password, do

not use a 4 character string of numbers as your password. Your goal with your password is to make the search

space as large as possible, so using numbers and varying capitalization all make it more difficult, statistically,

to brute force a password. This 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.

http://codex.wordpress.org/Hardening_WordPress (4 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex

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: intended by Developers to be completely writable by all (owner/

user, group, and public).

❍ /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 may vary.

http://codex.wordpress.org/Hardening_WordPress (5 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex

● If you have shell access to your server, you can change file permissions recursively with the following command:

For Directories

find [your path here] -type d -exec chmod 755 {} \;

For Files

find [your path here] -type f -exec chmod 644 {} \;

You have to omit to use this command for /wp-includes/.

Note that if you are on a shared-server the permissions of your wp-config.php should be 750. It

means that no other user will be able to read your database username and password. If you have FTP

or shell access, do the following:

chmod 750 wp-config.php

Regarding automatic upgrade

Beginning with Version 2.7 WordPress can perform an automatic upgrade. As such, all file operations are

performed as the user that owns the files, not as the web server's user. All files are set to 0644 and all directories

are set to 0755, and writable by only the user and readable by everyone else, including the web server.

Database security
If you run multiple blogs on the same server, it is wise to consider keeping them in separate databases

each managed by a different user. 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.

http://codex.wordpress.org/Hardening_WordPress (6 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex

Securing wp-admin
You can greatly enhance the security of your blog by adding additional access control to your /wp-admin/ folder

using the AskApache Password Protection plugin. This plugin also secures your /wp-login.php file, and all files

in your /wp-includes/ and /wp-content/ folders.

Caution: Installing the AskApache Password Protection plugin may lock you out of your WordPress

Admin panel and return an error 500 when you attempt to go to yourdomain.com/wp-admin. You

might try installing the plugin on a test site first, as your server or other configurations may

cause issues. To uninstall the plugin, first delete the new .htaccess file that appears inside your

wp-admin folder. Then log in to your site and deactivate (and then possibly delete) the plugin. See

the comments under the author's plugin home page to read other users' experiences with this plugin.

Adding server-side password protection to /wp-admin/ adds a 2nd layer of protection around your blog's admin

area, login, and files. This forces an attacker or bot to attack this 2nd layer of protection instead of your actual

admin files. Most of the time WordPress attacks are carried out autonomously by a malicious software bot.

The most common attacks against a WordPress blog usually fall into 2 categories.

1. Sending specially-crafted HTTP requests to your server with specific exploit payloads for specific vulnerabilities.

These include old/outdated plugins and software.

2. Attempting to gain access to your blog by using "brute-force" password guessing.

By adding a 2nd layer of protection around these important files you force the attackers to have to break

through that before they can even attempt to attack your main /wp-admin/. This protection uses Basic

HTTP Authentication, the password is passed over the network uuencoded as plain text, not encrypted. The

main benefit of this protection is in denying access to your servers files and alerting you to an attack against

your blog before the attack reaches your /wp-admin/ doorstep.

http://codex.wordpress.org/Hardening_WordPress (7 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex

The ultimate implementation of this "2nd layer" password protection is to require an HTTPS SSL encrypted

connection for your /wp-admin/ directory, so that all communications and sensitive data is encrypted.

Securing wp-config.php
You can move the wp-config.php file to the directory above your WordPress install. This means for a site installed

in the root of your webspace, you can store wp-config.php outside the web-root folder. Note that wp-config.

php can be stored ONE directory level above the WordPress (where wp-includes resides) installation. Also, make

sure that only you (and the web server) can read this file (it generally means a 750 permission).

SSL Encryption Security

You can secure and encrypt all of your communication and important WordPress cookies using the Admin-SSL

plugin. Works with Private and Shared SSL.

Plugins
First of all, make sure your plugins are always updated. Also, if you are not using a specific plugin, make sure

to delete it from the system.

Security Plugins
The WP Security Scan Plugin can be downloaded at WP Security Scan. While this helps tremendously to protect

your WordPress installation, you still need to maintain good passwords, check plugins and themes before

installing them, and keep good backups of your files and database in the event that you do get hacked.

Firewall Plugins
There are a few plugins that purport to screen out suspicious-looking requests based on rule databases and/

or whitelists. BlogSecurity's WPIDS plugin installs PHPIDS, a generic security layer for PHP applications,

while WordPress Firewall uses some WordPress-tuned pre-configured rules along with a whitelist to screen

http://codex.wordpress.org/Hardening_WordPress (8 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex

out attacks without much configuration.

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

As we said, part of the goal of hardening WordPress is containing the damage done if there is a successful

attack. Plugins which 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.

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 information might help with security:

1. Rename the administrative account: On a new install you can simply create a new Administrative account

and delete the default admin account. On an existing WordPress install you may rename the existing account in

the MySQL command-line client with a command like update tableprefix_users set user_login='newuser'

where user_login='admin';, or by using a MySQL frontend like phpMyAdmin.

2. Change the table_prefix: Many published WordPress-specific SQL-injection attacks make the assumption that

the table_prefix is "wp_," the default. Changing this probably amounts to security by obscurity, but will block at

least some SQL-injection attacks. Plugins to do this automatically can be found at WP Prefix Table Changer

and WordPress Table Rename. Manual instructions are also available.

3. Do not advertise the WordPress version you are running: If you are running an old WordPress version

http://codex.wordpress.org/Hardening_WordPress (9 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex

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.

However, editing out all the places where WordPress advertises its version string (e.g., <meta

name="generator" content="WordPress 2.9" /> in every page) in your theme can be a pain. It is still best to

make sure you are running the latest WordPress version. An easier way to do this is with the Replace WP-

Version, Secure WordPress, or WP-Secure Remove Wordpress Version plugins. If you want to remove this

line without a plugin, you can simply add <?php remove_action('wp_head', 'wp_generator'); ?> to your

theme's function.php file. Please Note: This does NOT prevent WordPress exploits being attempted against

your site, as modern worms ignore the version in their exploit attempts (Note: There are many ways of

determining the WordPress version a site uses, the "generator" is a rarely used method.)

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.

Logging
It is possible to log all $POST variables sent to WordPress. Standard Apache logs do not offer much help with

dealing with security forensics.

http://codex.wordpress.org/Hardening_WordPress (10 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex

● Mod_Security - Logs and Prevents using Apache

● Plugin that logs using WP

Monitoring
Sometimes prevention is not enough and you may still be hacked. That's why intrusion detection/monitoring is

very important. It will allow you to react faster, find out what happened and recover your blog back in place.

Monitoring your logs

If you are on a private server (where you have admin access), you have to watch your logs to detect

password guessing attempts, web attacks, etc. A good open source solution to monitor your logs in real time

and block the attacker is OSSEC.

Monitoring your files for changes

When an attack happens, it always leave traces. Either on the logs or on the file system (new files, files

modified, etc). If you are using http://www.ossec.net OSSEC] that we recommended above, it will monitor your

files and alert when they change as well. You can also use the open sourceTripwire to alert on file changes.

Monitoring your web server externally for malware and changes

If the attacker tries to deface your site or add malware, you can also detect these changes by using a web-

based integrity monitor solution.

Resources
● WordPress Security Links and Plugins

● 20 Wordpress Security Plug-ins And Tips To keep Hackers Away

● Security FAQ

http://codex.wordpress.org/Hardening_WordPress (11 of 12) [4/27/2010 8:17:26 AM]

Hardening WordPress « WordPress Codex

Categories: Advanced Topics | WordPress Development

Report a Site Bug | Privacy | GPL | Browse Happy | WordPress Updates

Code is Poetry

RSS

http://codex.wordpress.org/Hardening_WordPress (12 of 12) [4/27/2010 8:17:26 AM]