WordPress REST API user enumeration, explained

WordPress user enumeration is the process of identifying valid user accounts on a website.

One of the places this can happen is the WordPress REST API.

On a default installation, WordPress provides a users collection under:

/wp-json/wp/v2/users

Depending on the site’s content, configuration and the permissions of the requester, that endpoint can return public information about users who have published REST-visible content.

A response can contain information such as:

• user ID;
• display name;
• public author URL;
• user slug;
• avatar URLs;
• public biography or description.

This creates an important security distinction.

The REST API does not normally expose every private field of every WordPress account to anonymous visitors.

For example, fields such as the actual login username and email address are associated with more privileged REST contexts.

However, public REST responses can expose enough information to identify valid author accounts, correlate users with author archives, and sometimes reveal a slug that is identical or closely related to the account’s login username.

That is what makes REST API user enumeration worth understanding.

The problem is not:

The REST API exposes every WordPress password.

It does not.

The more realistic issue is:

Public WordPress information
        ↓
reveals valid users
        ↓
usernames or likely usernames become easier to identify
        ↓
an attacker has one less unknown
        ↓
login attacks can focus on known accounts

This guide explains exactly how REST user enumeration works, what WordPress exposes by default, why the user slug matters, how author archives interact with the REST API, what attackers gain from enumeration, and how to reduce unnecessary exposure without breaking the rest of WordPress.

What is user enumeration?

User enumeration means determining whether a particular user account exists.

Suppose an attacker wants to authenticate to a WordPress website.

Without any prior information, the attacker may need to determine both:

username
+
password

If the username can be discovered independently, the authentication problem becomes:

known username
+
unknown password

That does not mean the account has been compromised.

But it removes one unknown from the attack process.

User enumeration is not the same as account compromise

This distinction is important.

Discovering:

jane

as a valid WordPress user does not provide:

• Jane’s password;
• Jane’s authentication cookie;
• administrator access;
• the ability to edit Jane’s account;
• private user metadata;
• automatic access to wp-admin.

User enumeration is therefore an information exposure issue rather than an authentication bypass.

Its security value comes from what can be done with the information afterward.

Where can WordPress usernames or users be discovered?

The REST API is only one possible source.

WordPress users can sometimes be identified through:

• REST API user endpoints;
• author archives;
• author links in posts;
• display names;
• user slugs;
• RSS feeds;
• sitemaps or SEO output;
• comments;
• plugin-generated content;
• theme markup;
• login responses;
• public profile information;
• third-party services.

This matters because disabling one enumeration technique does not necessarily make WordPress usernames undiscoverable.

For a broader view of the problem, see How Attackers Collect WordPress Usernames and Email Addresses.

The WordPress REST API users endpoint

WordPress core registers a REST resource for users.

The primary collection endpoint is:

GET /wp-json/wp/v2/users

The official WordPress Users REST API documentation documents this route and the fields that can exist in a REST user record.

A specific user can also have a route such as:

GET /wp-json/wp/v2/users/123

while the current authenticated user can be represented through:

GET /wp-json/wp/v2/users/me

These endpoints do not all expose the same information to every requester.

What does an anonymous REST user response look like?

A public response can resemble:

[
    {
        "id": 4,
        "name": "Jane Smith",
        "url": "https://example.com",
        "description": "",
        "link": "https://example.com/author/jane/",
        "slug": "jane",
        "avatar_urls": {
            "24": "...",
            "48": "...",
            "96": "..."
        }
    }
]

The exact response depends on the site, WordPress version, registered fields, plugins and request context.

The important fields for enumeration are often:

id
name
link
slug

The REST API has different user contexts

WordPress REST resources support contexts that control which fields are returned.

For users, the documented contexts include:

embed
view
edit

The official Users endpoint schema shows that different fields are available in different contexts.

This is crucial when evaluating what WordPress actually exposes.

The REST API does not normally expose the login username publicly

The REST user schema includes a field named:

username

but WordPress documents that field for:

context: edit

Likewise, fields such as:

email
first_name
last_name
nickname
roles
capabilities
registered_date

are associated with more privileged contexts rather than ordinary anonymous view responses.

So the simplistic claim:

/wp-json/wp/v2/users
exposes everyone's login username and email address

is inaccurate for current WordPress core.

Then why is REST user enumeration still a concern?

Because the public user representation includes another important field:

slug

The WordPress REST schema describes this as an alphanumeric identifier for the user.

Internally, this corresponds to the WordPress:

user_nicename

rather than necessarily:

user_login

The distinction sounds small, but it matters enormously.

user_login vs. user_nicename

WordPress maintains separate user properties including:

user_login
user_nicename
display_name

They serve different purposes.

user_login

This is the actual login identifier associated with the account.

user_nicename

This is a URL-friendly user identifier commonly used for author URLs.

display_name

This is the public-facing name displayed by themes and WordPress interfaces.

They might be configured as:

user_login:
jsmith_admin

user_nicename:
jane-smith

display_name:
Jane Smith

In that case, exposing:

jane-smith

does not reveal:

jsmith_admin

But user_nicename often starts from the username

On many WordPress installations, the user nicename initially resembles the login username.

For example:

user_login:
jane

user_nicename:
jane

Now a public REST response containing:

"slug": "jane"

has effectively revealed a valid login identifier even though WordPress technically exposed the nicename rather than the username REST field.

This is why the practical security impact depends partly on whether:

user_login
=
user_nicename

The public REST slug is not automatically the login username

This distinction should not be ignored when auditing WordPress.

If the API returns:

"slug": "jane-smith"

you can conclude that:

jane-smith is the public user nicename

You cannot automatically conclude that:

jane-smith is definitely the login username

It may be.

But it may also differ.

That makes REST enumeration useful for reconnaissance without making every returned slug a guaranteed credential.

How WordPress decides which users anonymous visitors can list

The behavior is more nuanced than simply returning every account in the database.

WordPress core uses:

WP_REST_Users_Controller

to handle REST user routes.

The official WP_REST_Users_Controller reference exposes the current implementation used for REST user requests.

When the requester does not have the capability to:

list_users

WordPress limits the user query to accounts with published posts in post types exposed through REST.

Conceptually:

anonymous / unprivileged request
↓
cannot list arbitrary users
↓
WordPress limits results
↓
users with published REST-visible content

Why published content matters

WordPress treats authors of public content differently from arbitrary private accounts.

If a user has publicly authored content, WordPress already has reasons to expose some author identity information.

For example, a public post may link to:

/author/jane/

and display:

Jane Smith

The REST API can provide a structured representation of similar public author information.

Anonymous visitors do not necessarily get every WordPress account

Consider a site with:

Administrator A
→ never published content

Administrator B
→ published posts

Editor C
→ published posts

Subscriber D
→ no posts

An anonymous REST user collection should not be treated as a guaranteed complete list of all four accounts.

WordPress’s permission and query logic restricts what unprivileged users can retrieve.

The official WP_REST_Users_Controller::get_items() source shows that, when the requester cannot list_users, WordPress constrains the query using published posts from REST-enabled post types.

Individual user endpoints also have permission checks

The route:

/wp-json/wp/v2/users/123

does not blindly expose every valid user ID.

The current get_item_permissions_check() implementation checks whether the requester is allowed to retrieve the requested user.

For users who cannot otherwise be listed or edited, WordPress checks whether the user has published content in relevant REST-visible post types.

Why the user ID still matters

When exposed, a numeric user ID can provide another stable identifier:

"id": 4

An attacker can potentially correlate that ID with:

• author archives;
• posts;
• REST resources;
• plugin output;
• other public site data.

The ID itself is not secret authentication material.

Its value comes from correlation.

REST enumeration and author archives overlap

REST user resources commonly contain:

"link": "https://example.com/author/jane/"

WordPress author archives also use the public user nicename.

The official WordPress Theme Handbook author hierarchy documentation explains that author archive templates can be selected using either the user’s nicename or user ID.

REST therefore does not exist in isolation.

It can connect:

user ID
↓
user slug
↓
display name
↓
author archive
↓
published posts

See Why WordPress Author Archives Leak Usernames for the archive-specific side of the problem.

Author enumeration can happen without the REST API

A traditional WordPress enumeration technique involves requests based on author IDs.

For example, a site may resolve or redirect an author query toward an author archive.

The resulting URL can reveal the public user nicename.

This means:

REST user enumeration blocked
≠
WordPress user enumeration solved

If author archives still expose the same slug, the information may remain available through another path.

Why attackers combine enumeration sources

Reconnaissance is usually more effective when several sources are correlated.

An attacker might gather:

REST API
→ Jane Smith
→ user ID 4
→ slug jane

Author archive
→ /author/jane/

Posts
→ Jane Smith authored 37 posts

Login behavior
→ confirms jane as a valid login candidate

No single source necessarily reveals everything.

Together, they can provide a clearer picture.

REST search parameters can assist enumeration

The WordPress users collection supports several query parameters.

The official List Users endpoint documentation includes parameters such as:

• search;
• include;
• exclude;
• slug;
• who;
• has_published_posts;
• pagination and ordering parameters.

However, permissions affect how some filters can be used.

WordPress restricts privileged user filtering

Not every users-endpoint filter is freely available to anonymous visitors.

For example, the current WordPress permission checks restrict certain operations involving:

• roles;
• capabilities;
• edit context;
• ordering by sensitive fields such as email or registration date.

The official get_items_permissions_check() source shows these capability checks.

This is another reason an accurate security audit should distinguish public REST behavior from authenticated administrative behavior.

Can anonymous REST searches reveal email addresses?

Current WordPress core does not expose the user email field in ordinary public view context.

The REST schema places:

email

in:

context: edit

Likewise, WordPress restricts certain email-based query behavior for users without the necessary capabilities.

So if an anonymous REST response exposes raw account email addresses, investigate:

• plugins;
• custom REST fields;
• custom endpoints;
• misconfigured permissions;
• other site functionality.

Do not assume that exposure is standard WordPress core behavior.

Can the REST API expose display names?

Yes.

The public user schema includes:

name

which represents the user’s display name.

This is generally intended as public-facing information.

A display name such as:

Jane Smith

is not automatically a login credential.

However, it can help correlate an account with other public information.

Can the REST API expose avatar information?

Public user records can include:

avatar_urls

depending on WordPress configuration and available avatar functionality.

Avatar data is another example of information intended for public author representation rather than authentication.

Its security relevance is mainly correlation rather than direct account access.

Can the REST API expose user biographies?

The public schema can include:

description

which corresponds to public biographical information.

Again, this information may already appear on author archive pages or other frontend templates.

The REST API provides a structured way to retrieve it.

The REST API makes enumeration easier to automate

This is arguably the most important difference between REST exposure and normal frontend author information.

A human can manually browse author pages.

A machine can request:

/wp-json/wp/v2/users

and immediately receive structured JSON.

Instead of parsing HTML such as:

<a href="/author/jane/">
    Jane Smith
</a>

software can process:

{
    "id": 4,
    "name": "Jane Smith",
    "slug": "jane"
}

That makes legitimate API consumption easier.

It also makes automated reconnaissance easier.

What can an attacker do with an enumerated username?

The most obvious next step is authentication targeting.

An attacker who identifies:

jane

as a likely login can focus password attempts on that account.

The attack becomes:

known account
+
password guesses

rather than:

username guesses
+
password guesses

Enumeration and brute-force attacks

User enumeration can therefore support brute-force or password-spraying workflows.

For example:

enumerate users
↓
collect likely login names
↓
select common passwords
↓
attempt authentication
↓
repeat across accounts

The enumeration itself is not the brute-force attack.

It provides input for the later authentication attack.

See WordPress Brute-Force Attacks, Explained.

Password spraying is particularly relevant

Traditional brute force can involve many passwords against one account.

Password spraying instead tries a smaller number of common passwords across many known accounts.

For example:

Known users:

jane
mark
editor
john
content-team

Password candidate:

ExamplePassword123

A reliable list of valid accounts makes this type of attack more efficient.

Enumeration can improve phishing reconnaissance

Public REST data can also help identify:

• authors;
• content editors;
• names associated with the organization;
• public profile URLs.

This can provide context for social engineering.

For example, an attacker might learn that:

Jane Smith
→ writes company announcements
→ has an author account
→ probably works with WordPress

That does not create a vulnerability by itself, but it can improve targeting.

Does changing the display name solve REST enumeration?

No.

Changing:

Display name publicly as

can prevent the frontend from displaying the login username directly as the author’s visible name.

That is good practice.

But the REST:

slug

and author archive URL can still reveal the user nicename.

Display name and user slug are separate fields.

Does using an email address to log in solve enumeration?

Not necessarily.

WordPress can authenticate users using usernames and, in standard modern configurations, email addresses.

The more important security question is whether publicly exposed account identifiers overlap with actual authentication identifiers.

See WordPress Login: Username vs. Email, Which Is More Secure?.

Is a secret username a strong security control?

No.

A username can provide an additional unknown, but it should not be treated like a password.

A secure WordPress account should remain difficult to compromise even when the attacker knows:

the exact username

Strong authentication should instead rely on controls such as:

• unique passwords;
• long passwords;
• multi-factor authentication where available;
• login rate limiting;
• bot protection;
• monitoring;
• least privilege.

So should REST user enumeration be ignored?

No.

There is a difference between:

username secrecy is not a primary security boundary

and:

unnecessary account enumeration is desirable

If a website does not need to expose a public user collection, reducing that exposure can still make sense.

The goal should be defense in depth rather than pretending enumeration prevention replaces strong authentication.

Why blocking the entire REST API is usually the wrong fix

A common response to REST user enumeration is:

disable /wp-json/ completely

That solves a much larger problem than the one identified.

Modern WordPress uses the REST API for features including:

• the Block Editor;
• the Site Editor;
• templates;
• Global Styles;
• media;
• widgets;
• plugin interfaces;
• custom applications.

See What Depends on the WordPress REST API before applying broad restrictions.

Restrict the exposure, not necessarily the entire API

A better security question is:

Which REST resources should anonymous users be able to retrieve?

rather than:

Should WordPress have a REST API at all?

This allows a site to preserve:

• editor functionality;
• authenticated REST requests;
• plugin APIs;
• required public endpoints;

while reducing specific user exposure where appropriate.

How to inspect REST user exposure

Start with the public users collection:

https://example.com/wp-json/wp/v2/users

Perform the request while logged out.

Do not test only from an administrator session because administrators can have access to additional user information.

Check which fields are returned

For each public record, inspect:

id
name
url
description
link
slug
avatar_urls

Then compare those values with the account’s actual authentication information.

The most important question is often:

Does the public slug equal the login username?

Check whether privileged fields are exposed

An anonymous request should not normally reveal privileged user fields such as:

username
email
roles
capabilities
registered_date

in ordinary public context.

If it does, investigate immediately.

A plugin or custom endpoint may have changed the site’s exposure beyond WordPress core defaults.

Check individual user IDs

Test a known public author:

/wp-json/wp/v2/users/4

Then test an account with no published content where appropriate.

The responses can help you understand which users WordPress exposes publicly on that specific installation.

Check the user slug filter

The REST users endpoint supports filtering by slug.

For example:

/wp-json/wp/v2/users?slug=jane

Depending on permissions and whether the account qualifies for public visibility, the response can help confirm whether that public user slug exists.

This is another reason public slugs should be treated as public identifiers rather than secrets.

Check author archives

For each REST user, inspect the:

link

field.

It may point to something like:

https://example.com/author/jane/

Then determine whether disabling REST user listing would actually remove the information or merely leave the same slug exposed through the author archive.

Check public posts

Inspect author information in:

• post bylines;
• author boxes;
• structured data;
• theme markup;
• feeds;
• archive pages.

A username-protection strategy that ignores the rest of the public site can easily become security theatre with extra PHP attached.

Check feeds

WordPress RSS feeds can contain author information.

Depending on the site and feed implementation, that can provide another correlation source.

For how feeds are exposed, see WordPress RSS Feed URLs Explained.

Check plugins and custom REST routes

WordPress core is not the only software capable of exposing user data.

A plugin can register:

/wp-json/plugin-name/v1/users

or add custom fields to existing REST user objects.

Custom code can also expose:

• email addresses;
• roles;
• internal IDs;
• profile metadata;
• application-specific user data.

Do not stop auditing after checking /wp/v2/users.

Review REST namespaces

Request:

/wp-json/

and inspect registered namespaces.

Then identify routes that appear related to:

users
members
accounts
customers
profiles
authors

Third-party endpoints can have completely different permission models from WordPress core.

How to reduce REST API user enumeration

There are several possible approaches, depending on the site’s requirements.

The safest approach is generally targeted:

keep REST functionality
+
keep authenticated user access
+
keep required public content
+
reduce unnecessary anonymous user exposure

Option 1: restrict anonymous access to user routes

A site can apply additional permission logic specifically to user-related REST requests rather than blocking every REST route.

Conceptually:

Posts
→ public

Pages
→ public

Media
→ public where needed

User collection
→ restricted

Authenticated editor requests
→ allowed

This is much narrower than globally disabling REST.

Be careful with editor dependencies

The WordPress editor can legitimately request user information.

For example, interfaces may need authors for:

• author selection;
• post attribution;
• editor components;
• entity data.

A restriction should therefore distinguish:

anonymous visitor
from
authenticated WordPress user

rather than indiscriminately blocking the users endpoint for everyone.

Option 2: separate public slugs from login usernames

If public author functionality is required, one useful defense-in-depth measure is ensuring that:

user_nicename
≠
user_login

For example:

login username:
jane-secure-login

public nicename:
jane-smith

REST and author archives can then expose:

jane-smith

without directly revealing:

jane-secure-login

This does not replace strong passwords or MFA, but it reduces direct credential correlation.

Changing user_nicename requires care

The user nicename is used in author URLs.

Changing it can therefore change URLs such as:

/author/old-slug/

to:

/author/new-slug/

Consider:

• existing links;
• search indexing;
• redirects;
• caches;
• author sitemaps;
• theme references.

Do not treat it as an invisible account setting.

Option 3: disable unnecessary author archives

If the website does not use author archive pages, disabling or redirecting them can remove another enumeration path.

This is particularly relevant for:

• single-author company sites;
• business websites without public author profiles;
• sites where author archives duplicate other content.

But this should be evaluated independently from REST.

See Why WordPress Author Archives Leak Usernames.

Option 4: strengthen login security

Even perfect enumeration prevention should not be the main authentication defense.

Assume an attacker can eventually discover the username.

Then protect the account accordingly.

A stronger login posture includes:

• long unique passwords;
• multi-factor authentication;
• rate limiting;
• bot mitigation;
• monitoring failed logins;
• removing unused accounts;
• least-privilege roles;
• keeping WordPress and plugins updated.

See A WordPress Login Hardening Checklist.

Option 5: review public display names

Do not configure an administrator with:

username:
admin-secret-name

display name:
admin-secret-name

if there is no reason to expose the authentication identifier publicly.

A public display name can instead be:

Jane Smith

while the login identifier remains different.

This is basic hygiene, even though it does not solve REST slug exposure by itself.

Option 6: review unnecessary privileged accounts

Enumeration becomes more consequential when public authors also have excessive privileges.

For example:

public content author
+
administrator privileges

creates a more valuable authentication target than:

public content author
+
author-level privileges

Apply the principle of least privilege.

Do not publish content from a primary administrator account unnecessarily

A useful operational separation is:

administrator account
→ site administration

author/editor account
→ public content publishing

This can reduce the chance that a publicly enumerable content author is also the site’s most privileged account.

It does not eliminate enumeration, but it reduces its potential value.

Should you hide REST API discovery links?

WordPress can advertise the REST API through:

• HTML api.w.org links;
• HTTP Link headers;
• RSD.

Removing those signals can reduce passive API discovery.

But:

REST discovery removed
≠
/wp-json/ unavailable
≠
user enumeration prevented

An automated tool can request the predictable API URL directly.

See How WordPress Advertises Its REST API.

Hiding /wp-json/ is not a complete defense

The standard REST URL is widely known.

WordPress can also use:

?rest_route=/

when appropriate.

Trying to make the API difficult to locate is therefore weaker than controlling what anonymous users can retrieve from sensitive routes.

See Hiding vs. Restricting the WordPress REST API.

