Block Author Scans stops attackers from harvesting your WordPress usernames through two well-known leaks: the ?author=N URL trick and the REST API users endpoint. With this on, both return 403 Forbidden for anonymous visitors.

What this feature does

Before brute-forcing your login form, attackers need a list of valid usernames. WordPress hands them two by default:

  • The ?author=N trick: visiting https://yoursite.com/?author=1 redirects to /author/admin/ (or whatever username belongs to user ID 1). Iterating through small numbers reveals every administrator and editor on the site.
  • The REST API users endpoint: a GET to /wp-json/wp/v2/users returns a JSON list of every user with at least one published post, including their slugs (which are usually the login names).

This setting writes .htaccess rules that block anonymous access to both, while letting authenticated administrators continue to use them normally.

A natural pair with Disable REST API

If you also enable Disable REST API, the /wp-json/wp/v2/users path is already blocked. This setting still adds value because it covers the ?author=N trick separately at the server level, before WordPress even runs.

How to enable it

  1. Open AdminEase › Security. Click AdminEase in the WordPress admin menu, then switch to the Security tab.
  2. Toggle Block author scans on. Save settings. AdminEase writes the rules to .htaccess immediately.
  3. Verify. Test from a private/incognito window: curl -I "https://yoursite.com/?author=1" should return 403, and curl -I https://yoursite.com/wp-json/wp/v2/users should also return 403.

Settings reference

Setting What it does Default
Block author scans Writes .htaccess rules that block ?author=N and /wp-json/wp/v2/users for anonymous visitors. Off

What gets written to .htaccess

The rule uses mod_rewrite with conditions to allow legitimate admin traffic through:

# BEGIN AdminEase
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/wp-admin/
    RewriteCond %{HTTP:Authorization} ^$
    RewriteCond %{HTTP_COOKIE} !wordpress_logged_in
    RewriteCond %{QUERY_STRING} author=\d+ [OR]
    RewriteCond %{REQUEST_URI} wp-json/wp/v2/users
    RewriteRule .* - [F,L]
</IfModule>
# END AdminEase

Translation in plain English: if the request is not for /wp-admin/, has no Authorization header, has no logged-in cookie, and either includes ?author=N or hits the users REST endpoint, return 403 Forbidden.

What happens behind the scenes

.htaccess only, conditional on auth

The block runs at the server level via Apache mod_rewrite. The conditions ensure that legitimate traffic isn’t affected: any request from a logged-in user (which carries the wordpress_logged_in_* cookie) bypasses the block. Same for any request inside /wp-admin/ or carrying an Authorization header.

This means content APIs that authenticate via Basic Auth, application passwords, or JWT continue to work. Only fully anonymous probes are blocked.

Troubleshooting

Author archive pages stopped working entirely

The /author/username/ URLs still work. Only the ?author=N redirect (which uses an integer ID) is blocked. If your theme links to author pages by ID, change those links to use the proper author archive permalinks.

I’m on Nginx and the rules don’t apply

Nginx doesn’t read .htaccess. Ask your host to add equivalent location rules: deny ?author=N with an if on $args, and deny /wp-json/wp/v2/users. Or use AdminEase’s Disable REST API for the users endpoint and accept the small leak from ?author=N.

An external site that legitimately lists my authors broke

Either authenticate the request (use an application password) or upgrade your authentication strategy. Anonymous public access to your user list is exactly what this feature blocks; the fix is to switch the consumer to use authenticated access.

Logged-in users still get 403

Check that your auth cookie name is wordpress_logged_in_*. Some hardened setups rename WordPress cookies via COOKIEHASH or custom code. If yours are renamed, the rewrite condition no longer matches and even logged-in users get blocked. Either revert the cookie rename or use the adminease_block_author_scans_code filter to customise the rule.