I wrote an article recently about applying some of the more common security tweaks to WordPress to make it a more robust system than it already is out of the box. I talked about some of the steps that can be performed during installation like creating an admin username other than “admin,” using a sentence with punctuation as a very strong virtually unhackable password, and changing the default table prefix for the WordPress database, and so on. In this article I will talk about some other more advanced techniques for keeping WordPress secure.

Let’s get into it. But first I would like to suggest that you apply these techniques in a test environment before applying them to a live WordPress site.

WordPress security

1) Disable HTTP Trace Method

A hacker might use a technique called Cross Site Tracing (XST), perhaps in combination with Cross Site Scripting (XSS) to steal sensitive server information (and even cookies), using header requests.

They can only exploit systems in this way that have HTTP TRACE functionality enabled. HTTP TRACE is most often turned on by default and provides an environment for a developer to debug his or her web based application.

The trace mechanism can be turned off by adding the following commands to the .htaccess file (or through your Apache config).

RewriteEngine On
RewriteRule .* - [F]

2) Eliminate Header Output That WordPress Spits Out

WordPress, by default, has a big head. A lot of the information that is outputted can be revealing to a hacker and provide them with enough information to know which exploits to attempt on a given WordPress install.

Fortunately we can prevent much of this uneeded output from being added to the HTML head tags.

The following code can be added to a theme’s functions.php file. You may want to test them one by one to make certain they don’t break some functionality of your site that you actually want or need.

These are the common ones to remove from the head.

remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'feed_links', 2);
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'feed_links_extra', 3);
remove_action('wp_head', 'start_post_rel_link', 10, 0);
remove_action('wp_head', 'parent_post_rel_link', 10, 0);
remove_action('wp_head', 'adjacent_posts_rel_link', 10, 0);

Do a search on WordPress.org for each one to see what it’s use it before getting rid of them. In some cases you may have a use for them.

The Head Cleaner WordPress plugin will give you ideas of you might want to remove from the head, as well as what you might want to include.

3) Prevent Comments Being Made From a Proxy Server

Comment spam has no value to your blog what-so-ever, and in general, when a comment is posted from a proxy server, it is intended as spam.

Although this isn’t as much a security tweak as it is a spam protection tweak, it does have a security angle to it. If there is a particular known vulnerability in the version of WordPress that is running, although rare, it may be able to exploited via a comment. In addition, if a server is commenting relentlessly it can (and has) bring a WordPress site down to it’s knees.

Here are the commands that can be added to the .htaccess file to prevent comment spam from a proxy server.

RewriteCond %{REQUEST_URI} !^/(wp-login.php|wp-admin/|wp-content/plugins/|wp-includes/).* [NC]
RewriteRule .* - [F,NS,L]

You can test each security tweak one at a time on a test WordPress install before applying to a live system. While this article served as an overview, it is a good idea to understand each “tweak” in detail to understand what exactly it is meant to do. Plus, it’s good to know what it can potentially do (in a negative sense) so that you can check for that as well after the tweak is applied.

In conclusion, I would recommend a security plugin that will alert you of common hacking attempts so that you can address them as they happen.