Securing WordPress

Preview - Securing WordPress

When developing for clients on the WordPress CMS platform you must also be literate in how you can secure your WordPress install from malicious attacks, outsourcing your IT department is one of the best ways to protect your business.

Some ways in which you can do this are very simple and can be solved by little more than installing a plugin. There are plenty of other security geniuses within the WordPress community. We also cover some more complex security fixes, which require technical and programming ability. Keep reading if your interested in how you can secure up your WordPress installation, from malicious attacks, cross site scripting and much more.

Remove WordPress Version Number From Source Code

A small and easy change which although not achieving a great deal, can at least make it a little more challenging to find the version number your WordPress install is running on.

You can do this by adding this line to your functions.php

remove_action('wp_head', 'wp_generator');

Stop WordPress allowing unlimited password guesses

By default WordPress hosting does nothing to stop a user guessing usernames and passwords at /wp-login.php – this is bad!
We can safely assume that if you’ve done more than 6-10 failed login attempts in a short space of time, you might be trying to game the system, so, how we can we implement something to make this harder. Simple.

These two great plugins will help you.

After a series of failed login attempts the plugin will lock down your IP address attempting anymore logins for a period of time, making it considerably harder for a brute force attack to be successful. It also comes with a few handy administrative options, like determining the length of time to lock the user out for etc.

You could take this a little further and add an Re-Captcha to the site wp-login page as well. You can do this with the use of two simple plugins.

Install the first wp-captcha plugin first and grab an re-captcha api key from if you haven’t already got one.

Although if your like us and develop with WP_DEBUG set to TRUE, you will find that the wp-login-recaptcha contains a notice of deprecation in it.

I have forked this on Github and created my own version of the plugin.

Find it here -> here

After this you will have secured your wp-login page reasonably well from malicious or brute force attacks, or have you? click here to know why a blog might be useful.

Yes you have, but one more thing…

Change your password, make it a strong password, if your unsure of what makes up a strong password then a quick google ‘strong password generator’ will quickly solve your problem. Perhaps also consider obscuring your admin username login to something less obvious, even your name is less obvious than admin.

Securing the admin username

After changing your username to something more obscure you might also notice if you deliberately get the password wrong WordPress actually changes its output message.

See the below example:

Screen Shot 2012 04 05 at 14.17.31 300x238 Securing WordpressScreen Shot 2012 04 05 at 14.28.58 300x261 Securing Wordpress

A bot could then make a reasonably concrete observation that it’s found a valid username and concentrate login attempts on that username.

Lets change that.

We can simply change the output message for the error message which contains you entered for the username. How you ask? Simples. Drop the below code snippet into your functions.php file. This will give you a generic response with any error.

function login_error_message($error){
    //check if that's the error you are looking for

    //its the right error so you can overwrite it
    $error = sprintf(__("Login failed, please try again. Lost password?"),get_bloginfo('url'));

    return $error;


Removing autocomplete from wp-login form

Some would see autocomplete as just one of those things, and in general I tend to agree, but if your being really picky about security, autocomplete can open a can of worms when sharing a computer with another user or logging in from a remote location. So in general it might be better to remove the functionality from wordpress wp-login altogether.

WordPress by default offers no such hooks or filters unfortunately, however, we came up with a clever solution of just using a piece of javascript to do the work for us.

Changing file permissions

If you have shell access to your server or installation you can change the permissions of the directories within wordpress to the right permissions by running the following commands.

For Directories:

find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

For Files:

find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Securing your wp-config.php file

Move your wp-config.php file one directory level up, preferably outside of your http/ or html/ folder.

Also make sure you and the web server only can read this file (generally this would mean giving the file a 400 or 440 permission setting).

Add the following to your .htaccess file to prevent people surfing for your config file.

<files wp-config.php>
order allow,deny
deny from all

Administration over SSL

The ultimate weapon in your security arsenal for WordPress is an SSL layer and then forcing WordPress administration to run over SSL. You can do this pretty simply by enabling some simple settings in your wp-config.php file.

Place the following code snippets above the following point in your file:

/* That's all, stop editing! Happy blogging. */
require_once(ABSPATH . 'wp-settings.php');
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

Forces all admin sessions and logins to happen over SSL.

XSS Scripting

Lastly as with any application you need to secure your site from XSS Scripting. XSS Scripting (cross site scripting). As defined by Wikipedia:

Cross-site scripting (XSS) is a type of computer insecurity vulnerability typically found in Web applications (such as web browsers through breaches of browser security) that enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 80.5% of all security vulnerabilities documented by Symantec as of 2007. Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner.

You can prevent cross site scripting through numerous methods but here’s a quick checklist.

  • Transfer data over a SSL
  • Escaping data (output encoding)
  • Preventing injections
  • Never trust inserted data & never insert un-trusted data
  • HTML Escape Before Inserting Untrusted Data into HTML Element Content
  • Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
  • JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
  • URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
  • Prevent DOM-based XSS

Blog written by Dave

I am one of the Directors of Bytewire and I like to blog about lots of different and interesting stuff surrounding the website design and development world.

Leave your thoughts

You may use these HTML tags and attributes in your comments.