WordPress is quickly becoming one of the most used website management(CMS) software options. I frequently notice various security issues on many WordPress based sites. This tutorial/article is designed to assist users with hardening their WordPress installation. WordPress takes security very seriously, and by default has some excellent security practices. However, there are a lot more steps that can be taken, by the end user, to make their site even more secure, and specifically tailor the security to their install.
Basic Security Ideals
The most common misconception about website security is that once certain steps are completed that your site is secure. This is incorrect. Maintaining an entirely secure site while potentially possible is highly improbable and would be a logistical nightmare to support. The most important things to keep in mind is your job keeping your site secure is never done. You will constantly need to be on the lookout for new methods of security, and new hacks, in order to better protect yourself.
A couple basic security steps that many fail to take, and are easy to implement are:
1: Secure passwords.
2: Frequent, offsite backups.
3: Keep your install up-to-date with the most recent stable build.
1: Secure Passwords
Many users fail to keep their passwords secure. This can be a result of several things:
- Any password that contains a single word that is found in the dictionary is extremely vulnerable.
- Any password using all letters or all numbers is extremely vulnerable.
- Any password using less than 8 digits is extremely vulnerable.
- Any password using less than 12 digits is weak.
- Any password containing personal information is weak.(Ex: Smith4501 - Last name + house number)
- Any password used at more than one location or more than one site is slightly vulnerable.(Your basing the security of your site on the security practices of someone else)
- Any password saved on your computer or written on a paper found near your computer is slightly vulnerable.
Best password practices are as follows:
- A password containing 16+ digits.
- A password containing lower case letters and upper case letters.
- A password containing numbers.
- A password containing special symbols.
- A randomized password.
- A password unique to this site or application.
A secure password should be similar to the following:
X91gt$1d.#4s9J1k(0sx. The password is 20 digits long, contains caps and lower case, contains numbers, contains special characters and is unique to this site.
2: Frequent, offsite backups
Another major mistake people will make is doing very infrequent backups, or storing the backups in the same location as their site. This is extremely hazardous. If a hacker breaks into your site, they will erase the backups, or corrupt the backups as well as the main site. Second, if your server were to be damaged or hard drive were to fail, you would lose the backups and the main copy.
The best practices for data backup are to perform regularly timed backups that are tailored to your site. For example, if you have new data being written to your site on a very regular basis, such as a highly used message board, or a busy web shop, it would be recommended to perform hourly backups. This can get quite costly to maintain, so one easy way to combat this is to run the hourly backups on your server, store them locally until they are batched together and uploaded as one compressed file to your backup service, once every 24 hours. This allows you to maintain the frequent backups, in the event something minor happened that required a rollback to an early point, while maintaining safe and secure backups of major data.
Another highly important step with this is to audit your data, AFTER the backup is complete to your offsite location. A company I worked with failed to audit our data on a regular basis, and when one of our drives failed, we found out the backups for the past several weeks had been corrupted, as a result of the drive failing. By auditing our data frequently, we could have caught on to the drive failure before it occurred, AND would have been able to better secure our data.
Keep in mind, this frequent of a backup system is overkill for simplistic sites that are updated infrequently, or do not process/store customer/user data. You should speak with a security/server admin to come up with the best backup plan for your site.
3: Keep your install up-to-date
It never ceases to amaze me how many sites LABEL what version they are running at the bottom of their pages, then fail to keep it up-to-date. Most web hosts offer the ability to keep your sites up-to-date with the most recent stable build, with the click of one button(using cPanel or another webmin alternative). In the case of WordPress, they do a fantastic job of staying current on security threats, and releasing patches. You should take complete advantage of this, and keep your site up-to-date. This is a simple step that a lot of site owners fail to complete.
Every one of these security practices should be applied to any type of site you make and do apply to WordPress sites.
Be smart and limit access to any part of the site, or any directories on your site that are not absolutely critical to your sites function. Doing so limits entry points for attackers.
Configure your server to minimize the access an attacker can have. If you run your own server, create separate users for everything, and limit the access each user has. Restrict access to a users own directories only. Use separate usernames and passwords for your databases. Limit database users to their own database only.
Preparation and Knowledge
As before, stay current on vulnerabilities and read the patch notes for each version you install. Keep yourself informed. Never assume somebody else will keep themselves informed for you. Build a worst case plan: In the event you are hacked and your site is entirely compromised, what do you do? Have a plan for it, or any other significant possibility. Have everything ready that you need to carry it out. If your running a major site, rehearse your plan every now and then.
Vulnerabilities on Your Computer
Make sure your computer is up-to-date on security software, and run frequent scans. Anything you upload to your server could potentially be infected, and cause harm to your site. No amount of security on your website can protect you from your own stupidity. Make sure you are safe and make sure your server is safe. Remember, your server is not the only thing that needs to be up-to-date on its software. Windows on your computer has security vulnerabilities. In many cases it is easier for an attacker to get into your computer and then gain access to your server using your own computer than it is to break into the server itself.
This is to re-iterate what was said several times above. KEEP WORDPRESS UP-TO-DATE! WordPress will fix known vulnerabilities in their software quickly and frequently.
As mentioned above, there is more to keeping your site secure than just keeping WordPress secure. Having vulnerabilities in your web server software can be more damaging than having an issue with WordPress. Keeping your web server secure and hardened is extremely important, and often starts with keeping it up-to-date(starting to see a pattern here?).
There are many different brands/types of web servers to covering anything of any substance here would ultimately be a waste of me typing it and you reading it. If you are maintaining your own web server, search Google for ways of securing your specific software.
Lastly, just because you are using a web host that manages and takes care of that for you, doesn't mean its secure. Talk to them and ask them what security practices they implement and what precautions they take. Speak to a securities expert and make sure their practices are adequate if you are not sure yourself.
This is starting to get into the more nitty gritty type stuff that is mainly for people admining their own server. If this is not you, skip this step. If this is you, there are several network related steps you should be taking. First, make sure all of your firewall settings and rules are up-to-date(heh). If you are running a software firewall, make sure the software is up-to-date(!).
On your own computer, make sure you have a firewall, and that it has the settings and rules setup correctly. Make sure its software is up-to-date(getting tired of me telling you that yet?). If you are on a wireless network, make sure you have monitoring software to see who else is connected(just because your wireless network has a password does not mean its secure). NEVER use a public network to login to your server. NEVER use a 'secure' public network to login to your server(Read: Starbucks, net cafe's, etc).
Whenever connecting or uploading files to your server, use SFTP(Secure FTP). The majority of webhosts offer SFTP. If they don't, I suggest switching hosts. If you are unsure, ask them. SFTP is the equivalent of HTTPS for file transfers. Google SFTP for more information if you are interested.
Now were finally getting back to WordPress specific(although these can and should be applied to any other type of site) security adjustments. WordPress allows several fancy features such as the ability to write to its own files. This should not be allowed. Its fancy. Its shiny. Its insecure. In the rare instance where this is necessary, re-adjust your file permissions to allow writing temporarily, then reset it after.
Any files for your installation of WordPress should only be accessible and writable for one user on your server. Do not use global usernames. Any files than need write access from WordPress should be group-owned by the user account used by the web server.
You can setup specific directories to require an additional password, requested and maintained by the server via
.htaccess. This is HIGHLY recommended for any areas of the site dealing with administration(Ex: /wp-admin/).
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.
The WordPress administration area: all files should be writable only by your user account.
The bulk of WordPress application logic: all files should be writable only by your user account.
User-supplied content: intended to be completely writable by all users (owner/user, group, and public).
Within /wp-content/ you will find:
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.
Plugin files: all files should be writable only by your user account.
Any files or directories that do not require access by the user, or do not require write access should be CHMODed to disallow access.
Automatic Updates File Permissions
When you tell WordPress to perform an automatic update, 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.
As mentioned above, keeping wp-admin secure is very important. We already covered adding a second password in the .htaccess file for wp-admin. This may break the functionality of some admin functions such as the AJAX handler at wp-admin/admin-ajax.php. There are various guides out there on how to fix these issues, if they present for you. The best practice for securing this directory is to also use SSL for the entire admin system.
A second layer of protection can be added where scripts are generally not intended to be accessed by any user. One way to do that is to block those scripts using mod_rewrite in the .htaccess file.
# Block the include-only files.
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
Note that this won't work well on Multisite, as
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] would prevent the
ms-files.php file from generating images. Omitting that line will allow the code to work, but offers less security.
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.
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 400 or 440 permission).
If you use a server with
.htaccess, you can put this in that file (at the very top) to deny access to anyone surfing for it:
deny from all
The last topic I will cover is using security plugins. Some of these plugins are not updated frequently, or cause excessive bugs with site functionality. That being said, some security plugins actually do work, and are updated frequently.
The best one I have found for this is Bulletproof Security. Please note that the Bulletproof Security software requires the use of Linux specific Apache
.htaccess files. If you do not use Apache or are on a different server type, this will not work for you.
Its a lot of work! Hopefully there are some new ideas here and information that will assist people with security on their sites. Should anyone have questions on any part of this, please do not hesitate to ask here or in a PM. I would be glad to help. Good luck and keep yourselves safe!
This page was published on It was last revised on