TLDR;
XML-RPC is outdated, but still activated by default. It poses a security risk. Think about disabling it. Use the newer REST-API instead.
History
- In 2012 XML-RPC was enabled by default with WordPress 3.5 and the introduction of the WordPress mobile app.
- In 2015, WordPress core introduced a new REST API for interacting with mobile applications and other platforms.
- However, XML-RPC is still enabled in WordPress, and the xmlrpc.php file is still located in the core software directory.
https://www.hostinger.com/tutorials/xmlrpc-wordpress#XML-RPC_nowadays
Why disable it?
The issue isn’t with XML-RPC in itself but instead with how the file can be abused to launch cyberattacks on your site.
Brute-force attacks
Purpose: To gain entry to your site.
How to do: An attacker will try to access your site using xmlrpc.php by using various username and password combinations. They can effectively use a single command to test hundreds of different passwords, allowing them to bypass security tools that typically detect and block brute-force attacks.
DDoS attacks
Purpose: Taking sites offline through a DDoS attack.
How to: Hackers would use the pingback feature in WordPress to send pingbacks to thousands of sites instantaneously. This feature in xmlrpc.php gives hackers a nearly endless supply of IP addresses over which to distribute a DDoS attack.
https://www.hostinger.com/tutorials/xmlrpc-wordpress#XML-RPC_nowadays
How to disable
Option #1 .htaccess
# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
Option #2 Plugin
Option #3 wp-config.php
This method is not recommended, because it does not disable XML-RPC completely.
add_filter( ‘xmlrpc_enabled’, ‘__return_false’ );
From the wordpress documentation:
Contrary to the way it’s named, this filter does not control whether XML-RPC is fully enabled, rather, it only controls whether XML-RPC methods requiring authentication – such as for publishing purposes – are enabled.
Further, the filter does not control whether pingbacks or other custom endpoints that don’t require authentication are enabled. This behavior is expected, and due to how parity was matched with the enable_xmlrpc UI option the filter replaced when it was introduced in 3.5.
https://developer.wordpress.org/reference/hooks/xmlrpc_enabled/
How to test
- Call it directly
- Example for this website:
https://scratchpad.wordpressspezialist.de/xmlrpc.php - If the result ist “Access forbidden!” or “403 error”, then XML-RPC is successfully disabled
- Example for this website:
- Or you can try any XML-RPC Validator: https://iptools.net.au/xmlrpc-tester
- Keep in mind that you want the validator to fail and tell you that XML-RPC services are disabled.