OM DENNE EPISODE
WordPress has long prioritized extensibility and openness, which is why it introduced the REST API (also referred to as the JSON API). This feature makes it easier for developers to build applications that interact with WordPress content in a standardized way, whether to fetch posts, update settings, or integrate with other platforms. However, not all of these capabilities are ideal for public consumption, especially when it comes to exposing sensitive information such as registered user data.
One commonly overlooked security concern is the /wp/v2/users REST endpoint. If you navigate to that path on your WordPress site, you’ll see a list of your users. By default, this endpoint allows unauthenticated visitors to fetch a list of user accounts on the site, typically exposing usernames, display names, and user IDs. While passwords and emails are not revealed, the public exposure of usernames is a known vector for brute force and enumeration attacks. Knowing a valid username is half the battle for an attacker attempting to gain access through credential stuffing or login automation.
Even though WordPress doesn’t show passwords, making usernames public can seriously weaken your site’s defenses. Here’s why this practice should be avoided:
- Credential Stuffing and Brute Force Attacks: With usernames in hand, attackers can use automated tools to attempt password logins.
- Targeted Phishing: A known list of users (especially administrators or editors) can become the focus of social engineering or phishing campaigns.
- Enumeration for Reconnaissance: Exposing user data helps attackers map your site and assess potential vectors for privilege escalation or plugin abuse.
Yes, and that’s an important distinction. The WordPress REST API is used not just by third-party applications, but also by the WordPress core itself. For example, the block editor (Gutenberg) relies on REST endpoints to manage blocks, autosaves, and previews. Disabling the REST API entirely would break many aspects of your site for both admins and users.
The solution isn’t to remove the REST API altogether, but rather to harden specific endpoints like /wp/v2/users, so that they only return data for authenticated users with appropriate permissions. That way, the REST API continues to power the admin dashboard and plugins as intended, but keeps sensitive data off-limits to anonymous users.
The most targeted and performance-friendly way to secure the user’s endpoint is by modifying its permission callback, essentially changing the rules on who gets to view it.
You can do this in two ways: by adding code to your child theme’s functions.php file or by creating a simple custom plugin.
functions.php
Paste the following snippet into your child theme’s functions.php file. This code restricts access to the user list and user detail endpoints unless the visitor can edit posts—i.e., they’re a logged-in contributor, editor, or admin.
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( isset( $endpoints['/wp/v2/users'] ) ) {
$endpoints['/wp/v2/users'][0]['permission_callback'] = function () {
return current_user_can( 'edit_posts' );
};
}
if ( isset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] ) ) {
$endpoints['/wp/v2/users/(?P<id>[\d]+)'][0]['permission_callback'] = function () {
return current_user_can( 'edit_posts' );
};
}
return $endpoints;
} );
This allows your backend to keep functioning properly for logged-in users while preventing unauthorized access to user account metadata.
Option 2: Create a Simple PluginIf you’d prefer not to rely on your theme’s functions.php file—especially if you’re using a child theme or plan to switch themes—you can use the same code as a lightweight plugin:
- In your WordPress directory, go to
/wp-content/plugins/ - Create a new folder, for example:
disable-public-users-endpoint - Create a new folder file, for example:
disable-public-users-endpoint.php - Paste the following code:
<?php
/*
Plugin Name: Disable Public Users Endpoint
Description: Restricts access to the REST API users endpoint to logged-in users with 'edit_posts' capability.
Version: 1.0
Author: Douglas Karr
Author URl: https://dknewmedia.com
*/
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( isset( $endpoints['/wp/v2/users'] ) ) {
$endpoints['/wp/v2/users'][0]['permission_callback'] = function () {
return current_user_can( 'edit_posts' );
};
}
if ( isset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] ) ) {
$endpoints['/wp/v2/users/(?P<id>[\d]+)'][0]['permission_callback'] = function () {
return current_user_can( 'edit_posts' );
};
}
return $endpoints;
} );
- Save the file and activate the plugin via the WordPress admin.
This approach is safer for long-term maintainability and can be version-controlled like any other plugin.
Testing Your ChangesOnce you’ve added the code or activated your plugin, you can test it by visiting:
https://yoursite.com/wp-json/wp/v2/users
If you’re not logged in, the response should now be a 403 Forbidden error. If you are logged in with appropriate permissions, the endpoint will still return user data.
The WordPress REST API is an essential tool for modern development, but it shouldn’t come at the cost of basic security hygiene. By default, the open /users endpoint is a potential liability that’s easy to overlook—especially on smaller sites where security is assumed rather than enforced.
Locking it down is a minor tweak with significant benefits: improved privacy, lower attack surface, and a clearer signal that your site is actively hardened against standard exploitation techniques. Whether you insert a few lines into functions.php or wrap it as a plugin, this is a best practice every WordPress admin should consider.
©2025 DK New Media, LLC, All rights reserved | Disclosure
Originally Published on Martech Zone: WordPress: Why the JSON API User Endpoint is a Risk and How to Secure Your Site
