WordPress is a very common and popular content management system used to develop everything from blogs to ecommerce sites. Unfortunately, it’s also a very common target for attacks and other abuse. Securing your WordPress site from attackers takes a bit of work and research but will save you time and money in the long term.
In this article, we’ll explore several ways to help protect your WordPress site and maintain solid security practices so you can worry less and focus more on producing great content and marketing your new site.
Always use good passwords and keep them safe
One of the most important ways to keep your WordPress site secure and help avoid unauthorized access is to always use good passwords for FTP and your WordPress admin area. It may be inconvenient, but cleaning up a hacked WordPress site that was exploited using insecure passwords will be even more of a nightmare to deal with.
A suitable and strong password will be one that cannot be brute forced using dictionary words or words from common password lists. Your cat may be the most awesome thing in the world, but using “fluffy” as your password is just asking for trouble. Likewise, a common list password such as “12345” will do a very poor job at keeping intruders out no matter how many levels of security your server has against bruteforcing (aside from blocking everyone but you in the firewall) or any security-related plugins you may have installed.
Instead, choose a password comprised of a random mix of numbers, uppercase letters, lowercase letters, and preferably a character. We recommend using RANDOM.ORG’s random password generator. The generated passwords by default are pretty secure but you can increase their security even further by adding in a “#” or any other character supported in passwords by your application.
The first step to secure passwords is choosing the right one, but you also need to keep it safe.
Never reuse the same password, even if the password is secure. The password you use for your WordPress admin should not be used to access your online banking account, for instance. It’s understandable that using a different secure password for every service is very inconvenient but if one of those passwords gets stolen or otherwise compromised, you only have that one service to worry about rather than all of them.
If you need to maintain a list of passwords don’t keep them in an unencrypted plaintext file on your computer. Use an encrypted container like Truecrypt or dmcrypt to store your password lists or one of the several browser extensions such as LastPass.
Adhere to correct file and directory permission levels
The permissions for files, such as .php, .txt, .html, and so on should not be any higher than 644 unless absolutely necessary. The permissions for directories should also never exceed 755 unless absolutely necessary. 644 means the owner (typically the account WordPress is installed under) can read and modify the file but everyone else can only read it. 755 means the owner can read, write, and execute the file but everyone else can only read and execute it.
The more sensitive files, such as wp-config.php, can be set to 700 for even better security.
Notice we say “absolutely necessary” when referring to situations when permissions can be more permissive? Only go that route when there is absolutely, positively no other option for doing what you need to do – and only after pursuing every other viable option down to rethinking how you’re handling file reading and writing in WordPress. Permissions should not be taken lightly as a file or directory allowing anyone other than the owner to write or execute it opens up a greater possibility remote attackers can exploit the file or directory contents.
You may change the permissions of files and directories in the shell by using the “chmod” tool or modifying them through your control panel file manager (if you have one installed on your server) or through FTP.
Keep WordPress core and all plugins up-to-date
WordPress sites are most commonly compromised due to security holes in the core application or installed plugins. The WordPress team and authors of actively-maintained plugins are excellent at updating their applications when a security hole is found and reported, therefore it is very important to check daily for any updates that may be available.
This applies to not only activated plugins but deactivated plugins as well. You should never allow insecure code to reside anywhere in the webroot (typically public_html or /var/www/html). Even if a plugin is deactivated, attackers may still be able to take advantage of any security holes exploitable in conjunction with WordPress core files.
WordPress also provides an auto-update feature which can be used where possible to help keep your core files and plugins up-to-date if it’s not feasible to check and update manually on a regular basis.
Only install the plugins you need
The fewer plugins you have installed the easier it will be to keep them audited and up-to-date. This is especially true if you manage many WordPress sites. While installing a plugin can greatly reduce development time, it can also introduce security holes in situations where it’s unnecessary to do so. If you’re attempting to provide layout functionality to the front of your WordPress site, combine CSS, jQuery, and WordPress’ template tags in your theme before opting for a plugin.
Regularly audit plugins for author activity
When a plugin is actively maintained, the author provides regular updates for features, bugs, and security holes as well as often featuring an active user base with recent comments on the plugin’s WordPress.org page. An abandoned plugin – one that is not being actively maintained – may contain security holes that are unpatched with no plans to patch them. Sometimes a plugin may be quite active with regular updates and recent customer reviews but quietly slip into abandonment over time.
This is why it’s important to avoid abandoned plugins in the first place and regularly audit any plugins you have installed for signs the author has stopped maintaining them. For instance, if a plugin hasn’t seen any updates in more than a year and the author no longer participates in discussions regarding their plugin on the WordPress forums, there’s a good chance they have ceased development and maintenance on it.
Use WordPress’ template tags instead of raw database queries
WordPress provides a very flexible and powerful way to access your site’s database using template tags so there should be no need to use raw MySQL queries in your theme files. The WordPress Codex contains extensive documentation on these template tags along with example usage, and help is readily available through their forums.
Using raw MySQL queries in your template files can open your site to a number of problems, including SQL injection. WordPress’ template tags abstract direct database access away from your theme files to help protect against malicious behavior and make developing your site easier.
Use security plugins and/or mod_security
One extra layer of protection in addition to keeping your WordPress core and plugins up-to-date, maintaining good password practices, using appropriate file / directory permissions, and developing your themes using template tags is installing a security plugin or mod_security. Additionally, there are other types of 3rd-party WAF (web application firewall) services to consider.
There are a number of security plugins available for your WordPress site and one big advantage of using a plugin is it only affects the site you install it on rather than your entire server. What works for one site may not work for all. Security plugins typically work by modifying .htaccess to block known bots, block potentially malicious query strings, restrict access to wp-login.php, and so on. A couple of examples are Securi and Wordfence.
Mod_security is another popular method used to protect WordPress sites. It’s applied server-level as a module compiled into Apache. Mod_security works by analyzing each Apache request against a set of rules defining what to look for and what to do with the request if a match occurs. It works best to protect against malware when mod_security is allowed to analyze the request body, however a disadvantage here is the cost in resources. A server with just a few sites using a small set of intelligent mod_security rules would be well-protected and experience very little performance degradation while a server hosting many sites may take a fairly significant performance hit.
If performance is a concern when using mod_security, keep SecRequestBodyAccess disabled and use an efficient rule set that blocks brute force attempts on wp-login.php, common patterns used in query strings to compromise files (i.e. directory traversal), and POST attempts on files that a site visitor should never be POSTing to.
Mod_security is a very complex and powerful module which we’ll touch upon more in a future blog post.
There are also a number of 3rd-party WAF services available that work a bit differently than installing a plugin or mod_security. These services typically require routing your traffic through their network, which is analyzed for malicious activity before being passed on to your site. If you’re familiar with Cloudflare or any of the other 3rd-party DDoS protection services, think of a WAF as acting in the same manner to protect your site against malware and hacking; it’s effectively a firewall standing between your site and traffic to your site.
In summary:
- Use secure passwords that can’t be brute forced and keep them safe.
- Maintain permissions no greater than 644 for files and 755 for directories.
- Keep WordPress core and all plugins, both activated and deactivated, up-to-date. Upgrade them as soon as the update is available.
- Try to maintain a minimal number of plugins and only use plugins that are actively updated by the author.
- Use WordPress’ template tags to build your theme and never use raw database queries.
- Consider using a security plugin, mod_security, or a good 3rd-party WAF to further secure your site.