Update Frequently

The first and most important security tip is to always make sure you upgrade to the most recent version of WordPress as soon as a new version becomes available and also always update any plugins/themes that you have installed on your site. Many of the updates that are pushed out involve security updates; therefore, it is always important to upgrade your software in order to stay up to date and safe.

Don’t Use the Username “admin”

Another important item to take care of is making sure not to use “admin” as one of your user accounts. Many bots will automatically try to log in to your site with this username. Knowing that most people don’t change this account is half the battle; all they really need to focus on is guessing the password. When installing WordPress, the default username will be “admin” unless you specifically change it, and you should specifically change it! If you are already using WordPress under the username “admin,” you should create a new user account with an administrator role, log in with that new user, and delete the default administrator account. Make sure you change over any posts or pages created by your administrator account to this new account.

Use a Strong Password

Choosing a secure password is also very important, especially for your administrator accounts. Don’t use one word or one name. Jumble your password up and make it not connected to you personally.

Make sure your password is a combination of upper- and lowercase letters as well as numbers and special characters. A good password should also be at least 10 characters long; the more characters you use, the stronger your password will be. If you are having trouble coming up with one yourself, just mash on your keyboard a bit or use a service like Random.org. Make sure you memorize it or copy it somewhere and secure it properly. WordPress will tell you whether you are using a strong password; please take this into consideration.

Examples of Bad Passwords

Following are some examples of bad passwords:

• password

• password123

• pa55w0rd

• 123456789

• qwerty

• batman

• mustang

• letmein

Using any variation of password or single words, numbers, or names is a bad idea:

• usmarine (Brian was in the Marines)

• brianmessenlehner (Brian’s first and last name)

• jason&kim050507 (Jason’s name, his wife’s name, and their anniversary)

• Dalya-Brian (kids’ names)

• ThaiShortiMaxx (pets’ names)

• IAMAWESOME! (everybody knows this, so it could be easy to guess)

Anybody who knows anything about us or our families could potentially guess passwords like these.

Examples of Good Passwords

Following are some examples of strong passwords:

