WordPress cookies based protection for the WordPress REST API

Introduction

Use this guide if you want to protect your WordPress REST API endpoints with a combination of a WordPress cookie and a nonce for delegated access. If you enable WPO365's WordPress cookie based endpoint protection for the WordPress REST API then applications requesting data from any of the protected endpoints will either receive a 401 (unauthorized) or 403 (forbidden) error, unless they present a valid WordPress authentication cookie and a valid WordPress REST nonce .

Cookie authentication is the standard authentication method included with WordPress. When you log in to your dashboard, this sets up the cookies correctly for you, so plugin and theme developers need only to have a logged-in user. However, the REST API includes a technique called nonces to avoid CSRF issues. This prevents other sites from forcing you to perform actions without explicitly intending to do so. This requires slightly special handling for the API. For further details please refer to the WordPress REST API Handbook (see https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/ for details).

WordPress already implements this type of protection for its out-of-the-box REST API endpoints that allow access to sensitive data, for example the /wp-json/wp/v2/users endpoint. However, the WPO365 | LOGIN plugin allows administrators to protect endpoints that out-of-the-box are not protected, for example /wp-json/wp/v2/posts. To restrict access to those endpoints that otherwise are available to anonymous users makes sense if you have restricted access to front-end posts and pages, for example if your WordPress website contains internal or confidential information for employees or partners (please refer to the documentation for the configuration of the Authentication scenario).

Please note

The nonce must be passed to the API via the X-WP-Nonce header and that the _wpnonce data parameter is not supported.

This article aims to explain the following steps needed to update the configuration of your WordPress website's App registration in Azure AD to be able to configure the Azure AD based protection for your WordPress REST API:

Before you start

You are an Administrator for your WordPress website.

Enable WordPress cookie based endpoint protection

Complete the following steps to enable WordPress cookie based endpoint protection for your WordPress REST API with the WPO365 plugin.

Open a new browser tab and go to WP Admin > WPO365 > Integration.
Scroll down to WordPress cookie based protection for the WordPress REST API.
Check the option to Enable cookie based WordPress REST API protection.
Protect an endpoint by entering the following details:
- The endpoint's path e.g. /wp-json/wp/v2/users/me. If you enter an incomplete path e.g. /wp-json/wp/v2 then be aware that all requests to endpoints starting with /wp-json/wp/v2 will be subject to the protection defined by this configuration
- The HTTP methods for which the protection should be activated as a comma separated string e.g. post or get, post.
If you want to Block all other WordPress REST endpoints you can check the corresponding option.
Click Save configuration.

Below is a screenshot of an exemplary WordPress cookie based protection for the WordPress REST API configuration.

Important

If you selected the Intranet Authentication scenario (on the plugin's Single Sign-on configuration page) then the plugin will - by default - block access to all your WordPress REST API endpoints. To work-around this, you must add the path of endpoints that you want to protect to the list of Pages freed from authentication (also on the plugin's Single Sign-on configuration page). Also refer to the online documentation for the Authentication scenario documentation.

Access a protected endpoint

Once the endpoint protection has been enabled using the WPO365 configuration pages, you can test using a tool such as Fiddler (Composer) or Postman . Requests that try to access data or functionality using a protected endpoint will need to present a valid WordPress cookie and an additional X-WP-Nonce header with the nonce (shown below is a screenshot of such a header produced using the Fiddler tool).