☰
WEB SECURITY / PRACTICE

How to Protect WordPress from User Enumeration and Login Discovery

How to Protect WordPress from User Enumeration and Login Discovery

User enumeration is the process of identifying real usernames on a website. WordPress may expose them through author archives, the ?author=1 parameter, the REST API, RSS, and various messages on the login page.

A username alone does not provide access to the administration panel, but it reduces the number of unknowns in a brute-force attack. It is therefore worth minimizing public clues without creating a false sense of complete protection: 2FA, login attempt limits, updates, and strong passwords are also required.

What Is User Enumeration in WordPress?

User enumeration is a class of attacks in which an automated script checks which usernames or author names exist on a website. In many cases, an attacker does not target the entire site at random, but first collects a list of potential users, administrators, and editors.

For this purpose, attackers use URLs such as /author/admin/, requests such as /?author=1 and /?author=2, and sequential post IDs. If WordPress or the server redirects such a request to an author page, the username may appear in the Location header or URL.

The login form can provide additional information. Messages such as “the user does not exist” or “the password is incorrect” make it possible to distinguish a real account from a fictitious one. This is not a vulnerability by itself, but it makes password guessing easier.

  • author archives and links to author pages;
  • the ?author=1 parameter and similar requests with other IDs;
  • the REST API, if it publicly returns a list of users;
  • RSS, sitemaps, or templates that display login or user_nicename;
  • different messages after an unsuccessful login attempt.

Close Author Archives and ?author= Requests

If the site does not use public author pages, it is better to redirect them to the homepage or return a 404 response. This removes one of the most common ways of obtaining usernames.

Check not only URLs such as /author/admin/, but also numeric requests. In some configurations, WordPress first processes ?author=1 and then performs a canonical redirect to the author page. It is therefore important to test the actual server response, not just how the page looks in a browser.

The example below is intended for a site where author archives are not required. It is better to add the code to a site-specific plugin or mu-plugin rather than directly to the theme file: the rule will remain in place after the theme is changed. Start with a temporary 302 redirect, test the site, and change it to a permanent redirect if necessary.

  • Do not redirect author pages if they are part of the blog structure or are needed for SEO.
  • Check whether links in the sitemap, RSS, breadcrumbs, and Elementor templates stop working.
  • A redirect to the homepage must not replace proper authentication for access to the administration panel.
add_action('template_redirect', function () {
    if (is_author() || get_query_var('author')) {
        wp_safe_redirect(home_url('/'), 302);
        exit;
    }
});

When Is It Better to Return a 404?

If author archives are definitely not used, returning a 404 status is more logical than creating a chain of redirects. The implementation depends on the theme, caching, and server configuration, so it should be tested separately. A simple redirect to the homepage is technically easier, but it does not tell search engines that the page no longer exists.

  • Do not create an endless redirect if the homepage also uses author-related query parameters.
  • After making the change, clear the WordPress, CDN, and reverse-proxy caches if applicable.

Do Not Display the Login in Profiles or Public Content

In WordPress, a user's login and public name are different values. For posts, comments, and profiles, use a neutral Display name: a personal name, team name, or pseudonym. Do not display a value on the site that matches the login.

Changing a login directly in the database is dangerous: it may damage relationships, integrations, post authorship, or the operation of third-party plugins. If an old login is already known and needs to be replaced, it is safer to create a new user with the correct details, transfer the content to that account, and delete or block the old account after verification.

Pay particular attention to administrators. Do not use obvious logins such as admin, administrator, webmaster, or the domain name. An author's public name may be clear to readers, but it should not match the technical login used to sign in.

  • Check the authors of older posts, team pages, comments, and widgets.
  • Do not place the login in a profile URL unless there is a genuine need.
  • Do not pass usernames in JavaScript, HTML comments, or publicly accessible API responses.
  • Use separate administrator logins for each site.

Use the Same Login Error Message in Every Case

The wp-login.php form or a custom login form may reveal whether a specified user exists. To protect against this, use one neutral message regardless of the reason for the failure: an incorrect login, an incorrect password, or a nonexistent account.

The standard WordPress filter changes the error text on the login page. This example applies to the classic wp-login.php form; an Elementor form or membership plugin may have its own messages, which must be configured separately.

  • Do not tell the user exactly what was incorrect—the login or the password.
  • Make sure the message does not differ in the HTTP response, processing time, or HTML code.
  • Do not hide messages about CAPTCHA or 2FA challenges: the user needs to understand what additional action is required.
add_filter('login_errors', function () {
    return 'Невірні облікові дані.';
});

Check the REST API and Other Public Data Sources

In some configurations, a request to the REST API may return a list of users, for example through the /wp-json/wp/v2/users endpoint. Even if author archives are closed, this endpoint can expose names, avatars, and profile links.

Before blocking the REST API, determine whether it is used by a mobile application, editor, integrations, WooCommerce, or a custom frontend. Completely disabling the API may break site functionality. It is better to restrict public access to users specifically and test the change on a copy of the site.

Also review RSS, sitemaps, JSON-LD, comments, search results, and Elementor templates. A plugin or custom code may display an author's name even after the standard archive has been disabled.

  • Check /wp-json/wp/v2/users without authentication.
  • Do not expose more of the API than the site requires.
  • Do not hide data with CSS alone: it will still remain in the HTML.
  • After making changes, check cached responses from the CDN and server cache.

How to Test a Site for User Enumeration

Perform the check in incognito mode or without an administrator session. Review not only the page content, but also the HTTP status code, the Location header, the final URL, and the response text.

A few requests are enough for a basic check. You can run the commands from a computer with the curl utility available.

  • Open /?author=1, /?author=2, and several subsequent values.
  • Check /author/admin/, /author/administrator/, and known old author names.
  • Review /wp-json/wp/v2/users without logging in to the administration panel.
  • Try to log in with a real and a fictitious username and compare the messages.
  • Check whether XML-RPC, RSS, the sitemap, or search pages expose usernames.
curl -I https://example.com/?author=1
curl -I https://example.com/author/admin/
curl -s https://example.com/wp-json/wp/v2/users
curl -s -X POST https://example.com/wp-login.php -d 'log=unknown-user&pwd=wrong-password'

What Else Is Needed to Protect Login Access?

Hiding usernames reduces the amount of information available for an automated attack, but it does not stop password guessing. Usernames may be obtained from data breaches, phishing, old emails, or other websites.

For comprehensive hardening, configure multifactor authentication for administrators, rate limiting, and blocking of suspicious requests. Use unique, long passwords; keep WordPress, the theme, plugins, and Elementor up to date; and remove unused extensions.

At the server or WAF level, you can limit frequent requests to wp-login.php and XML-RPC, but the rules must not block legitimate users, webhooks, or integrations. Make a backup before changing anything and review the error log.

  • Enable 2FA at least for administrators and editors.
  • Apply rate limiting to the login form.
  • Use separate accounts instead of a shared admin account.
  • Configure notifications for failed logins and suspicious activity.
  • Regularly check backups and the ability to restore them.

Frequently asked questions

Is hiding the username enough to protect WordPress?

No. It only reduces the amount of information available to an attacker. Protection also requires unique passwords, 2FA, login attempt limits, updates, and access control.

Should the REST API be disabled completely?

Not necessarily. The REST API is required by many themes, integrations, and plugins. First check which endpoints the site uses, and restrict only the public user listing if doing so does not break functionality.

Can I simply rename admin in the database?

This is not recommended without a backup and an understanding of the WordPress data structure. Direct changes may affect integrations and third-party plugins. To replace an account, it is better to create a new user and transfer the content correctly.

Does Elementor affect user enumeration?

Elementor itself is not the cause of this issue, but its templates, forms, and dynamic widgets may display authors or different error messages. Review public templates and the login form separately if it was created with Elementor or a third-party plugin.

Conclusion

For basic WordPress protection, close author archives, do not publish technical usernames, standardize login form messages, and check the REST API and other data sources.

Then test the site without authentication and strengthen the protection with two-factor authentication, rate limiting, unique passwords, and regular updates. User enumeration cannot be eliminated with a single setting, but addressing it significantly reduces the amount of information available to automated attacks.

← All web security materials