3 Ways to Disable WordPress XML-RPC for Better Security

I’ve written before about how to protect WordPress XML-RPC and why it’s important. In this quick post, I explain three easy ways to to disable WordPress XML-RPC to help improve the security of your WordPress-powered site.

Contents

• About XML-RPC
• Why Disable XML-RPC?
• Disable XML-RPC via plugin
• Disable XML-RPC via WordPress code
• Disable XML-RPC via Apache/.htaccess
  • Using mod_alias
  • Using mod_authz_core
• Disable XML-RPC via Nginx

About XML-RPC

From the official website:

XML-RPC is a spec and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet.

Basically XML-RPC enables apps to interact with your WordPress site. More specifically, the WordPress xmlrpc.php file (and supporting methods) enables external applications to connect, transmit, and process data. Learn more »

Why Disable XML-RPC?

As explained in my previous posts, WordPress’ XML-RPC file, xmlrpc.php, is a huge target for spammers and bad actors. The file is repeatedly attacked by all sorts of bad bots looking for a “way in” to your WordPress site.

Don’t misunderstand, WordPress itself is secure out of the box. There are no outstanding security issues involving xmlrpc.php or related functionality. So in general there is nothing to worry about. Nothing that is, until something changes and a vulnerability is introduced, either from a 3rd-party plugin or theme, or could be that a new way to hack XML-RPC is discovered.

Who knows what the future holds, what some brilliant hacker will discover, or which plugins and themes may be problematic with XML-RPC. Sure everything is fine now, but as things change, you don’t want to take any chances, especially for an obscure feature that you probably never use.

So if you’re not using XML-RPC for anything, you might as well lock it down and block all access to the file, and/or disable XML-RPC programmatically. That way your site is protected if and when the next XML-RPC vulnerability hits the streets.

Let’s look at several different ways to disable WordPress XML-RPC..

Disable XML-RPC via plugin

The WordPress Plugin Directory provides some free plugins that effectively disable WordPress XML-RPC functionality, for example:

• Disable XML-RPC
• Disable XML-RPC-API
• stop XML-RPC Attacks

Pros & Cons

Some pros and cons of using a plugin to disable XML-RPC:

• Pro: Fast and easy
• Pro: No code required
• Con: Not as efficient as handling via server level

The main downside with using a plugin to disable XML-RPC, is that the server still has to load up the database, PHP, and everything else for each request. Contrast that with blocking XML-RPC requests directly at the server level (like via Apache or Nginx), so a lightweight “denied” response can be served for blocked requests, with no need to load the database and other heavy resources.

Disable XML-RPC via WordPress code

There is some confusion in the community as to which code is required to fully disable XML-RPC functionality. This is the commonly shared code snippet:

// Disable XML-RPC for authenticated methods
add_filter('xmlrpc_enabled', '__return_false');

That looks great, but only disables any XML-RPC methods that require authentication, like publishing posts, editing, deleting, and so forth. It does not disable methods where authentication is not required, like reading, pingbacks, and other custom endpoints. So the above one-liner doesn’t completely disable XML-RPC, but is useful in helping to lock things down.

To disable XML-RPC methods that do not require authentication.

// Disable all XML-RPC functionality
function shapeSpace_disable_xmlrpc($methods) {

	return array();

}
add_filter('xmlrpc_methods', 'shapeSpace_disable_xmlrpc');

This technique disables all XML-RPC functionality by passing an empty array via the xmlrpc_methods filter hook. This can be further simplified by using the WordPress function, __return_empty_array(). For example:

// Disable all XML-RPC functionality
add_filter('xmlrpc_methods', '__return_empty_array');

That one line takes care of disabling all XML-RPC functionality. The only other sort of related thing is the X-Pingback header, which WordPress includes automatically. So if XML-RPC is disabled, it makes sense also to disable the header, because pingbacks require XML-RPC in order to work. This will do it:

// Disable X-Pingback header
function shapeSpace_disable_x_pingback($headers) {

	unset ($headers['X-Pingback']);
	return $headers;

}
add_filter('wp_headers', 'shapeSpace_disable_x_pingback');

No editing or changes required. Add to your WordPress and done.

Pros & Cons

Some pros and cons of using WordPress code to disable XML-RPC:

• Pro: More flexible than using a plugin
• Con: Requires copy/pasting some codes
• Con: Not as efficient as handling via server level

The big upside to disabling XML-RPC using code snippets, is that it allows for greater flexibility than using a plugin. The code may be added via a plugin or theme functions.php, and it also may be customized with additional logic to support other types of functionality, integrations, etc.

As far as server efficiency is concerned, it’s the same deal as with plugins: you get better performance by disabling/blocking XML-RPC at the server level. That way blocked requests aren’t draining precious resources like database, PHP, JavaScript, CSS, images, and all the rest.

Disable XML-RPC via Apache/.htaccess

The easiest and most effective way to protect against XML-RPC attacks is to just deny access to WordPress’ xmlrpc.php file. Here are two ways to do it using Apache/.htaccess.

Using mod_alias

Here is the technique that I use to protect XML-RPC on my own WordPress sites, using Apache’s alias module, mod_alias:

# Protect xmlrpc.php
<IfModule mod_alias.c>
	RedirectMatch 403 (?i)/xmlrpc\.php
</IfModule>

This simple directive blocks all access to xmlrpc.php by returning a 403 “Forbidden” response for all requests. Very lightweight and very effective.

Using mod_authz_core

Here is an alternate way of denying access to all requests for xmlrpc.php, using Apache’s authorization module, mod_authz_core:

# Protect xmlrpc.php (Apache 2.2)
<Files xmlrpc.php>
	Order Allow,Deny
	Deny from all
</Files>

# Protect xmlrpc.php (Apache 2.4+)
<Files xmlrpc.php>
	<RequireAll>
		Require all denied
	</RequireAll>
</Files>

For older versions of Apache, use the first code snippet. For Apache version 2.4 and better, use the second snippet. No need to use both.

Pros & Cons

Some pros and cons of disabling XML-RPC at the server level:

• Pro: Performance benefits
• Pro: More flexible than using a plugin
• Con: Requires copy/pasting some codes

The big win here is with performance. When blocking requests at the server level, only a few bytes are required, so very minimal requirements in terms of server memory, bandwidth, and so forth. Contrast with using a plugin or WordPress code, where each request has to load up heavy resources like the database, PHP, and everything else. It just makes more sense to save all those resources for legitimate visitors.

Disable XML-RPC via Nginx

Similar to protecting xmlrpc.php with Apache, here is how to do it using Nginx and its access module, ngx_http_access_module:

# Protect xmlrpc.php
location /xmlrpc.php {
	deny all;
}

This simple directive blocks all access to xmlrpc.php by returning a 403 “Forbidden” response for all requests. Very lightweight and very effective.

Pros & Cons

Using Nginx to protect xmlrpc.php has the same pros and cons as the Apache/.htaccess technique. Basically huge performance benefits FTW.

That’s all for now folks, thanks for reading :)

About the Author

Jeff Starr = Web Developer. Security Specialist. WordPress Buff.