WordPress XML-RPC is a system designed to make it easy for other systems to communicate with a WP site.
We’re going to explore what it is, what it lets you do, and why you might want to disable, and how.
Just what does WordPress XML-RPC do for you?
It provides an interface to communicate with your WordPress site.
It’s been turned-on by-default since WordPress 3.5 (circa 2012) and where it’s used will vary, from your iOS App, to letting other websites send “pingbacks” when they link to your articles.
But the need for XML-RPC has dramatically decreased, especially since the newer WP REST API has been built.
There’s no doubt about it, XML-RPC is a major API component of a WordPress site and depending on how your site is structured you may be using it and not even know. An example of this is the JetPack plugin (at the time of writing) that uses the XML-RPC API extensively.
Can someone attack my XML-RPC?
One of its features is the ability to send multiple commands using a single HTTP request. Handy, but not really when one of those commands could be a login authentication.
This means that with a single web request, an attacker can try hundreds of login username/password combinations. There isn’t any real-world application of such a feature for most of us. So there’s no good reason to leave this attack vector lying open unless we really need to.
Is XML-RPC being used on my site?
The only way to know this is to
- Examine your plugins and theme and see whether they make use of XML-RPC in their spec. An example of this is JetPack which uses XML-RPC extensively.
- Monitor traffic on your site We outline this below, under option #2. Shield has an integrated Traffic Monitor, and this will let you see hits to your XML-RPC and from there determine if it’s actually in-use.
Can you disable XML-RPC?
It’s technically possibly to disable it. But before you set about doing that, you need to determine if your site uses it or not (see later on under the section with disabling XML-RPC using Shield)
Let’s assume that you’ve done the research and decided that your site doesn’t need XML-RPC. Can you, and should you, disable it? Our opinion is that if it’s not being used, then there’s no upside to keeping it around.
If you’ve decided to disable it, we’re going to outline 2 of ways you can go about it.
- Blocking XML-RPC using CloudFlare (the easiest).
- Blocking XML-RPC using Shield Security Pro.
The 1st one is ideal because it blocks traffic before requests even touch your web server. We’ve been recommending CloudFlare for everyone years, for every domain they manage. If you’re on CloudFlare already, this will take only a few minutes to setup.
#1 – Steps to block WordPress XML-RPC using CloudFlare
All free CloudFlare plans come with 5 firewall rules, so there is no cost to you for creating the following rule:
- Log into CloudFlare and select the domain you want to manage.
- Select ‘Firewall’ from the main navigation.
- Click the button to create a Firewall rule
- Give your new rule a name – any name will do.
- Now you need to create rules to match requests that are specific to XML-RPC:
- Field: URI Path
- Operator: contains
- Value: /xmlrpc.php
- You can also add the following rule, though it’s not required. Beside the first rule you created, click the “And” button (not the ‘Or’!). If you click ‘Or’, you’re in trouble.
- Field: Request Method
- Operator: equals
- Value: POST
- Then you need to choose the action that CloudFlare will take. We recommend choosing ‘Block’.
- Then click ‘Save and Deploy’
And you’re done! XML-RPC requests to your WordPress site will be intercepted and blocked before they even reach your WordPress site.
Please note that CloudFlare is a powerful system and creating the Firewall blocking rule, incorrectly, could break normal access to your site. If you notice anything strange or broken as a result of this, you can delete the rule you just created and return the site back to normal.
#2 – Steps to block WordPress XML-RPC using Shield Security
Shield Security also provides the option to block any XML-RPC requests made to your site.
You can use Shield Security Pro to determine whether your site is actually using XML-RPC.
- Under the ‘Block Bad IPs’ module within Shield, find the option “XML-RPC Access” under the Probing Bots section and turn this on to ‘Audit Log Only’
- Monitor your Audit Trail logs for a few days to see if there are any legitimate requests to your XML-RPC. If you’re seeing traffic there and it’s legitimate, you may want to hold off disabling it. Otherwise proceed to the next steps.
- Select the sub-menu item
Settingsunderneath Shield Security
from the main WP menu.
Lockdownfrom the side menu on the following page.
- Under the sub-section
API & XML-RPCclick to turn-on the option that disables XML-RPC, and save.
How to verify your WP XML-RPC is disabled
After performing either of the steps above, you can verify XML-RPC is disabled quite easily.
If you don’t know the URL of your XML-RPC, you can find it by:
- Browsing to your WP Login URL. e.g. https://www.example.com/wp-login.php
- Remove “wp-login.php” from the URL and replace it with “xmlrpc.php”
With your XML-RPC URL, go to this site and test whether it can communicate with it. You’ll discover in a few seconds whether or not you’ve correctly disabled access to it.
Should you use Shield, or CloudFlare to disable XML-RPC?
We could obviously say “Shield is best” because we want you to think you can’t live without us, but in this case, CloudFlare is the better solution. Here’s why…
CloudFlare acts like a proxy, and this means that traffic is routed via their servers. If anyone tries to access your XML-RPC endpoint and you have the CloudFlare rule in-place, the request wont even register on your website. With CloudFlare, you’re blocking traffic long before it even touches your WordPress site. This is the best way to stop traffic you don’t want.
But it does no harm to use both settings. In-case you need to pause CloudFlare at a future date, Shield’s protection will kick-in and protect your site, too.
Comments and Feedback
We’ve covered in this article what XML-RPC is, why it might be used, and how you can disable it completely, and verify it’s been disabled.
Remember to always assess whether you need it disabled, and you follow the instructions carefully when doing so.
If you have any suggestions on this or improvements that can be make, please let us know in the comments below.
I only use this plugin to protect my site for more than one month now, and I am so happy with it. The developer is really responsive and gave me tips and clear explanations. This plugin really deserves more than 5 stars. Thanks for your amazing work!
Good options, great support
I esp like the ability to hide/rename the wp-admin login page. Couldn’t even guess the # of millions of fake requests stopped just by this feature.
Secures your website from malicious attacks. Thanks for this wonderful plugin 🙂
All in one for free
I’v just tried it yesterday. Really easy to use. Good explanations on the plugin dashboard and during all the security configuration process. Security functions that I did not even expected. I just did not protect the plugin itself (but it is a really good idea) : as english is not…