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
OvKit includes Block REST API Users under Features → Security. One toggle restricts the users endpoint for non-authenticated visitors while keeping the rest of the API fully functional. No code, no risk of accidentally breaking your editor.
What happens after you fix this?
/wp-json/wp/v2/usersreturns 401/403 for non-logged-in visitors- User data stops being publicly accessible via the API
- Username harvesting via REST API is blocked — one fewer attack vector
- Gutenberg editor continues working — admin functionality is untouched
- All other REST API endpoints remain accessible — no breakage
FAQ
Will this break the Gutenberg editor or WooCommerce?
No. The restriction only applies to non-authenticated requests. When you’re logged into WordPress, the REST API works normally. Gutenberg, WooCommerce, Contact Form 7, and any plugin that uses the REST API internally will continue to function perfectly.
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. OvKit’s REST API restrictions support custom exceptions for headless setups.
Related reads: