WordPress To Disable Remote Access

June 24th, 2008

The WordPress developers have decided that, starting with WordPress 2.6, access to the XMLRPC and AtomPub-based remote publishing interfaces will be disabled by default. Users who wish to use a remote client such as MarsEdit will have to go out of their way to enable the required functionality in their blog’s settings.

There are good arguments for this, at least on the face of things. They can be packed into a nutshell: it may reduce the security risks of having these access points opened by default.

But in my opinion, there are also good arguments to be made for rejecting the change as a damaging and misguided solution.

First, and obviously near to my heart, is the fact that this marginalizes remote clients. For users who would find value in a remote client, this decision will put one more roadblock in their way. Historically, the remote editor interface is already compromised such that remote editors do not have access to all the same functionality as the web interface. With this change in place, things get even worse. While a screen-scraping application will easily log in and authenticate a fragile WordPress session via the web interface, the well-behaved API clients will be refused access by default. All in the name of improving security.

Second, and probably most important, is that this is not a fundamental security improvement. Consider a bank with two sets of automated cash machines: one for drive-through cars, and one for walk-up pedestrians. Two vastly different sets of customers are being served securely by different interfaces, yet the transactions are secure because they ultimately travel through the same bottlenecked safeguard. A fundamental design consideration on the part of the bank is that these two classes of customer are equally important, and each deserves unfettered access.

WordPress’s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.

Also worth considering: if a service is disabled by default for security considerations, what message does that send to people who choose to, or who are encouraged to turn the service back on? It sets up a perception of insecurity which may not even be warranted. If the remote publishing interfaces are insecure, they should be fixed, not merely disabled!

A Real Solution

If I’m so smart, what should WordPress be doing instead? A real security improvement would be bottlenecking all access to the blog’s vital authorized content, and making sure that the remote APIs and the web interface all go through the same interface.

In my opinion, an entire class of problems with WordPress (and other blogging systems) stems from this interface bifurcation. Establishing a single interface to WordPress would be comparable to the “pin code + card” interface at your bank. You pass through it by car, on foot, and even at the counter when they ask you to swipe before doing any transaction.

If you’ve only got one “real API” that touches the critically important data, then you’ve only got one door to secure. Furthermore, when all views into the blog are required to share the same API, suddenly none of them is deprived of functionality that the other has.

Imagine if the API that the web interface uses to access all features of a blog could be just as easily employed by MarsEdit or any other application you authorized. The end result would be lots less work “playing catch up” for the XMLRPC and Atom developers, and more time focusing on innovative and cool features for all blog users.

If this sounds like a pipe dream, it’s worth pointing out that one very popular web service is already employing this strategy, and it works brilliantly. Flickr, Yahoo’s incredibly popular photo sharing site, is built on the very same APIs it makes available to clients. This results in some truly incredible Flickr-enabled applications and web services. And you don’t see any sign of Flickr disabling access to their API, because there’s too much at stake.

If your web service only provides one, first-class API through which all access flows, then you’ve only got one point to secure, you’re likely to have feature parity across interfaces, and the risk of marginalizing one interface is dramatically decreased.

67 Responses to “WordPress To Disable Remote Access”

  1. Jonathan Wight Says:

    If the majority of WP users are not using the API at all, then wouldn’t the “disabled by default” security pattern make sense no matter how good the underlying security is? Even if WP replaced their current API with some imaginary infinitely secure system (and of course don’t bodge it up and introduce new security flaws along the way), if most users don’t need it, it shouldn’t be turned on by default.

    I see this as a good healthy, interim solution – and not some indication that the WP folks don’t have a clue what they’re doing (which may or may not be true).

    Obviously disabled by default will make it just that little bit harder for new WP users to get it working with MarsEdit. And I can see why you’re opposed to that from a business perspective. This WP feature will either increase your support costs (Help! ME doesn’t work with my new WP install!) and/or restrict your adoption amongst new WP users (Can’t get WP to work with ME, screw this POS).

    That will suck for you (and other API users) for sure, but raising this much FUD about it seems very disingenuous.

  2. Jens Alfke Says:

    @Matt — Great to hear that WP supports Atom Publishing nowadays! I’ve been out of the loop on the APP for a while, so I hadn’t heard the news yet.

  3. Mark Evans Says:

    As an Ecto user, the proposed change in 2.6 is a small aggravation but not a show stopper. As long as WordPress is clear about what people using third-party publishing tools need to do, that would be enough for me.


  4. Brian Layman Says:

    “WordPress’s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.”

    Umm no… you are misleading people into thinking this has to be done repeatedly.

    It is much more like, when you open a savings account, checking either the box that says you want an ATM Debit card and/or the box saying you want to access the account through the online site. Eliminating either of those options would make your money more secure.

    I agree that there is an issue with people upgrading and finding that MarsEdit doesn’t work. That is easily solved by keeping the XML interface off by default on new blogs, but not changing the behaviour for upgrades.

    That should be considered,

  5. alan Says:

    @I said: “It creates a situation where a single slip up means you’re compromised.”

    @Jens Alfke Says: I have no idea what you mean here.

    I was just pointing out that if you rely solely on perfect software engineering to secure something that you’re asking for trouble. The “slip up” refers to a bug getting into the codebase that causes a vulnerability that might be compromised

  6. Craig John Says:

    Thanks for the head’s up on version 2.6. It’s a shame they’re doing it that way around – your solution seems spot on!

    …let’s hope WordPress is listening!

  7. Douglas Karr Says:

    Why not just ASK the user in the upgrade process if they’d like to disable these options? Turning them off by default will kill many integrations inadvertently. It’s a terrible choice.

  8. Christina Warren Says:


    After I read your post, I was pretty peeved (for the same reasons you mentioned). Semantical arguments about the security benefits of default disabling aside (I don’t care), having to go through an extra step just so I can post in my blog — while a minor inconvenience — makes me worried about the long-term API support. And of course, is just one more thing I have to keep in my arsenal when doing unpaid tech support for friends/family who use WordPress and a blogging client.

    That said, if 2.6beta1 is any indication, for new installs anyway (upgrades didn’t get a notice but I also didn’t check to see if it disabled the feature by default) DO ask if you want to enable/disable remote blogging. The check box is unchecked, but it is there during the standard WordPress install screen. That, I can live with. If the same sort of screen could appear to upgrade users too — informing them of the change and letting them say yes or no (it could be on the upgrade.php page), this won’t be a huge deal for existing users.

    As for users who are installing WP for the first time, yes, it’ll require more work to get MarsEdit and others to work out of the box, but at least the setting is easy to find.

    Check it out: http://img.skitch.com/20080626-tumdstx1jh8ma8x4hdyjc12ych.png

  9. Daniel Jalkut Says:

    Christina: the bad news is that the WP team has since decided to yank that option from the startup process. They’re afraid it will cause too many users to inadvertently turn it on (sigh).

    But the good news is that they are talking now about putting an error message in for blog clients that attempt to connect, so that at least the user will have a chance of understanding why the client is not working as they expect.

  10. Christina Warren Says:

    Dude, that sucks. *sigh* indeed. I would rant about it, but I’m sure you’ve been there/done that. I do hope they include a HELPFUL error message so that users who upgrade and don’t spend their life following WordPress development can easily enable remote blogging.

  11. Julik Says:

    Wonderful. Of course it’s much easier to axe some setting instead of implementing something useful (like HTTP digest authentication around the RPC backend).

  12. Doug Stewart Says:

    Christina: Revision 8202 takes care of the messages. XML-RPC now tosses:

    $this->error = new IXR_Error( 405, sprintf( __( ‘XML-RPC services are disabled on this blog. An admin user can enable them at %s’), admin_url(‘options-writing.php’) ) );

    while APP tosses:

    $this->not_allowed( ‘AtomPub services are disabled on this blog. An admin user can enable them at ‘ . admin_url(‘options-writing.php’) );

    Brief, yes, but instructive, I think. Hopefully it’s enough.

  13. Taybin Says:


    all is forgiven. please come home. :)

  14. I Wordpress Themes Says:

    As for the security the idea of WP developers is not really good. As for the convenience of using the service it is not good too, especially for the users. I still do not understand the point of this innovation.

  15. Jerry Henderson Says:

    Wow. It requires checking exactly one radio button. Why all the fuss, Russ?

  16. Haiming Says:

    How to enable wordpress remote access? I have just installed a wordpress new version, and have the trouble to setup XML-RPC services.

  17. Voks Says:

    Isn’t it just possible to find a module for wordpress which allows API approach?

Comments are Closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.