• U$s(#8H27@!

• !lik32EaTF1$h&CHIp5

• #Uk@nN0tBr3akTh1s$h1t!!!

• [0mG-LoL-R0Fl-T0T3$CraY]!

It can be a pain in the neck and take an extra second or two entering a good password, but it’s well worth it if it can prevent your website/application from being hacked.

Don’t Allow Admins to Edit Plugins or Themes

By default, WordPress allows administrators to edit the source code of any plugin or theme directly in the web browser. You should disable this functionality so that if a hacker is able to log in to one of your administrator accounts, they can’t add malicious code via the administrator user interface for editing code. To disable this functionality, add this code to your wp-config.php file:

define( 'DISALLOW_FILE_EDIT', true );

Change Default Database Tables Prefix

The standard WordPress installation uses wp_ as a prefix for all tables in the database. By simply changing this prefix to something else, you will make your site far less vulnerable to hackers who attempt SQL injections and assume you’re using the generic wp_ prefix. On a brand-new WordPress installation, you have the option to use any table prefix you want; you should change the default wp_ prefix to something custom.

To do this on a WordPress site that is already up and running, follow these steps:

1. Make a database backup just in case you mess this up!

2. Open wp-config.php and change $table_prefix = wp_; to $table_prefix = anyprefix_;.

3. Update the existing table names in your database to include your new prefix with the following SQL commands using phpMyAdmin or any SQL client such as MySQL Workbench:

   rename table wp_commentmeta to anyprefix_commentmeta;
   rename table wp_comments to anyprefix_comments;
   rename table wp_links to anyprefix_links;
   rename table wp_options to anyprefix_options;
   rename table wp_postmeta to anyprefix_postmeta;
   rename table wp_posts to anyprefix_posts;
   rename table wp_terms to anyprefix_terms;
   rename table wp_term_relationships to anyprefix_term_relationships;
   rename table wp_term_taxonomy to anyprefix_term_taxonomy;
   rename table wp_usermeta to anyprefix_usermeta;
   rename table wp_users to anyprefix_users;

Using SQL commands or a SQL client, update any of the instances of wp_ in the prefix_options and anyprefix_usermeta tables and change any values like wp_ to prefix_:

update anyprefix_options set option_name = replace(
option_name,'wp_','anyprefix_');
update anyprefix_usermeta set meta_key = replace(
meta_key,'wp_','anyprefix_');

Test out your site and make sure everything is working as it should.

If you don’t feel comfortable making these changes manually, there are plugins available that can change your table prefix for you:

• Change Table Prefix

• Brozzme DB Prefix & Tools Addons

Move wp-config.php

The WordPress wp-config.php file stores valuable information like your database location, username, and password and your WordPress authentication keys. Since these values are stored in PHP variables and they are not displayed to the browser, it is not likely that anybody could gain access to this data, but it could happen. You can move wp-config.php to one level above your WordPress install, which in most cases should be a nonpublic directory. If it doesn’t find it in your root directory, WordPress automatically looks one level up for wp-config.php. For example, move /username/public_html/wp-config.php to /username/wp-config.php.

You can also store wp-config.php as any filename in any directory location. To do this, make a copy of wp-config.php, name the copy whatever you want, and move it to any directory above your root install of WordPress. In your original wp-config.php file, remove all of the code and add an include to the relative path and filename of the copy you made. For example, copy /username/public_html/wp-config.php to /username/someotherfolder/stuff.php. Change the code in the wp-config.php file to include('/username/someotherfolder/stuff.php');.

Hide Login Error Messages

Normally, when you’re trying to log in to your site, WordPress displays an error message if you’ve entered the wrong username or password. Unfortunately this lets hackers know exactly what they are doing wrong or right when attempting to access your site.

Luckily there is a simple fix for this: add a line of code into your theme functions.php file or in a custom plugin that will hide or alter those messages:

add_filter( 'login_errors', function ( $message ) {
    return "Invalid username or password.";
} );

Hide Your WordPress Version

Many bots scour the internet in search of WordPress sites to target specifically by the WordPress version they are running. These bots look for sites with known vulnerabilities they can exploit. By default, WordPress displays the following code within the <head></head> of every page:

`<meta name="generator" content="WordPress 3.8.1" />`

You can easily hide the version of WordPress you are using by implementing the following code:

add_filter( 'the_generator', '__return_null' );

Don’t Allow Logins via wp-login.php

Some bots are smarter than others. We just discussed hiding your WordPress version from some bots, but sometimes all a bot needs to know is that you’re using WordPress. This is easy if it sends a POST request to wp-login.php. Once a bot knows wp-login.php exists, it can start trying to log in to your site.

We like to redirect wp-login.php to the home page, which prevents bots from specifically trying to log in using this file. Follow these steps to make an alternative login page and hide the default wp-login.php login page:

1. Add the following rewrite rule to your .htaccess file:

   RewriteRule ^new-login$ wp-login.php

   Note that /new-login/ will be the URL you can use to actually log in to wp-admin. You can change this to whatever you want.

2. In your theme functions.php file or in a custom plugin, add this code:

   function schoolpress_wp_login_filter( $url, $path, $orig_scheme ) {
       $old = array( "/(wp-login.php)/" );
       $new = array( "new-login" );
   	return preg_replace( $old, $new, $url, 1 );
   }
   add_filter( 'site_url', 'schoolpress_wp_login_filter', 10, 3 );
   
   function schoolpress_wp_login_redirect() {
    if ( strpos( $_SERVER["REQUEST_URI"], 'new-login' ) === false ) {
   		wp_redirect( site_url() );
   		exit();
    }
   }
   add_action( 'login_init', 'schoolpress_wp_login_redirect' );

If you don’t want to write any custom code, you can use the following plugins to achieve similar results:

• iThemes security

• WP Admin

Add Custom .htaccess Rules for Locking Down wp-admin

If you are the only user that needs to log in to the backend of your application, or if you have only a handful of backend users, you can restrict access to the backend by certain IP addresses. Create a new .htaccess file in the wp-admin directory of your WordPress installation and add the following code, replacing 127.0.0.1 with your actual external IP address. Go to http://ipchicken.com/ if you are not sure of your external IP address:

order deny,allow
allow from 127.0.0.1 #(repeat this line for multiple IP addresses)
deny from all

If you suspect that certain IP addresses hitting your application are bots or malicious users, you can block them by their IP addresses by using the following code:

order allow,deny
deny from 127.0.0.1 #(repeat this line for multiple IP addresses)
allow from all

If people really want to get around their banned IP address, they will use a proxy server.

If you think your IP address or that of your backend users may change often or you have far too many backend users to manage all of their IP addresses, you can add a separate username and password to access the wp-admin directory. This adds a nice second layer of authentication because all of your backend users will be required to enter an htaccess username and password and their standard WordPress username and password:

AuthType Basic
AuthName "restricted area"
AuthUserFile /path/to/protected/dir/.htpasswd
require valid-user

Notice the AuthUserFile line; you will need to create a .htpasswd file somewhere in a directory above or outside of your WordPress install. In this file, you will need to add a username and password. The password can’t just be plain text; use a tool like htaccess password generator to create an encrypted password.

So the username/password for letmein/Pr3tTyPL3a$3! after encryption should be letmein:E5Dj7cUaQVcN.

Add the entire encrypted string letmein:E5Dj7cUaQVcN. to your .htpasswd file; and when users try to go to /wp-admin, they will be prompted for a username and password. Make sure to let your backend users know what this username and password is and tell them not to share it with anybody.

Installing an SSL Certificate on Your Server

First, make sure that you have SSL enabled on your web server. How to do that will depend on your specific host and web server. DigitalOcean has great system administrator documents in general and a particularly good article on setting up SSL with Apache.

After enabling the SSL service on your host, you’ll need an SSL certificate to use with it. You can use self-signed certificates for testing purposes, but modern-day browsers will show some fairly dire warnings when you browse to a site using a self-signed certificate. Figure 8-1 shows the warning displayed to Chrome users.

Figure 8-1. Chrome SSL warning

For production environments, you’ll want to use a public-key certificate from a certificate authority, or CA. You can purchase public-key certificates, though they’re usually bundled or offered as an add-on to your web-hosting package. You can also use public-key certificates (SSL certificates) purchased from third parties. A good CA certificate will be trusted by all modern web browsers, which is what gives you the green or golden padlock icon on your website instead of a broken or red padlock.

There are good options now for paid or free CA certificates. What you’re really doing when you use a CA certificate is confirming that you actually own the domain on which you are using the certificate. Ownership of the domain is usually confirmed via email to an address on the domain. Or, in the case of Let’s Encrypt, the confirmation is done through automated scripts run from the server in question.

Again, every website should install an SSL certificate. In the first edition of this book, we covered methods to serve the admin and checkout pages over HTTPS while the rest of the site was served over unsecured HTTP. We no longer recommend this kind of hybrid setup. The internet has moved to a place where it is assumed that all websites are served entirely over HTTPS. This is part of a larger “security by default” movement.

There are a number of reasons to set up HTTPS on your entire site:

• Security by default. You might imagine that only your login and checkout pages really need to be secure, but what happens when your site is updated to show a login form in the sidebar? Now every page on your site needs to be secure. If your entire site is served over HTTPS, you won’t accidentally introduce an unencrypted form anywhere on the site.

• Internet consumers are trained to look for that padlock (see Figure 8-2). Both savvy and nonsavvy users will feel better seeing it. Further, modern browsers will show some pretty scary warnings if parts of your site are not served over HTTPS.

• Google and other search engines have started boosting sites that are served entirely over HTTPS in their search rankings.

• There is no longer a CPU hit to your server when you use HTTPS. The web server stack has been updated to better handle HTTPS and frankly expect it, so you can no longer use page load times as an excuse to disable HTTPS on your site.

Figure 8-2. Various padlocks across browsers

WordPress Login and WordPress Administrator over SSL

Serving your checkout page over SSL is the minimum you can do to secure the private data passed to and from your site. You can also set up WordPress to use SSL on the login page, in the administrator dashboard, across the entire site, or only on select pages.

For SSL logins in WordPress, you set the FORCE_SSL_LOGIN constant to true in your wp-config.php file. Place the following line of code above the “That’s all, stop editing! Happy blogging.” comment at the end of the file:

define('FORCE_SSL_LOGIN', true);

To use SSL on the login page and in the administrator dashboard, use the following FORCE_SSL_ADMIN constant instead:

define('FORCE_SSL_ADMIN', true);

Debugging HTTPS Issues

Now we’re going to write a quick little function to filter URLs generated by WordPress to use the same protocol as the current page. Remember earlier that we talked about how URLs like https://yoursite.com/some-page (HTTP) that show up on a page like https://yoursite.com/checkout (HTTPS) will cause your browser to show a security warning:

function my_https_filter($s) {
	if(is_ssl())
		return str_replace("http:", "https:", $s);
	else
		return str_replace("https:", "http:", $s);
}
add_filter('bloginfo_url', 'my_https_filter');
add_filter('wp_list_pages', 'my_https_filter');
add_filter('option_home', 'my_https_filter');
add_filter('option_siteurl', 'my_https_filter');
add_filter('logout_url', 'my_https_filter');
add_filter('login_url', 'my_https_filter');
add_filter('home_url', 'my_https_filter');

The is_ssl() function provided by WordPress will return true if the current page was loaded over HTTPS. The is_ssl() function checks specifically if the $_SERVER['HTTPS'] global is set to on or 1 or if the $_SERVER['SERVER_PORT'] global is set to 443. Some server setups behind load balancers or reverse proxies will load HTTPS pages without setting those globals properly in PHP. You can fix this by adding the following code to your wp-config.php file.

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
		&& $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
	$_SERVER['HTTPS'] = 'on';
}

