You lock your front door. Good. But then you hang a little sign next to it saying, “Hi, the keyholder is Mike.” That’s basically what happens on a lot of WordPress sites with user enumeration.
Sounds technical. It is, a bit. But the idea is simple: bots try to figure out your admin username before they start guessing the password. And if they can get the username easily, their job gets a whole lot easier.
Not impossible for them without it. Just easier. Faster. Cheaper.
Let’s talk about how this works through the WordPress REST API, why small business sites get caught by it, and what you should actually do about it.
First, what is user enumeration?
User enumeration just means discovering valid usernames on a site.
That’s it.
On WordPress, attackers often don’t start by hammering random passwords against “admin” anymore. They want real usernames first. If your site has a user called sarah, mike, or worse, your email-style login name, bots can grab that and move to the next step – password guessing, credential stuffing, phishing, or targeted brute force attempts.
And yes, this happens to tiny sites too. Local accountants. Dentists. A two-person online shop selling candles. Nobody’s beneath automated attacks. If you want the bigger picture, this article on how attackers find your WordPress site in the first place explains why random-looking small sites still get swept up by bots all day long.
How the REST API gives usernames away
WordPress includes a REST API. It lets apps and services talk to your site. Useful feature. Also, sometimes a bit chatty.
On many sites, a bot can visit an endpoint like this:
/wp-json/wp/v2/users
And get back user data in JSON format. Sometimes that includes the username slug, display name, author archive details, and other bits that help identify who can log in.
Maybe not the full story for every setup. Different themes, plugins, and WordPress versions can change what’s exposed. But honestly, even a little leak is often enough.
Here’s a typical problem. A site owner says, “My admin username isn’t admin, so I’m safe.” Then the REST API happily reveals jennifer-storemanager to anyone who asks. Big mistake.
Bots don’t care that your homepage looks harmless. They’re not reading your About page and admiring the logo. They’re poking common endpoints automatically, checking what answers back, and building a shortlist.
It’s not just the REST API, but this is a common shortcut
Usernames can leak in other places too. Author archive URLs. Old sitemap entries. Comment metadata. Plugin output. Even image metadata sometimes, which is just silly.
But the REST API is attractive because it’s fast and scriptable. One request, clean response, easy to parse. Bots love easy.
If you’ve ever wondered why login attacks seem oddly specific, this is usually part of the chain. First they discover the site. Then they identify the software. Then they look for usernames. Then they test weak passwords or reused credentials. Nice and mechanical.
If you want to see how weak admin setups make that even worse, read Admin account mistakes that hand hackers the keys. A leaked username plus a sloppy admin account is a bad combo. I’ve seen this kill a site in a weekend.
How to check if your site is exposing usernames
You don’t need to be a developer for a basic check.
- Open your website in a browser
- Add
/wp-json/wp/v2/usersto the end of your domain - See what loads
If you get a list of users, or even partial data about authors, that’s a sign your site is exposing more than it should.
Now, some setups block this for non-logged-in visitors. Great. Some don’t. Some return errors but still leak clues in a different way. Annoying.
You can also test author archive redirects by trying a URL like:
/?author=1
On some sites, that redirects to an author page with the username in the URL slug. Again, not ideal.
And no, changing your visible display name isn’t enough. That only fixes the obvious surface stuff. The login username underneath may still be exposed.
Why this matters for a small business
Because your website is usually connected to real business activity.
Contact forms. Customer messages. WooCommerce orders. Quote requests. Maybe invoices, maybe booking data, maybe employee accounts. If someone gets into WordPress admin, they may not just deface a page. They can inject spam, steal data, create hidden users, or drop malware that blacklists your domain in Google.
Then you’re dealing with cleanup instead of running the business.
That’s why basic hardening matters more than flashy security talk. You want to reduce easy wins. Make the bot move on to somebody else who left the windows open.
What you should actually do
Here’s the practical part.
- Block public user enumeration through the REST API if your site doesn’t need it
- Disable or limit author archive exposure
- Use a unique admin username, not your name or business email pattern
- Turn on two-factor authentication for every admin account
- Add login rate limiting and bot protection
- Remove unused users, especially old freelancers or ex-staff
That last one gets overlooked alot. Old user accounts sit there forever, quietly becoming a problem.
For most small business sites, I’d start with login protection and username exposure hardening before chasing more exotic stuff. Fancy security dashboards can wait. Close the obvious gaps first.
If you want a simple way to lock down common WordPress weak spots, the one-click hardening tools are built for exactly this kind of thing – trimming off public clues and reducing the easy nonsense bots rely on.
Should you disable the REST API completely?
Usually, no.
That’s the blunt answer.
The REST API is useful. Some plugins, page builders, forms, WooCommerce features, and headless setups rely on it. Killing it completely can break things in weird, frustrating ways. You update one plugin next month and suddenly part of your site stops working and nobody knows why. Not fun.
A better move is to limit what’s exposed publicly while keeping the useful parts working.
So instead of “turn it all off,” think “stop leaking user data to strangers.” Much saner approach.
What this looks like in real life
Say you run a small law firm site. Five pages, a blog nobody updates much, and a contact form. Your admin user is your first name. A bot hits /wp-json/wp/v2/users, gets the username, then tries passwords from old breach lists. If you reused that password years ago on LinkedIn or Adobe or some dead forum from 2016, that’s now your problem.
Or maybe you run a WooCommerce store. You’ve got one admin, one shop manager, and a freelancer account you forgot to remove. Bots find both usernames. They attack the shop manager because people often give those accounts weaker passwords. And suddenly orders are being redirected, checkout scripts are modified, and customers are emailing you screenshots of casino popups. Sounds dramatic. Happens more than you’d think.
Don’t treat this as a tiny issue just because it sounds nerdy
User enumeration isn’t usually the hack by itself. It’s the setup. The recon. The part before the part.
But that setup matters.
If attackers have to guess both username and password, that’s harder. If you hand them the username first, you’ve cut their work in half. Roughly speaking. And bots love shortcuts more than anything.
This is why layered protection works better than a single magic plugin. Hide what doesn’t need to be public. Protect the login page. Use 2FA. Keep plugins updated. Clean out stale accounts. Boring stuff, mostly. Effective stuff too.
If you don’t want to babysit this stuff
Fair enough. Most business owners shouldn’t have to think about JSON endpoints over breakfast.
If your site brings in leads or sales, regular upkeep is usually the smarter route. A proper WordPress maintenance plan helps catch this sort of thing before it turns into login attacks, spam injections, or a very annoying Monday morning.
Because once a site is compromised, cleanup is always more expensive in time, stress, or money. Usually all three.
So check whether your usernames are exposed. Fix it if they are. And don’t assume a small site is invisible.
It isn’t.