WordPress’s REST API and default author archives can quietly reveal valid usernames to anyone who knows where to look, even when your login page itself gives nothing away — and a valid username is half of what an attacker needs. Locking this down closes that specific leak without turning off the API itself, which most sites still need for something.
REST API & user enumeration lockdown
Usernames quietly leaking through the REST API or author archives, found and closed.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Admin access and FTP/code access for the changes involved
- Confirmation of any plugins or integrations that rely on the REST API, so we don’t break something you need
- Confirmation you’re aware which specific usernames are currently exposed, if you’ve already checked
This or something else?
| Usernames or user data are exposed through the REST API or author archives | This fix covers it |
| You want the REST API disabled entirely, not just locked down selectively | Worth discussing directly, since a full disable can break legitimate plugin functionality |
| You’ve already changed your admin username but want the broader exposure closed too | This fix covers it — username changes and enumeration lockdown are complementary, not redundant |
| You want general security headers implemented, a different but related fix | Security headers implementation – CSP, HSTS |
What we do
- Identify exactly what user information is currently exposed via REST API or author archives
- Check which plugins or integrations genuinely depend on the exposed endpoints
- Restrict or filter the specific endpoints leaking usernames, preserving what’s actually needed
- Redirect or disable predictable author archive URLs where appropriate
- Test that legitimate API usage and plugin function still work
- Confirm the exposure is closed by checking the previously vulnerable endpoints directly
What is included
- User enumeration vectors identified and closed
- Legitimate REST API and plugin functionality preserved and tested
- Verification the previously exposed endpoints no longer leak data
- A written note on what was closed and why
Not included
- Disabling the REST API entirely, which is a larger, more disruptive change if genuinely wanted
- Changing your admin username itself, a separate, related fix
- Broader security header implementation, a separate fix
- Ongoing review as new plugins introduce new endpoints
Questions about this fix
What exactly does 'user enumeration' mean in practice?
It means an outsider can discover valid usernames on your site through predictable URLs or API responses, without needing to guess — information they can then use to attempt to guess the matching password.
Will this break any plugins that rely on the REST API?
It can, if a plugin genuinely depends on the specific endpoint being restricted, which is why we check current dependencies before closing anything rather than blocking indiscriminately.
Why not just disable the REST API completely?
Many modern plugins, including the block editor itself, rely on the REST API to function — disabling it entirely is a much bigger, more disruptive change than most sites actually need.
How would I check myself whether this is currently exposed?
Visiting yoursite.com/wp-json/wp/v2/users often reveals exactly this kind of exposure directly in a browser, without needing any special tools.
Does closing this guarantee no one can find my usernames another way?
No single fix eliminates every possible way a username could become known, but this closes the most common, automated method attackers use.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.