Adding WordPress REST API Security To Basic CRUD Operations

Work has been underway adding REST API functionality to the Store Locator Plus plugin.   Most people are familiar with the basic concept of using REST to fetch data from a remote server.   We use this every day when surfing the web using the basic premise of an HTTP GET protocol.   In short this is the simplest form of a REST “read” operation.   Go here, get this thing and show it to me.

REST APIs get more exciting when  you talk about adding basic create/update/delete operations proving the full CRUD functionality via the REST protocol.    The issue with using REST for these operations , especially via the WordPress REST API , is that you are now exposing your data via  service that anyone with even a touch of technical prowess can now create, update, or delete data elements from your site.     In the case of our locator plugin, we don’t want any random person to send a simple HTTP request to our server and delete a location.

The WordPress REST API provides a simple mechanism for adding security to these types of requests.   It uses the built-in WordPress user authentication and roles-and-capabilities to ensure a user has permission to alter the specific object, in our case location data, before handling the REST request.   To employ this security you will need two things;  A plugin that manages authentication requests  and the addition of a permission_callback parameter to your register_rest_route() call within your plugin/theme class that is managing your REST API.

The first part, adding a plugin, is easily handled by fetching one of the git repositories listed at the WordPress REST API documentation site.   You can choose either Basic Authentication (very weak security) or oAuth (much better option).   Using Basic Authentication is great for development and is what I use when testing RESTful services via phpStorm 2016 with its built-in RESTful service applet.

The second part, adding a permission_callback parameter, is done in the coding of your plugin or them that is managing your REST requests.   This can be handled using a simple anonymous function that returns the results of the WordPress current_user_can() function.     In Store Locator Plus we check to make sure the the user, authenticated with one of the above plugins as part of the source of the REST request, has the capability  of ‘manage_slp_user’ assigned.   By default this is assigned to all admin users when Store Locator Plus is installed.   The register_rest_route call looks like this:

    /**
     * Add a single location.
     *
     * Requires authentication.
     *
     * @route   wp-json/store-locator-plus/<v2+>/locations
     * @method  WP_REST_Server::EDITABLE (POST, PUT, PATCH)
     *
     * @params  string  sl_store        required , name of store
     * @params  string  <field_slug>    optional, other store data. Field slugs can match base or extended data fields.
     *
     * @returns WP_Error | WP_REST_Reponse
     */
    register_rest_route( SLP_REST_SLUG . '/' . $version, '/locations/', array(
        'methods'               => WP_REST_Server::EDITABLE,
        'callback'              => array( $this, 'add_location' ) ,
        'permission_callback'   => function () { return current_user_can( 'manage_slp_user' ); } ,
        'args'                  => array(
            'sl_store'  => array( 'required'    => true ),
        )
    ) );

This setup will check that the REST request has passed authentication and that the user identified with the request has the manage_slp_user capability before executing the add_location method in our REST API class.

Adding security on your POST/PUT/PATCH REST requests is as simple as that.

There are a lot of other tricks built into the WordPress REST API. Keep track of this blog to watch for more articles on WordPress development as I share what I’ve learned each week.