How Hackers Find Your WordPress Username (and How to Stop Them)
Typing ?author=1 on any WordPress site reveals the admin username. Attackers use this for brute force login. Here's how to block author enumeration.
Try this on your WordPress site right now: add ?author=1 to your homepage URL. Like this: yoursite.com/?author=1. Press Enter.
If you haven’t taken steps to block this, WordPress will redirect you to yoursite.com/author/admin/ (or whatever your admin username is). You just discovered the admin username in 2 seconds.
This is called author enumeration, and every bot on the internet knows this trick. It’s the first step in a brute force attack: find the username, then start guessing passwords.
What is author enumeration?
WordPress assigns a numeric ID to every user, starting with 1 for the first (usually admin) account. When you request ?author=1, WordPress looks up user ID 1 and redirects to their author archive page. The URL of that page contains the username slug.
Attackers don’t stop at ?author=1. They cycle through ?author=2, ?author=3, and so on, mapping every user account on your site in seconds. Automated tools do this at machine speed.
But the URL parameter isn’t the only leak. WordPress also exposes usernames through:
- REST API —
yoursite.com/wp-json/wp/v2/usersreturns a JSON list of all users with their slugs - Author archives — direct URLs like
/author/username/ - oEmbed endpoints — the
author_urlfield in oEmbed responses - RSS feeds — the
<dc:creator>field in feed entries - Login error messages — “The password you entered for username X is incorrect”
That’s five different ways your WordPress site broadcasts user information by default.
Why should you care?
It’s step one of every brute force attack. Knowing the username cuts the attacker’s work in half. Instead of guessing both username and password, they only need to guess the password. With leaked password databases containing billions of entries, a known username dramatically increases the chance of a successful attack.
The REST API makes it trivially easy. A single API request to /wp-json/wp/v2/users returns every public user’s name, slug, description, and avatar URL in clean JSON. No authentication needed. It’s like publishing your employee directory with login credentials hints.
It confirms WordPress is installed. The ?author=1 redirect pattern is a fingerprint that confirms WordPress is running and active. Combined with the version number, this gives attackers a complete reconnaissance picture.
The quick fix
Block the ?author= parameter:
// Block author enumeration via URL parameter
add_action( 'init', function() {
if ( ! is_admin() && isset( $_GET['author'] ) ) {
wp_redirect( home_url(), 301 );
exit;
}
});Block the REST API users endpoint (for non-authenticated requests):
// Block public access to REST API users endpoint
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( ! is_user_logged_in() ) {
if ( isset( $endpoints['/wp/v2/users'] ) ) {
unset( $endpoints['/wp/v2/users'] );
}
if ( isset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] ) ) {
unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
}
}
return $endpoints;
});Together, these close the two most common enumeration vectors. For complete protection, also consider disabling author archives and hiding login error messages (separate switches in Ovanap Admin Toolkit: Disable author pages and Hide login error hints).
The one-click solution
Ovanap Admin Toolkit includes Hide author usernames from URL probing under Admin Toolkit → Features → Security. One switch sends any front-end request with a numeric ?author= parameter to the homepage with a 301 redirect. It does not touch the REST API or feeds: the users endpoint has its own switch, Block public user list API, which removes the endpoint for everyone, logged in or not.
What happens after you fix this?
?author=1returns a 301 redirect to the homepage instead of revealing the username- The REST API users endpoint stops answering logged-out requests — WordPress returns a 404 (
rest_no_route) because the route no longer exists - Brute force bots lose their first reconnaissance step — they don’t know which usernames to target
- Your site looks less like a WordPress target — one fewer default behavior pattern
FAQ
Will this break my author archive pages?
The code above blocks the ?author=1 query parameter redirect, not the author archive itself. Direct visits to /author/username/ still work if you want author archives visible. For complete username hiding, you’d also want to disable author archives or change the author slug to something other than the username.
Does blocking the REST API users endpoint break Gutenberg or plugins?
Not with the code above, because the block only applies to non-authenticated requests. When you’re logged into WordPress, the REST API users endpoint works normally. Ovanap Admin Toolkit’s Block public user list API switch is stricter: it removes the endpoint for logged-in users too, so check that the author selector in the block editor and any plugin that lists users still work after you turn it on.
What about usernames in my blog post bylines?
The display name shown on posts (like “Tomas” or “Admin”) can be different from the login username. Go to Users → Your Profile and change “Display name publicly as” to your first name or a nickname — never your login username.
Related reads: