Part 2 in a series on working with the WordPress XML-RPC API with PHP.
A significant amount of hue and cry in the WordPress world surrounds security, and not without some cause; a poorly implemented install is susceptible to attack, especially in earlier versions.
Such protests are amplified when it comes to XML-RPC, the SOAP service used by WordPress to allow outside access for content management.
This is largely nonsense. The fact that 9 out of 10 WordPress installs have a well-known admin url (/wp-admin), and probably two-thirds of such installs have a administrator login with the user name “admin”, is a far greater vulnerability than the presence of an XML-RPC server at a known URL.
Because hey, at least XML-RPC limits what can be done to a WordPress install, and structures how you interact with it. It’s the difference between letting your crazy uncle live in the basement, versus giving him the keys to the house: He might burn the place down, either way, but at least you know he won’t steal the silver or make a mess of the living room.
In short, making XML-RPC secure involves the same steps as making WordPress secure, and if you properly secure your WordPress site, you need not fear what XML-RPC might do.
Basic WordPress Security
WordPress itself gives excellent guidance on securing an install. Let’s highlight the ones that are especially important in terms of XML-RPC:
- Strong usernames and passwords.
- Limited user permissions.
- Maintaining site backups, both database and wp-uploads.
- Using the minimal database permissions necessary.
- Logging XML-RPC access.
Let’s take those from the top.
Usernames and passwords: If you have a user named “admin,” change it. Don’t have usernames that are the same as author names. Use passphrases, not passwords.
Limited user permissions: Create a user specifically for your XML-RPC calls and give that user only the permissions he needs.
For example, if you just need to read posts, create a Subscriber. If you need to post content, make a Contributor or Author. If you have to have broad authority to change any content, make an Editor.
I would not do anything via XML-RPC that requires Administrator permission — namely, changing site options. But if you must, still make an admin user specific to XML-RPC, so you can at least log that activity.
Site backups: There are a number of site backup options out there. A variety of plugins will do scheduled database dumps, and even email them to you. There are also many FTP programs available that can be run on a schedule and used to download your site’s files to some other computer; one I have used is SyncBack Pro by 2BrightSparks.
For simplicity and peace of mind, you can always use VaultPress. The Lite plan costs $55 per year is perfectly adequate for disaster recovery. And yeah, it’s $55. But if you don’t think it’s worth it, you haven’t suffered a significant crash yet.
Minimal database permissions: This one requires a little behind-the-curtain tinkering and can become problematic, especially if you are constantly adding plugins that need database access. But for day-to-day operations, once you get WordPress installed, you should change your config file to employ a database user whose only permissions are SELECT, UPDATE, DELETE and INSERT. Details are in the Hardening WordPress post, linked above.
Logging: I use a plugin called Bluetrait Event Viewer (BTEV), which records pretty much everything going on in my install: Login attempts, the creation and editing of content, theme changes, plugin activation, etc. This shows up on my dashboard; the plugin can also email alerts or provide notices via RSS feed.
More Secure Than wp-admin
As I noted earlier in this post, XML-RPC is inherently more secure than the wp-admin directory, for two reasons:
Limited access: While someone who successfully authenticates against WordPress’s XML-RPC service can do real damage, especially if the compromised user has Administrator or Editor permissions, at the very least, XML-RPC can’t tinker with your themes or plugins. Someone who gains access via wp-admin as an Administrator is pretty much free to leave your blog a smoking hole.
Structured data: As we’ll see in future posts, XML-RPC is structured. Data has to be in a certain order, named a certain way, and in some cases of a certain type, in order for a request to be processed.
Over the last decade, there have been dozens of exploits that use junk input to successfully attack unpatched WordPress installs; but a handful of XML-RPC exploits.
Vigilance vs. Paranoia
I’m not saying you shouldn’t be vigilant about security in WordPress. You absolutely should.
My point is that there is nothing inherently insecure about XML-RPC, especially the way it is implemented in WordPress. To believe otherwise is ignorance at best, paranoia at worst.
A good WordPress install — and a properly managed website in general — is pessimistic about users, diligent about patching / updating and vigilant about monitoring. If you employ that attitude about your WordPress install in general, there’s no extra threat from XML-RPC.
All links in this post on delicious: https://delicious.com/dougvdotcom/wordpress-xml-rpc-and-php-security