Do not globally require authentication without testing

A broad REST rule such as:

all anonymous REST requests
→ 401

can stop public user enumeration.

But it can also stop legitimate public REST consumers.

Depending on the site, those might include:

• headless frontends;
• public search applications;
• mobile applications;
• external content consumers;
• plugin functionality.

Before making the whole REST API authenticated-only, review What Depends on the WordPress REST API.

Do not use the deprecated rest_enabled approach

Older WordPress tutorials may recommend filters or techniques intended to completely disable REST globally.

Current WordPress documentation notes that the REST API can no longer be completely disabled through the old:

rest_enabled

mechanism.

The current rest_enabled hook documentation directs developers toward REST authentication controls when access restrictions are required.

This is another reason old REST-hardening snippets deserve scrutiny before being copied into a current site.

Should you block /wp/v2/users with a firewall?

It can be done, but application-level behavior is usually more nuanced.

A firewall rule sees a URL.

WordPress understands:

• whether the requester is authenticated;
• which user is making the request;
• which capabilities that user has;
• which REST route is being requested;
• which operation is being performed.

A blanket firewall block can therefore prevent legitimate authenticated WordPress functionality as well as anonymous enumeration.

Rate limiting can reduce automated enumeration

If repeated REST queries are part of automated reconnaissance, infrastructure controls can reduce request volume.

Possible layers include:

• CDN rate limiting;
• web application firewall rules;
• reverse proxy controls;
• application-level throttling.

However, rate limiting does not change what one permitted response exposes.

It controls scale, not data visibility.

Does blocking REST enumeration prevent brute force?

No.

It can make account discovery less convenient.

But attackers may still obtain usernames from:

• author archives;
• public posts;
• feeds;
• comments;
• data breaches;
• social networks;
• email conventions;
• other WordPress endpoints.

Brute-force protection must therefore work even when the username is known.

Does REST enumeration reveal passwords?

No.

WordPress does not expose user passwords through the REST users endpoint.

The REST schema identifies the password as a write-oriented field and it is never included in normal user responses.

If an application somehow exposes passwords through a custom API, that would be a severe custom implementation vulnerability, not normal WordPress REST behavior.

Does REST enumeration reveal password hashes?

Not through the standard WordPress users endpoint.

Password hashes stored by WordPress are not part of the public REST user schema.

Does REST enumeration reveal administrator roles?

Not normally to anonymous users through the standard public user representation.

The:

roles

field belongs to the privileged:

edit

context.

WordPress also restricts role-based filtering to users with the necessary capabilities.

Again, plugins and custom APIs can change this, so audit the actual site.

Can REST enumeration reveal administrator accounts indirectly?

Potentially.

If an administrator publishes content and their public slug or author archive is exposed, an attacker may identify that account as a public author.

However, the public REST response does not necessarily state:

"role": "administrator"

to anonymous visitors.

Role inference can instead come from other public information or behavior.

Does disabling author archives remove users from REST?

Not automatically.

Author archives and REST user endpoints are separate WordPress mechanisms.

You can have:

author archives disabled
+
REST users available

or:

author archives available
+
REST users restricted

If reducing enumeration is the goal, audit both.

Does disabling REST users remove author archives?

No.

The inverse is also true.

Restricting:

/wp-json/wp/v2/users

does not automatically remove:

/author/jane/

This is why enumeration should be treated as a multi-surface problem.

REST user enumeration and WordPress fingerprinting

REST user information can contribute to broader site reconnaissance.

An attacker may combine:

REST namespaces
+
user records
+
author archives
+
theme information
+
plugin fingerprints
+
WordPress version clues

to build a profile of the installation.

For the broader process, see How Attackers Fingerprint WordPress Sites.

How to audit REST user enumeration step by step

1. Test while logged out

Use a private browser window or another unauthenticated client.

Request:

/wp-json/wp/v2/users

2. Record every exposed user

For each result, note:

• ID;
• name;
• slug;
• author link;
• description;
• avatar information.

3. Compare slug and login username internally

For accounts you administer, determine whether:

slug == username

If they match, the public nicename is also revealing the authentication identifier.

4. Test individual user IDs

Request:

