WordPress Site Security Guide – Part 1

Establishing and maintaining the security of our WordPress websites is ultimately our own responsibility. Even if we depend on our hosting service or developer to decide what needs to be done and how to best do it, we still need to take responsibility for ensuring it happens.

Fortunately, the implementation of most security fixes is relatively uncomplicated, often involving simply checking a box, inserting a code snippet or editing a line in a file. This WordPress Site Security Guide is intended to help site owners with only basic editing skills learn to check their own site’s security, and in most cases, fix a potential issue.

First and foremost, the cardinal rule should be to always backup before making any changes. That doesn’t mean just your site’s database and files when updating the WP core, theme or plugins – it also means any individual files you might be editing, such as the .htaccess, wp-config.php or php.ini files. It’s too easy to make a tiny error that could take your site down ““ a recent backup of the file can turn a frown into a smile.

Here are over 3 dozen items you should check on your WP site, along with our recommended actions. Some are critical, some are just precautions that will reduce your risk slightly. And if you know your way around your site’s backend and your CPanel, you should be able handle most of these fixes with no problems. They’ll make your website less vulnerable to hackers, malware injection or DDOS attacks.

Don’t kid yourself into thinking that attackers won’t bother with you because you don’t handle any sensitive information”¦ most attacks involve sites that don’t handle any financial data or personal information at all – attackers use hijacked sites to inject malware, they use the site to forward spam en masse or they redirect users to other sites.

 

Basic Security

 

1.  Ensure your WordPress core is up-to-date.

One of the most important steps in maintaining your website’s security is ensuring the WordPress core is up-to-date. Whenever a vulnerability is discovered, by the time a new version has been released to patch it, the vulnerability has already been in the public domain long enough to allow hackers to exploit it – and they can work incredibly fast. Just 2 or 3 days out-of-date can be enough to allow them to infiltrate your site”¦. so just imagine if you’re running 2 or 3 versions behind.

WordPress enables you to set up your site for automatic updates, and if you’re not going to keep close tabs and act immediately, I highly recommend you take advantage of this feature. Just go to Dashboard ““ Updates to enable auto-update or to update manually. But remember to always backup your database and files before updating.

2.  Are automatic WordPress core updates enabled?

Normally, we recommend allowing automatic minor core updates, the exception being on a highly customized site with substantial modifications. Most minor updates are security patches that won’t affect your site’s operation. Nevertheless, periodic automatic backups, such as those possible with the iThemes BackupBuddy plugin, can help protect you from lost data in the event of a rare problem encountered after a core update.¹

3.  Ensure your plugins are up-to-date.

The second most important aspect of securing your site is to ensure your plugins are kept up-to-date. Hackers are continuously looking for exploits on plugins and just like with the WP core, they move fast when they find one.

Keeping your plugins up-to-date is an important way to protect yourself against hacking or injection attacks. Conscientious plugin developers will move quickly to patch any vulnerabilities that come to light, but unfortunately, not all plugin devs are conscientious.

For plugins installed from the WordPress plugin repository, it’s easy to see the latest update version and install the latest version. For plugins purchased or otherwise acquired elsewhere, you may have to visit the developer’s site to get the latest version.

Most plugins, you’ll be able to update from the Dashboard ““ Updates area of your site’s backend. Just as with the core, it’s always advisable to backup your database and files before updating plugins. That way, if you experience a problem, you can easily recover to the point before the update.

4.  Ensure your theme is up to date.

Keeping your themes up-to-date is arguably the third most important aspect of your website’s security, as they can be as prone to vulnerabilities as plugins. Just as with plugins, if you got the theme from the WP repository, you can update it in the Dashboard ““ Updates section of your backend. You can also do so from Appearance ““ Themes. If it’s a premium theme, you may have to update manually after downloading the new version from the developer’s site. And again, ALWAYS perform a fresh backup of your database and files before updating the WP core, plugins or your theme.

5. Are you running a child theme?

Many hackers find exploits for specific plugins and themes, then use automated scripts to find sites that are using them, in order to attack the site. Using a child theme can make it more difficult to identify the theme on which your site runs. It won’t prevent a sophisticated hacker from identifying your theme, but it will hide it from the majority of automated attacks. Besides, there are other very good reasons for using a child theme, such as preventing the loss of customizations when a theme is updated.

