WordPress REST API – developing a precautionary

Back over a year ago now the WordPress team at Devon County Council started exploring a RESTful API. In WordPress 4.4 they introduced an embed extension to embed content into other website. This was the start of the API.

WordPress 4.7 has just landed and now it has a full RESTful API built right into the core. It is now possible to display all your content by using the new endpoint routes, posts, pages, etc. This is really great, we can now do cross website querying for content using the API. This is just the tip of the iceberg of things that the API can be used for.

The bad side of this is that all your content is now widely available in an easy to consume JSON format. In addition it is now possible to get a list of all your site users that have published content on the website. This means that hacking could be made a bit easier if proper safeguards are not put in place for username and display name.

Out of the box WordPress lets you set your display name the same as your username. This hasn’t been much of a problem for us in the past as we generally have not advertised author’s names in our themes. With the API you can do a quick public query to find out the users of all published posts.

We use the iThemes Security Pro plugin to secure our websites, within this plugin there are 2 options that can help us here:

  1. Force Unique Nickname – This forces users to choose a unique nickname when updating their profile or creating a new account which prevents bots and attackers from easily harvesting user’s login usernames from the code on author pages. Note this does not automatically update existing users as it will affect author feed urls if used.
    1. Disable REST API – The REST API is disabled on the site. If your site does not use the REST API (there are very few plugins, themes, or other tools that currently use the REST API), we recommend disabling it for now.
    2. Require Admin Privileges – The REST API can only be used by logged in users with admin-level privileges. This allows privileged users to test and develop with the REST API without allowing anonymous access to the data.

These 2 options are very helpful. The first option hopefully fixes the displaying of the usernames. The second will restrict the REST API on the current site.

We run a number of standalone sites and these options fix the current possible leak in user information.

However, we also run a number of WordPress multisites. We would like to use the API on a couple of the subsites and also add extra custom posts to the API and create more.

So, option 1 above is perfect for the multi site installation but option 2 is a bit overkill for our multi use, so we have developed a plugin to remove parts of the API – this is mainly the users endpoint route.

Right now we are in beta testing for the custom plugin and the API, but if this is successful, we will be deploying this across all our multi sites.

Once we have completed testing and deployed I’ll write again about what we have learned.

Tim Barrett

I am a frontend developer for Devon County Council. I work mainly on WordPress and PHP.

More Posts

Follow Me:
Google Plus

Be the first to Comment

Your e-mail address will not be published. Required fields are marked *


Comments are held for moderation. House rules