/wp-json/wp/v2/users/ID

for:

• a public author;
• an administrator with published posts;
• an account with no published posts;
• other relevant roles.

5. Check author archives

Compare REST slugs with:

/author/SLUG/

6. Check public post bylines

Determine whether themes expose:

• login-like names;
• author URLs;
• author IDs;
• structured author metadata.

7. Check feeds

Inspect author information in RSS output.

8. Inspect the REST API root

Review:

/wp-json/

for custom namespaces.

9. Audit plugin endpoints

Look for routes exposing:

• users;
• members;
• customers;
• profiles;
• authors.

10. Test anonymous and authenticated behavior separately

Authenticated administrators will legitimately see more information than anonymous visitors.

Do not mistake administrative REST access for public exposure.

11. Test after applying restrictions

Verify both:

anonymous enumeration reduced
+
legitimate WordPress functionality preserved

12. Test the Block Editor

Open a post and check:

• author selection;
• saving;
• publishing;
• editor panels;
• media;
• taxonomies.

13. Test plugin interfaces

Especially inspect JavaScript-heavy admin screens that may request user entities through REST.

14. Inspect browser Network requests

Filter for:

wp-json

and look for failed:

/wp/v2/users

requests.

A practical exposure matrix

Information	Anonymous core REST exposure	Security relevance
User ID	Can be public for visible authors	Useful for correlation
Display name	Can be public	Identity correlation
User slug / nicename	Can be public	May match login username
Author URL	Can be public	Links REST identity to author archive
Biography	Can be public	Reconnaissance / identity information
Avatar URLs	Can be public	Identity correlation
Login username field	Not normal public view context	Authentication identifier
Email address	Not normal public view context	Sensitive account identifier
Roles	Privileged context	Can identify high-value accounts
Capabilities	Privileged context	Authorization information
Password	Never returned normally	Authentication secret
Password hash	Not exposed by core REST users endpoint	Authentication secret

How TheOneWP should approach REST user enumeration

REST user enumeration should be treated as a specific exposure problem rather than as justification for disabling the entire WordPress REST API.

The desired security model is:

WordPress REST API
→ available where required

Block Editor
→ works

Site Editor
→ works

authenticated REST clients
→ work

public user exposure
→ restricted where unnecessary

This is consistent with the distinction described in Hiding vs. Restricting the WordPress REST API.

TheOneWP can also remove public REST API advertising through its Disable REST API Links feature when automatic discovery is unnecessary.

But discovery cleanup should not be confused with protection against user enumeration.

A complete hardening strategy must consider the actual user endpoint, author archives, public user slugs and login security together.

Common mistakes with REST API user enumeration

Claiming WordPress publicly exposes every username

Current core behavior is more restricted than that.

Calling the public slug the username without qualification

The REST slug corresponds to user_nicename, which may or may not equal user_login.

Claiming anonymous REST exposes email addresses by default

The core email field belongs to privileged edit context.

Claiming REST exposes passwords

It does not.

Assuming every account appears in /wp/v2/users

Unprivileged requests are constrained according to WordPress’s user visibility rules and published REST-visible content.

Blocking the entire REST API to hide users

This can break major WordPress functionality.

Removing api.w.org discovery links and assuming enumeration is solved

The predictable REST endpoint can still be requested directly.

Restricting REST users but leaving identical author slugs public

The same information may remain available through author archives.

Changing the display name and assuming the slug changed

Display name and nicename are separate.

Using a hidden username as the primary login defense

Usernames are identifiers, not strong secrets.

Ignoring administrator publishing behavior

Publishing from privileged accounts can increase their public visibility.

Ignoring plugin REST endpoints

Third-party code can expose additional user information.

Testing REST only while logged in as administrator

Administrative responses are not representative of anonymous exposure.

Using rate limiting as if it removed exposed data

Rate limiting controls request frequency, not the content of successful responses.

Assuming enumeration prevention stops brute force

Login protection still needs to work when the username is known.

WordPress REST API user enumeration checklist

