Why I’m Reconsidering The Jetpack Plugin For WordPress

The Jetpack plugin is one of the most staple plugins on any WordPress installation. Ever since its release in 2011, it’s been a runaway hit with millions upon millions of downloads. It’s developed and maintained by Automaticc themselves, and so doesn’t run into any trust issues. I’ve been a staunch advocate of Jetpack for years – I use it myself on my site, and it’s a great plugin. It constantly adds new features, they fix bugs regularly, and issue maintenance releases all the time.

And yet…I’ve started to reconsider the wisdom of having Jetpack on my site. I’ll try and explain my reasons below.

1. XML-RPC is a Major Sticking Point

The number one vector for people trying to attack your website, is XML-RPC. Take a look at your server logs, and I guarantee you’ll see a whole bunch of requests trying (and failing hopefully) to brute force your credentials via XML-RPC.

Ideally, we’d just disable XML-RPC outright. Unfortunately, Jetpack requires XML-RPC for a variety of reasons, and they refuse to change their access policies. In a support thread, the team compared disabling XML-RPC to selling your car. They think it’s that important.

But I just don’t see it. Most other plugins don’t rely on XML-RPC like this, and the only reason to have it on your site is for Jetpack. Security plugins like iThemes have options to disable XML-RPC, with the caveat that you should leave it on if you have Jetpack.

Some will say that a well-configured WordPress installation won’t have problems with XML-RPC due to brute force attack prevention – and username/passwords should be impossible to guess anyway. But I think it’s silly to allow a random attacker to be able to place a strain on my database by submitting username/password combinations in the first place without any restrictions.

We can protect our regular login pages via obfuscation or via re-CAPTCHAS. But there’s no such restriction for an XML-RPC attack. And for this reason, I think it’s best disabled.

Workaround Are Shaky

There are ways to disable XML-RPC for everyone except Jetpack. I’d written an earlier post about how to whitelist Jetpack’s IP address range. But I’m not convinced that this is a long-term solution. Jetpack’s IP ranges are subject to change. And unlike Cloudflare, they don’t have a text file with the current IP ranges.

So, for these reasons, I’m not happy with the XML-RPC vector on my site.

2. Jetpack Does Too Much – Single Point of Failure

My focus these days has been to ensure site stability and make it less fragile. This sometimes means cutting back on the “efficiency” angle and building up redundancies. One of the things I’ve been looking at, is separating plugin functionality. I used to like Jetpack doing everything for me. Including:

1. Lazy image loading
2. Brute force prevention
3. Statistics
4. CDN (partially)

and much, much more. I liked the simplicity and the single interface. However, my philosophy regarding plugins these days has become “Do one thing and do it well”. I would rather have 5 different plugins, performing five different tasks rather than one plugin that does it all.

The reason is that I want to eliminate single points of failure. If I use Jetpack for everything, then a single error in Jetpack takes away everything. So I want to reduce the possibility of that happening.

This isn’t a knock against Jetpack. I love their interface, and the sheer functionality they pack into a single plugin is phenomenal. It’s just that my design philosophy contradicts what they’re trying to do.

Bottom Line

Jetpack isn’t going anywhere. But they’ll win a lot more fans if they downgraded their reliance on XML-RPC. But the other problem is systemic. A plugin that tries to do so much, makes the site weak to a single, well-targeted error. And that’s not a chance I’m willing to take.