Stop WordPress User Enumeration: Fix /?author=1 & REST API Leaks

A security scanner flags your WordPress site with "username enumeration possible" and suddenly you're staring at a warning that sounds serious but doesn't come with an obvious fix. Here's what's actually happening, why it matters more than it looks, and how to shut it down without breaking anything else on the site.

Symptom: What the Scanner Is Actually Seeing

User enumeration means an attacker (or a scanner acting like one) can figure out valid WordPress usernames without logging in. Two common ways this leaks out:

• Visiting yoursite.com/?author=1 redirects to something like yoursite.com/author/admin/ — and now your admin username is public.
• Visiting yoursite.com/wp-json/wp/v2/users returns a JSON list of every user with a public-facing slug, including display names.

Neither of these throws an error. Both just quietly hand over information. You can test it yourself right now — open either URL in a private browser tab and see what comes back.

Cause: Why WordPress Does This By Default

This isn't a bug — it's WordPress's default behavior, working exactly as designed. Author archive pages (?author=1) exist so visitors can browse posts by a specific author, which makes sense on a multi-author blog. The REST API users endpoint exists so themes, plugins, and the block editor can pull author info to display bylines and avatars.

The problem is that on a typical small-business or single-author site, nobody's browsing "posts by author," but the endpoint stays open anyway. Once an attacker has a confirmed valid username, they've cut a brute-force login attempt or a targeted phishing email in half — they only need to guess the password, not both fields at once. It's also the first thing most automated vulnerability scanners check, so it shows up on every WPScan-style report even on sites that have never been touched.

Fix: Three Layers, Pick What Fits Your Site

1. Stop using "admin" or your display name as your login

Before touching any code, fix the actual weak point: go to Users → All Users in wp-admin, and check whether your login username matches your public display name (often "admin," or your real name). If it does, create a new administrator account with a different, non-guessable username, log in as that user, then delete the old one — WordPress will ask whether to reassign its posts, so pick "Attribute posts to" your new account. This alone makes enumeration far less useful, since the leaked username won't be the one you actually log in with.

2. Block the author archive redirect

Add this to your theme's functions.php (or better, a small site-specific plugin so it survives a theme switch):

add_action( 'template_redirect', function() {
    if ( is_author() ) {
        wp_redirect( home_url(), 301 );
        exit;
    }
});

This catches both the ?author=1 query string and the resulting /author/username/ page, and bounces the visitor to your homepage instead of revealing anything. If you'd rather not edit theme files, a security plugin like Wordfence or iThemes Security has a toggle for this under its hardening or brute-force settings — usually labeled something like "Disable author scans" or "Hide author usernames."

3. Restrict the REST API users endpoint

This one needs more care, because plugins and the block editor genuinely rely on parts of this endpoint. A full lockdown can break the editor's "author" dropdown or avatar display. The safer middle ground is to strip the response down instead of blocking it outright:

add_filter( 'rest_endpoints', function( $endpoints ) {
    if ( isset( $endpoints['/wp/v2/users'] ) ) {
        unset( $endpoints['/wp/v2/users'] );
    }
    if ( isset( $endpoints['/wp/v2/users/(?P[\d]+)'] ) ) {
        unset( $endpoints['/wp/v2/users/(?P[\d]+)'] );
    }
    return $endpoints;
});

Test wp-admin thoroughly after adding this — specifically the block editor and any plugin that shows author selectors (event calendars, multi-author SEO plugins, membership plugins). If something breaks, you may only need to block the collection endpoint (/wp/v2/users, which lists everyone) while leaving single-user lookups by numeric ID alone, since most legitimate front-end code only needs the latter.

Server-level option: block it before WordPress even loads

If you're on a VPS or have .htaccess access in cPanel, you can stop the request earlier — cheaper on server resources than letting PHP boot up to process a redirect:

# In .htaccess, above the WordPress rules
RewriteCond %{QUERY_STRING} author=\d+
RewriteRule ^ https://yoursite.com/? [R=301,L]

On Nginx (typically a VPS setup), the equivalent goes in your server block:

if ($arg_author ~ "^[0-9]+$") {
    return 301 https://yoursite.com/;
}

Quick Reference

Prevention: Close the Loop, Don't Just Patch One Hole

• Pair this with login protection. Blocking username discovery matters a lot less if /wp-login.php still allows unlimited guesses — enable a lockout after a few failed attempts (Fail2Ban on a VPS, or a plugin like Limit Login Attempts Reloaded on shared cPanel hosting).
• Check comment author links too. If comments are open, published comment author names can sometimes match usernames — not a WordPress core leak, but worth a glance if you're locking things down for a client site.
• Re-scan after changing your username. Old scanner reports and cached search engine results may still show the previous username for a while — that's expected and not a sign the fix failed.
• Don't rely on "security through obscurity" alone. This fix removes an easy first step for an attacker, but it's not a replacement for strong, unique passwords and two-factor authentication on every admin account.

Frequently Asked Questions

Will blocking the REST API users endpoint break my site?

It can, if a plugin or the block editor depends on it for author dropdowns or avatars. Always test wp-admin (especially the editor) after adding the filter. If something breaks, scope the block to just the collection endpoint (the list of all users) rather than individual user lookups.

My scanner still flags user enumeration after I fixed the author archive — why?

Most scanners check both the author archive redirect and the REST API endpoint separately. Fixing one doesn't fix the other. Also double-check the fix actually applied by testing both URLs in an incognito window — a caching plugin or CDN can sometimes serve a cached version of the old, unprotected page for a while.

Is this worth fixing on a small site nobody's targeting specifically?

Yes — most WordPress attacks aren't targeted at you personally, they're automated bots scanning thousands of sites for exactly this kind of low-effort weakness. Closing it takes a few minutes and removes your site from the "easy target" pile.

Do I need a security plugin for this, or can I do it with just code?

Code snippets work fine and add zero overhead. A security plugin is worth it if you want the toggle in a UI, or if you're already using one for other hardening (firewall rules, login lockouts, file change detection) and don't want another custom snippet to maintain.

Does changing my WordPress username affect my post author byline?

No — your public display name (shown as "by [name]" on posts) is separate from your login username and won't change unless you edit it under Users → Your Profile. You can have a private login username and a completely different public display name at the same time.