The WordPress REST API is a powerful tool that allows developers to interact with their sites programmatically. However, a common concern for developers moving from a local environment to production is data visibility. By default, many WordPress REST API endpoints, such as /wp-json/wp/v2/users/, are accessible to anyone with the URL. This can expose registered usernames and other metadata that you might prefer to keep private.
In this guide, we will explore whether the REST API is safe for production, how to restrict access to specific data using permission callbacks, and how to implement a global lock on your API for unauthorized users. Understanding these security measures is essential for any modern WordPress developer looking to build robust, secure applications.
Is the WordPress REST API Production-Ready?
The short answer is yes. The WordPress REST API has been part of the core software for years and is used by millions of sites, including high-traffic enterprise environments. However, 'production-ready' does not mean 'configured for your specific privacy needs' out of the box.
One of the most frequent concerns is the visibility of the users endpoint. While seeing a list of users might feel like a security breach, it is important to remember that server responses are not inherently vulnerabilities. A read-only response showing public data (like a display name or gravatar) is standard behavior. The real risk occurs if your site allows weak passwords; in that case, exposing usernames gives a malicious actor half of the login credentials. Security in the REST API is less about hiding the existence of data and more about ensuring that sensitive actions and private data require proper authentication.
Restricting Access via Permission Callbacks
The most effective way to secure a REST API endpoint is through a permission_callback. This is a function associated with an endpoint that checks if the current user has the necessary capabilities to perform the requested action.
When registering a custom route, you should always include this check. Here is a basic example of how a permission check looks within a request handler:
if ( 'edit' === $request['context'] && ! current_user_can( 'list_users' ) ) {
return new WP_Error(
'rest_forbidden_context',
__( 'Sorry, you cannot view this resource with edit context.' ),
array( 'status' => rest_authorization_required_code() )
);
}
By returning a WP_Error with the status code provided by rest_authorization_required_code(), the API will automatically send a 401 (Unauthorized) or 403 (Forbidden) response to the client.
Advanced Protection: Extending the REST Controller
If you are working with custom post types and want to implement strict access control, the cleanest architectural approach is to extend the WP_REST_Posts_Controller. This allows you to override the default permission logic for an entire post type.
First, you define your custom controller class:
class My_Private_Posts_Controller extends WP_REST_Posts_Controller {
/**
* The namespace.
*/
protected $namespace;
/**
* The post type for the current object.
*/
protected $post_type;
/**
* Rest base for the current object.
*/
protected $rest_base;
/**
* Register the routes for the objects of the controller.
*/
public function register_routes() {
register_rest_route( $this->namespace, '/' . $this->rest_base, array(
array(
'methods' => WP_REST_Server::READABLE,
'callback' => array( $this, 'get_items' ),
'permission_callback' => array( $this, 'get_items_permissions_check' ),
'args' => $this->get_collection_params(),
'show_in_index' => true,
),
array(
'methods' => WP_REST_Server::CREATABLE,
'callback' => array( $this, 'create_item' ),
'permission_callback' => array( $this, 'create_item_permissions_check' ),
'args' => $this->get_endpoint_args_for_item_schema( WP_REST_Server::CREATABLE ),
'show_in_index' => true,
),
'schema' => array( $this, 'get_public_item_schema' ),
) );
register_rest_route( $this->namespace, '/' . $this->rest_base . '/(?P<id>[\d]+)', array(
array(
'methods' => WP_REST_Server::READABLE,
'callback' => array( $this, 'get_item' ),
'permission_callback' => array( $this, 'get_item_permissions_check' ),
'args' => array(
'context' => $this->get_context_param( array( 'default' => 'view' ) ),
),
'show_in_index' => true,
),
array(
'methods' => WP_REST_Server::EDITABLE,
'callback' => array( $this, 'update_item' ),
'permission_callback' => array( $this, 'update_item_permissions_check' ),
'args' => $this->get_endpoint_args_for_item_schema( WP_REST_Server::EDITABLE ),
'show_in_index' => true,
),
array(
'methods' => WP_REST_Server::DELETABLE,
'callback' => array( $this, 'delete_item' ),
'permission_callback' => array( $this, 'delete_item_permissions_check' ),
'args' => array(
'force' => array(
'default' => true,
'description' => __( 'Whether to bypass trash and force deletion.' ),
),
),
'show_in_index' => false,
),
'schema' => array( $this, 'get_public_item_schema' ),
) );
}
/**
* Check if a given request has access to get items
*/
public function get_items_permissions_check( $request ) {
return current_user_can( 'edit_posts' );
}
}
After creating the controller, you must tell WordPress to use it when registering your custom post type. You do this by setting the rest_controller_class argument in the register_post_type function:
add_action( 'init', 'my_book_cpt' );
function my_book_cpt() {
$args = array(
'public' => true,
'show_in_rest' => true,
'rest_base' => 'books-api',
'rest_controller_class' => 'My_Private_Posts_Controller',
'supports' => array( 'title', 'editor', 'author' )
);
register_post_type( 'book', $args );
}
This method ensures that any request to your custom post type endpoints will run through your custom permission logic, requiring the user to be authenticated and authorized.
The Global Option: Blocking All Public REST API Access
In some scenarios, you may want to completely disable public access to the REST API, requiring authentication for every single request. This is particularly useful for headless WordPress sites or internal intranets where no data should be public.
You can achieve this by hooking into rest_api_init and checking the user's login status:
add_filter( 'rest_api_init', 'rest_only_for_authorized_users', 99 );
function rest_only_for_authorized_users($wp_rest_server){
if ( !is_user_logged_in() ) {
wp_die('Sorry, you are not allowed to access this data.', 'Unauthorized Access', 403);
}
}
While this is effective, use it with caution. Some plugins and core WordPress features (like the Block Editor) rely on the REST API. If you block access globally, you must ensure that your administrative sessions and legitimate external applications have a way to authenticate, such as using Application Passwords or JWT (JSON Web Tokens).
Frequently Asked Questions
Can I hide only the /users endpoint without affecting other parts of the API?
Yes. You can use the rest_endpoints filter to unset specific routes or apply a custom permission callback specifically to the wp/v2/users namespace. This allows you to keep your posts and pages public while protecting user data.
Does disabling the REST API improve performance?
Generally, no. The REST API only runs when a request is made to the /wp-json/ prefix. Simply having it enabled does not consume significant resources for standard page loads. If you are worried about bot traffic hitting your API, a firewall or security plugin is a better solution than disabling the API entirely.
How do I authenticate external applications if I hide my endpoints?
WordPress provides several methods for authentication. For simple integrations, 'Application Passwords' (available in Core) are highly recommended. For more complex decoupled applications, using a JWT plugin is the industry standard for secure, stateless authentication.
Wrapping Up
Securing your WordPress REST API endpoints is a balance between accessibility and privacy. While the API is safe for production use, you should always evaluate which data needs to be public. For custom data, always use permission_callback. For sensitive post types, consider extending the WP_REST_Posts_Controller. And if your site's data must remain strictly private, a global authentication check is your best line of defense.
By following these best practices, you can leverage the full power of the WordPress REST API without exposing your site to unnecessary risks. Always verify your implementation against the latest WordPress documentation, as the REST API continues to evolve with every major release.