6.  Are there are deactivated plugins installed?

Even when deactivated, plugins with known vulnerabilities can present an opportunity for hacking or injections, so when you’re not using a plugin, it’s always best to delete it. If it’s a paid plugin you don’t want to delete, at least move it out of the /wp-content/plugins/ folder.

7.  Have all your plugins been updated in the last few months?

It’s not uncommon to see a plugin that was once extremely popular displaying a Last Updated date of 2, 3 or more years past. Sure, that might indicate the developer made it rock-solid and it contains no vulnerabilities. More often, though, it means it’s been abandoned or forgotten.

I recommend that any plugin that hasn’t been updated in 6 months or more should be carefully examined before installing it on your site. A little searching on Google should quickly uncover any relevant online discussion of the plugin, possibly saving you some heartache.

If one of your favorite plugins seems to have been abandoned by the developer, you can often find a replacement or two that can accomplish the same thing. Just be wary of installing plugins that haven’t been quality-checked by WordPress or by someone who knows what they’re looking at.

8.  Ensure all your plugins are tested to be compatible with your version of WP.

Backwards compatibility doesn’t always live up to our hopes. Every reputable plugin developer will test his plugin with each new WordPress core version, to ensure there aren’t any compatibility issues. Even then, though, it’s not unheard of for some problem to crop up or to see a conflict with some other plugin.

Even though testing isn’t infallible, the best protection is to ensure all your plugins have been tested with your version of WordPress before installing and activating them.

9.  Do you have any deactivated themes installed?

Vulnerabilities in themes that aren’t activated can still be exploited, so don’t keep themes you’re not using installed on your site. If it’s a premium theme, the very least you should do is move it out of the /wp-content/themes/ folder.

You can delete unused themes in your backend (Appearance – Themes), in the CPanel or via FTP.

 

Important Considerations

 

10.  Does the username “admin” exist, with administrator privileges?

By default, a new WordPress installation will have “admin” as a username. You should change this to something unique and not easily guessed. If someone successfully determines your administrator username, a brute-force attack to find a password is a remarkably quick process.

If your site still has “admin” as your administrator username, create a new account with administration privileges, assign it a unique username and a complex password, then delete the “admin” account.

11.  Does user with “ID 1” and administrator role exist?

An out-of-the-box WP install will normally assign the default admin account ID 1, which can help an attacker gain access to administrative privileges.

To fix this, create a new user account with admin privileges, then delete the old ID 1 account.

12.  Is your database table prefix still set to the default 62ZpKk_?

A fresh install of WordPress will set the database table prefix to the default 62ZpKk_­. This is easily changed during the initial installation, by changing the table prefix in the config.php file. If the site is already live, it’s a bit more complex and probably should only be attempted by someone with phpMyAdmin experience, as you could easily take your site down. This is another situation in which it’s important to backup your database and files before you make any changes.

13.  Is your WordPress database password strong?

Most servers are set up so that the database can’t be accessed from outside the local network. But mistakes happen, so don’t depend on that. Assign a strong password for your database. Conventional wisdom says at least 8 characters long, with a combination of numbers, letters and special characters. I advise extending that to at least 12 characters.

During a fresh install, you’ll be given an opportunity to set up your DB password, but you can also easily change it in your wp-config.php file, around line 28, which will look something like this:

/** MySQL database password */define(‘DB_PASSWORD’, ‘YOUR_NEW_DB_PASSWORD_GOES_HERE’);

14.  Do your security keys and salts have proper values?

Without going into great detail on how security keys and salts work, suffice it to say that they make the passwords used on your site many times safer against brute-force attacks. They provide a complex encryption, based upon the salts and keys. Essentially, they add seemingly random characters into cookies and passwords, based upon a set pattern.

I’ve seen sites with no keys and salts in place, which means they were storing unencrypted passwords. Obviously, that could be catastrophic! Fortunately, though, WordPress.org has been kind enough to provide a nifty script to generate new strings.

There are eight keys necessary, and the above script will generate a new, unique set you can drop into your wp-config.php file (around lines 48 through 55). They should look something like this:

define(‘AUTH_KEY’,         ‘xRPog|(YD$1h+HgF-?cE/~|OY~K-]!)`Nph4i5bv|#m+y8-Xp*4E9%,K|{Iu&T0P’);
define(‘SECURE_AUTH_KEY’,  ‘u&/TqCymF{q3ljoE9GU].~DH-$/z~2*IXzOH+G]HtT34b * =9Q|TF~AvDwXLv[A’);
define(‘LOGGED_IN_KEY’,    ‘7-9a%T_4Cx]h`VUDSo^Y<WfM[*_$PP4tV#MQxVLw.$nre:HEA:,J t{||W(4cOr’);
define(‘NONCE_KEY’,        ‘lpzae?fp;G9w6G#2RdN,8x*t~P+#+lgk-_+]8;_w+!P*GEdrX]+^5&.r:haQ+6!J’);
define(‘AUTH_SALT’,        ‘<!4G[w-1RQo(lh9mA^@H9,FiYD$cNXZ9XTMKW{y#R;Eh`YBv(>r]+-GH->|fo$L9’);
define(‘SECURE_AUTH_SALT’, ‘DBPi*kN]AbRQ(m;d($$:|^4:8Top4{mHcloj%j{J0s3|onz*|Y!-0K]Cl}s h?}P’);
define(‘LOGGED_IN_SALT’,   ‘E|Q-(=$i{HlV|_+~-++Zm@2`EK,i+lJV8L.jiw|C)#CM<bOO4CPLA 9u`BR9/3e ‘);
define(‘NONCE_SALT’,       ‘<!4G[w-1RQo(lh9mA^@H9,FiYD$cNXZ9XTMKW{y#R;Eh`YBv(>r]+-GH->|fo$L9’);

Warning: The above strings are ONLY A SAMPLE. DO NOT use these strings ““ generate your own at the above link.

15.  Is your WordPress installation address the same as the site address?

Another way to make your site safer against automated attacks is to move the WP core files out of the root directory and into a sub-directory. The simple part of that process is changing the WP address in your backend, in the Options ““ General section. But that’s only part of the process.

Note: You’ll only be changing the WP address, NOT the site URL.

First, go to your CPanel and create a new sub-folder in the root directory. Give it some different name, such as mysite.

Now go to the Options ““ General section in your backend and change the WP address to reflect the new location where your WP core files will be located, such as http://www.example.com/mysite.

When you make that change, your site will be inaccessible until you complete the next steps. Now, return to your CPanel, and check-mark all the WP files and folders in your root directory, with the exception of the .htaccess and index.php files and move them into your new sub-directory.

Note: Any non-WP folders should remain where they are, so leave them unchecked.

Now you’ll need to edit your index.php file to reflect the new location of your core files. Look for the line that should read something like this:

/** Loads the WordPress Environment and Template */require(‘./wp-blog-header.php’ );

and edit it to reflect the new location, such as:

/** Loads the WordPress Environment and Template */require(‘./mysite/wp-blog-header.php’ );

That’s the final step in changing your WP installation address. You’re done. Just don’t forget to change your log-in URL. Since your wp-admin folder has been moved, your new log-in URL will need to accommodate that. So from now on, you’ll log into your backend at www.example.com/mysite/wp-login.php.

Note: Any reference to “mysite” above should be replaced with whatever subdirectory name you choose.

You can also watch this handy video tutorial to help you understand the entire process:

16.  Is wp-config.php present in the default location?

This won’t help you if someone gains access to your server, via FTP or CPanel, but it can help otherwise.

The idea is to simply move your wp-config.php file up one level.

For instance, move it from

/home/www/wp-config.php

to:

/home/wp-config.php

or from

/home/www/my-blog/wp-config.php

to:

/home/www/wp-config.php

17.  What PHP version are you running?

Running an older version of PHP can make your site vulnerable to exploits, as well as cause it to run more slowly. Most reputable hosting companies will readily upgrade your site to PHP v.7, upon request. Our personal hosting favorite, SiteGround, let’s you change your version yourself, from within the CPanel.

18.  Check the MySQL version.

Running an old version of MySQL can also slow your site down and make it more vulnerable to hacking, as some low-budget hosting companies run old MySQL versions that are no longer maintained.

If you find that your site is running on an old version of MySQL, contact them and request they update you to a new version. If they can’t or won’t do so, you should consider moving to another host.

See Part 2 of this series for more advanced security steps you can take to protect your website from hackers, malware and injection attacks.