Our https filter uses the str_replace() function to swap “http:” for “https:”, or vice versa. We set this filter to run on a number of built-in WordPress hooks used at various places throughout the WordPress codebase where URLs are generated.

When you output URLs in other places of your custom application code, be sure to use the home_url() function to make sure the URL is generated correctly and the my_https_filter is run on it.

Avoiding SSL Errors with the “Nuclear Option”

The my_https_filter() function ensures links that show up on a page use the correct protocol. However, sometimes raw http://… URLs may be hardcoded into your posts, or maybe a plugin you use doesn’t use the built-in WordPress functions like it should when outputting same-site URLs or loading JavaScript or CSS files. Figure 8-3 shows the Chrome Developer Tools Console, which can help locate errors.

Figure 8-3. An SSL error in the Chrome Developer Tools Console

In these cases, you can try to find each case of a bad URL and fix the link in your posts or code to use a relative URL or the proper WordPress function to make sure it will output on the frontend using the proper protocol. However, it’s sometimes easier to use what we call the Nuclear Option:

constant('MY_SITE_DOMAIN', 'yoursite.com');

function my_NuclearHTTPS() {
	ob_start("my_replaceURLsInBuffer");
}
add_action("init", "my_NuclearHTTPS");

function my_replaceURLsInBuffer($buffer) {
  global $besecure;

	//only swap URLs if this page is secure
	if(is_ssl())
	{
/*
okay swap out all links like these:
* http://yoursite.com
* http://anysubdomain.yoursite.com
* http://any.number.of.sub.domains.yoursite.com
*/
$buffer = preg_replace(
      '/http://([a-zA-Z0-9.-]*'.str_replace('.','.',MY_SITE_DOMAIN).')/i',
      'https://$1',
$buffer
      );
	  }

	return $buffer;
}

