WordPress Disabling XML-RPC By Default With 2.6—Good or Bad?

XML-RPC is a protocol that allows third-party applications like Windows Live Writer and Ecto to post to a system supporting it. In this case, WordPress is the application that supports XML-RPC, but the WordPress development team has decided that they will disable XML-RPC by default starting with WordPress 2.6.

Daniel Jalkut, founder of Red Sweater Software, LLC., believes that it might help with reducing security risks, but it might have adverse effects for those who use applications that depend on XML-RPC:

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.

As a user who personally likes to make use of the XML-RPC system, I must say that I am disappointed with this decision. I am not exactly sure of the security implications, but I do agree that the system should be fixed, not simply disabled by default.

Daniel also brought up made an excellent point about the security of WordPress:

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!

Well, all that reflects my thoughts exactly.

Daniel does benefit from having the XML-RPC system enabled—he is the founder of the company that develops MarsEdit. It is in his company’s best interest for this feature to be enabled by default. So, there is a conflict of interest, but even though there is a conflict, I believe his points to be valid and his words to be truthful.

Of course, you could always just enable the XML-RPC option. It is fine for those who run their own blog, but in other instances, it could cause some serious issues and confusion.

What do you think about all this? Many of you who use desktop, browser, or any other third-party application to post content to WordPress will be affected. Voice your opinion!

5 thoughts on “WordPress Disabling XML-RPC By Default With 2.6—Good or Bad?

  1. Actually Brian, they must of had a change of heart because XML RPC is only disabled now for fresh installs. Upgrades will continue to have the feature enabled.

  2. As I sat waiting for my car’s air conditioning to be fixed, I tried to setup my business ideas blog on Live Writer. I’ve used it on my other blogs, but just never had posted anything there from my laptop before (I also use a desktop PC). It came back saying something about not supporting XML-RPC and I just shrugged it off figuring it was either the dealer’s wireless connection, or the protection product I use for public hotspots.

    Then, I was going through my feeds and I happened to see the title, and thought, “Hey that acronym looks familiar.” I agree with you that if there is a security issue, then the issue should be fixed, downgrading the feature set isn’t the answer. At the very least, full honest disclosure would be nice. I’m not talking about “WordPress 2.6 disables XML-RPC by default.” Most people won’t know what that means. I’m talking about a REAL disclosure. “WordPress 2.6 is not compatible with Windows Live Writer, BlogDesk, or other offline writers by default.” Spell it out like that, and you’ll have plenty of webmasters not bothering to upgrade. My guess is that this is a security “upgrade” that won’t make it past 2.6.1

  3. I haven’t had a lot of time to think about this one, but on the whole I’d say it is probably a safe way to do things.

    But I may change my mind once i look into it a bit more

  4. James, I saw this issue come to light via the WP-Hackers mailing list and I have a post written about the issue which should go public today on WLTC. Interesting how you and I have written about the same topic at the same time. Seems to happen more often than not.

    Anyways, here is a brief excerpt from the post:

    So far, it looks like the consensus is that, the option has to be disabled only for those who are installing WordPress for the first time. As for upgrading, the option should stay on by default.

    It’s a small change that on the surface, appears to be positive and will increase the security of WordPress installations but on the flip side, the WordPress team could be opening themselves up to a large number of complaints in regards to why something that used to work is now broken. This in turn may lead to people filing errouneous bug reports.

  5. Personally, I really do think it is just one of those quick band-aid type fixes. It is a common thing. The question I have is will this also affect WordPress upgrades? I can only hope it doesn’t. I can already see the influx of complaints on WordPress’s forums.

Comments are closed.