• Understand what user enumeration means.
• Do not confuse enumeration with account compromise.
• Test /wp-json/wp/v2/users while logged out.
• Identify which users appear publicly.
• Record exposed user IDs.
• Record exposed display names.
• Record exposed slugs.
• Record exposed author URLs.
• Check public biographies.
• Check avatar information.
• Understand that REST slug represents user_nicename.
• Do not automatically equate user_nicename with user_login.
• Compare public nicenames with login usernames internally.
• Separate public nicenames from login usernames where appropriate.
• Understand that username is associated with privileged REST context.
• Understand that email is associated with privileged REST context.
• Understand that roles and capabilities are privileged information.
• Know that passwords are not returned through normal REST user responses.
• Know that password hashes are not exposed by the core users endpoint.
• Understand how WordPress limits unprivileged user queries.
• Check which accounts have published REST-visible content.
• Test individual /wp/v2/users/ID routes.
• Check author archive URLs.
• Check author ID enumeration separately.
• Check public post bylines.
• Check author boxes.
• Check RSS feeds.
• Check SEO-generated author output.
• Inspect custom REST namespaces.
• Inspect plugin user endpoints.
• Inspect custom REST fields.
• Test anonymous and authenticated behavior separately.
• Do not disable the entire REST API merely to hide users.
• Review Block Editor dependencies before REST restrictions.
• Review Site Editor dependencies.
• Review plugin REST dependencies.
• Review headless frontend dependencies.
• Restrict user routes selectively where possible.
• Keep required authenticated REST functionality working.
• Consider disabling unnecessary author archives.
• Do not publish routine content from highly privileged accounts unnecessarily.
• Use least-privilege roles.
• Use strong unique passwords.
• Use multi-factor authentication where available.
• Use login rate limiting.
• Use bot mitigation where appropriate.
• Monitor failed login attempts.
• Remove unused accounts.
• Do not rely on username secrecy as the primary security control.
• Do not confuse REST discovery removal with REST restriction.
• Do not assume hiding /wp-json/ protects the endpoint.
• Remember the ?rest_route=/ REST URL form.
• Review firewall rules before blocking user endpoints globally.
• Review CDN and WAF behavior.
• Rate limit automated abuse where necessary.
• Retest REST behavior after security changes.
• Test author selection in the editor.
• Test post saving.
• Test media and taxonomy panels.
• Inspect failed REST requests in browser developer tools.
• Reaudit user exposure after installing plugins that register REST routes.

Related guides

• Why WordPress Author Archives Leak Usernames
• How Attackers Collect WordPress Usernames and Email Addresses
• How to Restrict the WordPress REST API
• WordPress REST API Security Basics
• What Depends on the WordPress REST API
• A WordPress Login Hardening Checklist

Final recommendation

WordPress REST API user enumeration is a real form of information exposure, but it should be described accurately.

The standard public users endpoint does not simply hand anonymous visitors every private account field.

Current WordPress core separates public and privileged user information through REST contexts and permission checks.

For unprivileged requests, WordPress also limits which users can be returned based on public content and REST-visible post types.

What can remain publicly useful for enumeration is information such as:

user ID
+
display name
+
user nicename / slug
+
author URL
+
public profile information

The most important field is often the public user slug.

If:

user_nicename
=
user_login

then exposing the nicename can effectively reveal a valid authentication identifier.

If those values are different, REST still reveals a valid public author identity, but the attacker has not necessarily learned the login username.

That distinction matters.

The correct response is also rarely to disable the entire WordPress REST API.

Modern WordPress can depend on REST for the Block Editor, Site Editor, media, templates, Global Styles, plugins and external applications.

A better strategy is:

audit anonymous user exposure
↓
identify which information is unnecessary
↓
restrict user-related routes where appropriate
↓
review author archives and other enumeration paths
↓
separate public slugs from login identifiers where practical
↓
protect authentication independently
↓
test WordPress functionality after every restriction

Most importantly, design WordPress login security under the assumption that usernames may eventually become known.

Enumeration resistance can remove useful reconnaissance information, but it should remain a defense-in-depth measure.

The real authentication boundary should still be strong passwords, appropriate account privileges, rate limiting, multi-factor authentication where available, and properly protected login workflows.

That approach reduces unnecessary user exposure without breaking a REST API that modern WordPress increasingly depends on.