First, we need to make sure we define a constant MY_SITE_DOMAIN and set it to the second-level domain (SLD) for your site. Your site_url() set in WordPress may be http:/<www.yoursite.com, but we are interested here in just the yoursite.com part of that.

Then, my_NuclearHTTPS() fires on the init hook and uses the PHP function ob_start() to turn on output buffering. Output buffering means that all output generated by PHP (e.g., via echo function calls or inline HTML) goes into a buffer string instead of straight to the browser. Then, when PHP is finished generating all output (or if you call the ob_end_flush() function first), the buffer string is passed to a callback function, which is my_replaceURLsInBuffer() in this case.

The my_replaceURLsInBuffer() function filters the buffer string, swapping out “http:” for “https:” on every link. The regular expression magic we’re doing in the preg_replace() call there makes sure that links to any subdomain using the same domain (why we needed to set the MY_SITE_DOMAIN constant) will also be filtered.

So you might have caught on by now why we call this the “Nuclear Option.” Instead of finding the source of bad URLs in your app and fixing them, we just fix all of the URLs at once before sending the output to the browser. There will be a small performance hit here, depending on how large your HTML output is. But this method can be useful in a pinch, especially if you are using many third-party plugins that you can’t or don’t want to fix to output site URLs properly.

Spam-Blocking Plugins

