Stopping user enumeration (author archives and REST users)

Someone probing your site for valid usernames is often gathering material for a password-guessing attack. WordPress leaks usernames in two default places: author archive pages (/?author=1 or /author/admin/) and the REST API's users endpoint (/wp-json/wp/v2/users). Fix both with settings and a small snippet before reaching for a plugin.

Check what you're exposing

Visit yoursite.com/?author=1 in a browser. If WordPress redirects you to a URL like /author/yourusername/, that username is public. Repeat for author=2, author=3, and so on to see every account WordPress will hand out.

Then check yoursite.com/wp-json/wp/v2/users. If it returns a JSON list with slug values, that's every author's username, in one request, no login needed.

Turn off author archives

If you don't use author pages, and most single-author or small-team sites don't, you can stop WordPress from generating them at all. Two ways to do this without a plugin:

• Redirect author archives to the homepage. Add this to your theme's functions.php (via wp-admin → Appearance → Theme File Editor, or better, a small site-specific plugin so a theme update doesn't wipe it):

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

That closes the archive page itself, but WordPress still resolves ?author=1 internally before the redirect fires, so pair it with the fix below.

• Stop the ?author=ID lookup from ever surfacing a username. The redirect above already handles this case since is_author() is true whether the URL came in as ?author=1 or the pretty permalink.

If you do use author pages (a multi-author blog, for example), skip the redirect and instead make sure your display name isn't your login name. Go to wp-admin → Users → your profile → Nickname, fill it in, then set Display name publicly as to that nickname. Do this for every author account. The archive URL still exists, but it no longer reveals the login username.

Hide the REST API users endpoint

The /wp-json/wp/v2/users endpoint is the bigger leak because it's structured data, easy to script against. For sites that don't rely on the public users endpoint (most don't, unless a theme or plugin queries author info client-side), restrict it to logged-in requests:

function fc_restrict_rest_users( $result, $server, $request ) {
    if ( strpos( $request->get_route(), '/wp/v2/users' ) === 0 && ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_forbidden',
            'Users endpoint disabled.',
            array( 'status' => 401 )
        );
    }
    return $result;
}
add_filter( 'rest_pre_dispatch', 'fc_restrict_rest_users', 10, 3 );

Add this alongside the author-archive snippet in the same site-specific plugin. Test /wp-json/wp/v2/users again afterward while logged out; it should return a 401 instead of a name list.

When a plugin makes sense

The snippets above cover the two most common leaks with zero added plugin weight, which matters since every active plugin is something to keep updated and something that can conflict with others (see My WordPress site is slow on plugin overhead). Reach for a security plugin instead if you want enumeration blocking bundled with other hardening (login attempt limits, file integrity checks) in one place, or if you're not comfortable editing functions.php directly. A general security plugin will usually cover both fixes above as toggles.

Either way, test changes like this on a staging copy first. See Using WordPress staging. Staging gives redirect logic and REST filters a realistic test, including how the cache layer handles them, before they hit live visitors.

Before you edit functions.php

A bad edit to functions.php can take the whole site down (a stray semicolon is enough). Your account's Backups tile keeps nightly copies of your site, so a bad edit isn't unrecoverable. See Backing up your WordPress site for how the backup layers work.

When to contact support

If you've applied both fixes and still see usernames leaking, or a plugin conflict breaks the redirect, open a ticket from the portal's Support section. It reaches a real person, not a bot, and they can look at the specific behavior on your account.