Celebrating 20 years online :)
Web Dev + WordPress + Security

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

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.

Note: In most cases it’s safe to disable XML-RPC with no issues. If however you actually are using XMP-RPC for anything, like remote login, remote posting, and/or anything else, then you should not disable XML-RPC by any means.

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:

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.

Related: Here is a guide on how to add custom code to WordPress.

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.

Important: Remember to test after disabling XML-RPC by requesting /xmlrpc.php and checking the results. Tip: you can use a free online validation service such as xmlrpc.blog. Thanks to Arin for mentioning.

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.

Important: Remember to test after disabling XML-RPC by requesting /xmlrpc.php and checking the results. Tip: you can use a free online validation service such as xmlrpc.blog. Thanks to Arin for mentioning.

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.

Important: Remember to test after disabling XML-RPC by requesting /xmlrpc.php and checking the results. Tip: you can use a free online validation service such as xmlrpc.blog. Thanks to Arin for mentioning.

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.
BBQ Pro: The fastest firewall to protect your WordPress.

One response to “3 Ways to Disable WordPress XML-RPC for Better Security”

  1. Thanks for this article. I just want to add that there are free online tools for testing XML-RPC on any site. Just enter the URL of your xmlrpc.php file and they will tell you how your site responds. Here are a couple of free XML-Validation services:

    https://xmlrpc.blog/
    https://xmlrpc-check.hostpress.me/

Leave a reply

Name and email required. Email kept private. Basic markup allowed. Please wrap any small/single-line code snippets with <code> tags. Wrap any long/multi-line snippets with <pre><code> tags. For more info, check out the Comment Policy and Privacy Policy.

Subscribe to comments on this post

Welcome
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
The Tao of WordPress: Master the art of WordPress.
Thoughts
RIP ICQ
Crazy that we’re almost halfway thru 2024.
I live right next door to the absolute loudest car in town. And the owner loves to drive it.
8G Firewall now out of beta testing, ready for use on production sites.
It's all about that ad revenue baby.
Note to self: encrypting 500 GB of data on my iMac takes around 8 hours.
Getting back into things after a bit of a break. Currently 7° F outside. Chillz.
Newsletter
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.