Spam is a problem for every website on the internet. These plugins will help.

Backup Plugins

Backups are very helpful to have in the event that your site is compromised. Here are a few popular backup plugins.

Firewall/Scanner Plugins

The plugins that follow are useful for detecting and mitigating the kinds of automated attacks that plague every website on the internet.

Login and Password-Protection Plugins

The plugins here deal specifically with limiting access to the WordPress login page and dashboard in general.

Check User Capabilities

Each of your users has unique standard or custom roles and capabilities. If you are writing some code that provides custom functionality for your application’s administrators, make sure to give access to administrators, and only administrators. There are a few built-in WordPress functions for telling you whether a user has certain roles or capabilities. All of these functions are located in wp-includes/capabilities.php and return a Boolean of whether the user has the passed-in role name or capability. You can pass in any default or custom-made roles or capabilities.

function schoolpress_admin_check() {
	global $user_ID;
	if ( ! user_can( $user_ID, 'administrator' ) ) {
        wp_redirect( site_url() );
    }
}
add_action( 'admin_init', 'schoolpress_admin_check' );

Custom SQL Statements

Sometimes the built-in WordPress functions that interact with the database may not be enough for your needs, and depending on what you are building, you may want to write custom SQL statements. When writing your own SQL statements, you need to make sure you do so in a way that will not allow for any potential SQL injections. First, always use the $wpdb object and make sure to escape and prepare all custom SQL statements.

As we talked about in Chapter 3, the $wpdb object can be used to access any standard or custom tables in your WordPress database and provides easy-to-use methods for doing so. One very important thing to remember is that when writing custom queries with any dynamic values being passed in, you need to use the esc_sql() function or the prepare() method to sanitize and escape those dynamic values. By sanitizing and escaping dynamic values, you are making sure those values are not made up of invalid characters or malicious SQL code that can hijack your query (SQL injections).

The esc_sql() and $wpdb->prepare() functions are covered in detail in Chapter 3.

Data Validation, Sanitization, and Escaping

Do not trust your users! Again: do not trust your users! Don’t be that web application, website, or blog that spreads malware.

Validate, sanitize, and escape every piece of data going into and coming out of your database. You want to make sure that the data your users are submitting to your database is in the format it should be in; the database doesn’t care what the data is as long as the data being submitted is of the same datatype.

For example, suppose that you have a custom form used to collect user data with a textbox for date of birth (DOB). You plan on storing the DOB as user meta in the meta_value column of the wp_usermeta table. The meta_value column has a datatype of longtext, meaning the value can be super-duper long¹ and the database isn’t going to care what value you store there. It’s up to you as the developer to make sure the data being stored as DOB is a date and nothing else.

So what exactly is the difference between validation, sanitization, and escaping?

Validating

The process of making sure the data received from the end user is in the correct format you expect it to be in. You want to validate data before saving it into the database.

Sanitizing

The process of cleaning data received from the end user before saving it to the database or using it in your app.

Escaping

The process of cleaning data you may already have before displaying it to the end user, saving it to the database, or passing it off to an API.

Now you know!

You want to validate and sanitize any data submitted to your app through form submissions, URL parameters, or API calls. You want to escape any data before putting it into your database or echoing it out to the screen. When pulling data out of your database, you want to sanitize it just to be safe in case somehow you are storing unsanitized data.

PHP has validation and sanitization functions, but WordPress has its own helper functions built in. This is a book about WordPress, so let’s talk about some of those functions.

// pretend a user added an email address "jason @ stranger$tudios.com"
$user_email = 'jason @ stranger$tudios.com';

// we can check if this is a valid email
$valid_email = is_email( $user_email );

// we know it's not because it's set to nothing from is_email()
if ( ! $valid_email )
	echo 'invalid email<br />';

// let's try again with sanitizing the email
$user_email = 'jason @ stranger$tudios.com';

// use sanitize_email() to try to fix any invalid email
$user_email = sanitize_email( $user_email );

$valid_email = is_email( $user_email );

if ( ! $valid_email )
	echo 'invalid email<br />';
else
	echo 'valid email: ' . $user_email;

Nonces

Nonce means “number used once,” and using nonces is critical to protecting your application from cross-site request forgery (CSRF) attacks. Normally your server-side scripts for form processing are processing forms from your own site. People visit your site, log in, and submit a form to perform some action on your site. However, if your server-side code were simply looking for $_POST values to determine what to do, those values could be submitted from any form, even forms on other websites.

The first line of defense is to check that a user is really logged in and has the capabilities to do the requested action. However, this isn’t enough to stop CSRF attacks, because you might be logged in on your WordPress site (e.g., in a background tab) while some malicious code on another site/tab kicks off the form request with the correct $_POST variable to send a spammy message to your friends or initiate account deletion or something else you don’t want to do.

What’s needed is a way to make sure that the request comes from the WordPress site and not another site. This is what a nonce does. The basic outline of using a nonce is as follows:

1. Generate a nonce string every time a page is loaded.

2. Add the nonce string as a hidden element on the form.

3. When processing a submitted form, generate the nonce the same way and check that it matches the one submitted from the form.

Because the nonce is generated using a combination of the secret salt keys in your wp-config.php and the server time, it is difficult for attackers to guess the nonce string for their spoofed forms.

Nonces are useful for nonform links and Ajax calls as well. The process is basically the same:

1. Generate a nonce string every time a page is loaded.

2. Add the nonce string as a parameter to the URL.

3. When processing the request, generate the nonce the same way and check that it matches the one submitted through the URL.

Whether protecting your forms, links, or Ajax requests, WordPress has a few helper functions to make this process very easy to implement.

// simple url with querystring example
function schoolpress_footer_nonce_url(){
	$url = wp_nonce_url(
		add_query_arg( array( 'action' => 'get_users' ) ),
		'get_users_nonce'
	);
	echo '<p><a href="' . esc_url( $url ) . '">Get Users</a></p>';
}
add_action( 'wp_footer', 'schoolpress_footer_nonce_url' );

// querystring action
function schoolpress_footer_nonce_url_action(){
	// check if querystring action is get_users and for the nonce
	if ( isset( $_GET['action'] )
		&& 'get_users' == $_GET['action']
		&& check_admin_referer( 'get_users_nonce' ) ) {
		echo 'Your action: ' . esc_html( $_GET['action'] );
		// or get your users and display them here...
	}
}
add_action( 'init', 'schoolpress_footer_nonce_url_action' );