Your WordPress REST API Is Leaking User Data — Here’s the Fix
The WordPress REST API exposes your user list at /wp-json/wp/v2/users — no login required. Here's how to restrict it without breaking your site.
Open a new browser tab and visit yoursite.com/wp-json/wp/v2/users. No login, no authentication, nothing — just that URL.
If you haven’t restricted this endpoint, you’ll see a JSON array listing every author on your site. Names, slugs (often identical to login usernames), descriptions, avatar URLs, and links to their author archives. All publicly accessible. All indexed by search engines.
This is the WordPress REST API’s users endpoint, and it’s been open by default since WordPress 4.7.
What is the REST API users endpoint?
The WordPress REST API is a modern interface that lets applications interact with your WordPress site using HTTP requests. It powers the Gutenberg editor, the WordPress mobile app, and many plugins.
The /wp-json/wp/v2/users endpoint specifically returns a list of all users who have published content on your site. By default, it requires no authentication for read access — anyone can query it.
The response includes: user ID, display name, slug (usually the login username), description, URL, avatar URLs in multiple sizes, and links to related endpoints. It’s essentially a public directory of your site’s users.
Why should you care?
Username harvesting in one request. While author enumeration via ?author=1 requires iterating through IDs, the REST API hands over all usernames in a single request. One curl command gives an attacker every username on your site.
It’s automated at scale. Security scanners like WPScan, Shodan, and custom scripts query this endpoint automatically. Your site’s user data might already be indexed in vulnerability databases without your knowledge.
The slugs often match login usernames. Unless you’ve explicitly changed your nickname and display name, the slug field in the REST API response matches your WordPress login username — the exact string needed for brute force attacks.
Search engines index it. Since it’s a publicly accessible URL returning structured data, search engines can index and cache your REST API user data. Your usernames might appear in Google search results.
The quick fix
// Restrict REST API users endpoint to authenticated users only
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( ! is_user_logged_in() ) {
// Remove users endpoints entirely for non-logged-in visitors
unset( $endpoints['/wp/v2/users'] );
unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
}
return $endpoints;
});This removes the users endpoint for non-authenticated requests. Logged-in users (and therefore Gutenberg, admin features, and plugins) retain full access.
Don’t disable the entire REST API. Some guides suggest blocking all REST API access. This breaks Gutenberg, Contact Form 7, WooCommerce, and most modern plugins. You only need to restrict specific endpoints.
The one-click solution
Ovanap Admin Toolkit includes Block public user list API under Admin Toolkit → Features → Security. One switch removes the /wp/v2/users routes for every request, logged in or not, and leaves the rest of the API working. Because logged-in requests are blocked too, check that the author selector in the block editor and any plugin that lists users still work after you switch it on.
What happens after you fix this?
/wp-json/wp/v2/usersreturns a 404 (rest_no_route) for non-logged-in visitors (with the toolkit switch, for everyone)- User data stops being publicly accessible via the API
- Username harvesting via REST API is blocked — one fewer attack vector
- Gutenberg keeps working with the code above — it only blocks logged-out requests. The toolkit switch blocks logged-in requests too, so check the editor’s author selector
- All other REST API endpoints remain accessible — no breakage
FAQ
Will this break the Gutenberg editor or WooCommerce?
With the code above, no: the restriction only applies to requests that are not logged in, so Gutenberg, WooCommerce, Contact Form 7 and other plugins keep their access. Ovanap Admin Toolkit’s switch is stricter: it removes the users endpoint for every request, logged in or not. The rest of the REST API is untouched, but anything that lists users through this endpoint, such as the author selector in the block editor, can stop working. Test it after you switch it on.
Should I also restrict other REST API endpoints?
The users endpoint is the highest-priority concern because it directly exposes login usernames. Other endpoints like posts and pages return data that’s already publicly visible on your site. If you want tighter control, consider requiring authentication for all REST API access — but test thoroughly, as some frontend features may depend on public API access.
My site has a headless frontend that queries the API — will this break it?
If your headless frontend needs user data, you’ll need to either authenticate API requests (recommended) or whitelist specific IPs or tokens in your own code. Ovanap Admin Toolkit has no exception list: its switch removes the users endpoint for every request, so leave it off on headless sites that need it.
Related reads: