What is the WordPress REST API?

Table of Contents 5 sections

What is the WordPress REST API?

The WordPress REST API is a standardised interface built into WordPress core (since version 4.7) that exposes site data and functionality through a set of HTTP endpoints returning JSON responses. REST, which stands for Representational State Transfer, is an architectural style that uses standard HTTP methods (GET, POST, PUT, DELETE) to perform operations on resources. The WordPress REST API maps these methods to WordPress content types, allowing external applications to read, create, update, and delete posts, pages, users, comments, taxonomies, and other WordPress objects programmatically.

The REST API transformed WordPress from a traditional server-rendered CMS into a flexible application platform capable of powering headless architectures, single-page applications, mobile apps, and complex integrations with third-party services. Endpoints are accessible at /wp-json/wp/v2/ by default, and developers can register custom endpoints to expose additional data or functionality. While this openness enables powerful use cases, it also introduces a significant attack surface that must be carefully managed.

How the REST API Works

The WordPress REST API follows a route-based architecture where each endpoint corresponds to a specific resource type. For example, /wp-json/wp/v2/posts returns a collection of published posts, /wp-json/wp/v2/users returns user data, and /wp-json/wp/v2/pages/42 returns a specific page by ID. The API supports query parameters for filtering, sorting, pagination, and field selection, making it highly flexible for consuming applications. Requests can include authentication credentials to access protected resources or perform write operations.

The API uses a permission system that mirrors WordPress capabilities. Unauthenticated requests can only access publicly available data, while creating, updating, or deleting resources requires authentication with appropriate user capabilities. WordPress supports multiple authentication methods for the REST API, including cookie-based authentication (for same-origin requests in the admin panel), application passwords (introduced in WordPress 5.6), and third-party authentication plugins that implement OAuth or JWT tokens. Each request is validated against both the authentication credentials and the WordPress capability system.

Security Risks of the REST API

The most widely discussed security concern with the WordPress REST API is user enumeration. By default, the /wp-json/wp/v2/users endpoint is publicly accessible and returns a list of all users who have published at least one post, including their usernames, display names, and avatar URLs. Attackers routinely use this endpoint to harvest valid usernames, which they then use in brute-force login attacks. This single endpoint has been responsible for countless compromised WordPress sites because it eliminates the guesswork from credential attacks.

Beyond user enumeration, an improperly secured REST API can expose sensitive content, allow unauthorised data modification, or serve as an entry point for injection attacks. In 2017, a critical vulnerability in the REST API (affecting WordPress 4.7.0 and 4.7.1) allowed unauthenticated attackers to modify any post on a site by sending a crafted request to the posts endpoint, leading to the defacement of approximately 1.5 million WordPress sites. Custom REST API endpoints developed by plugins may also introduce vulnerabilities if they fail to implement proper permission checks, input validation, or output sanitisation.

Securing the WordPress REST API

The first step in securing the REST API is restricting access to sensitive endpoints. The user enumeration endpoint should be disabled or restricted to authenticated administrators using the rest_authentication_errors filter or a security plugin. Sites that do not use the REST API for front-end functionality can restrict the entire API to authenticated users only, though this may break compatibility with plugins like Gutenberg that rely on the API internally. A more surgical approach is to selectively disable specific endpoints while keeping those required by the admin panel.

All custom REST API endpoints should implement proper permission callbacks using the permission_callback parameter in register_rest_route(). Never use __return_true as a permission callback in production, as this makes the endpoint accessible to anyone. Input data should be validated and sanitised using the validate_callback and sanitize_callback parameters, and all output should be escaped appropriately. Rate limiting API requests, implementing authentication token expiration, and monitoring API access logs for anomalous patterns are additional measures that significantly reduce the REST API attack surface.

REST API Security Best Practices

For sites that expose REST API endpoints to external consumers, implementing HTTPS is non-negotiable, as API requests often carry authentication tokens and sensitive data. Application passwords, introduced in WordPress 5.6, provide a secure way to grant API access to external applications without sharing the user's primary password. Each application password can be revoked independently, and they are hashed before storage, limiting the damage from a database compromise.

Developers should follow the principle of least privilege when designing API endpoints, exposing only the minimum data and capabilities required for the intended use case. Custom endpoints should never expose raw database queries or internal system information. Implementing CORS (Cross-Origin Resource Sharing) headers restricts which domains can make API requests, preventing unauthorised cross-origin access. Regular security audits of all registered REST routes, combined with automated testing for authentication bypass and injection vulnerabilities, help ensure the API remains secure as the site evolves.