Look, if you’re running a WordPress site, there’s a decent chance someone’s already tried to figure out your usernames. Yeah, I know—creepy, right? But here’s the thing: WordPress, by default, basically hands out your usernames like Halloween candy. This is called user enumeration, and while it won’t break into your site by itself, it’s like giving burglars a list of which doors to try picking.
Let me break down what’s happening, why you should care, and—most importantly—how to slam that door shut.
What the Heck is User Enumeration Anyway?
User enumeration is just a fancy way of saying „finding out who has accounts on your site.“ Think of it like this: if someone wants to break into your house, knowing which doors exist is step one. They still need keys (passwords), but now they know exactly where to focus their efforts.
In WordPress, attackers can discover usernames through several sneaky methods:
Method 1: The Classic Author Archive Trick
WordPress creates author archive pages for anyone who’s written a post. Just add ?author=1 to any WordPress URL and boom—you get redirected to something like /author/admin/. Attackers can automate this, checking ?author=1, ?author=2, ?author=3, and so on until they’ve mapped out all your users.
Example of what attackers do:
|
1 2 3 4 5 6 7 |
# They literally just cycle through numbers https://yoursite.com/?author=1 https://yoursite.com/?author=2 https://yoursite.com/?author=3 # ... and so on |
Each redirect reveals a username. Pretty straightforward, pretty annoying.
Method 2: The REST API Goldmine
This one’s even easier for attackers. WordPress has a REST API (basically a way for apps to talk to your site), and by default, it exposes user information at:
|
1 2 3 |
https://yoursite.com/wp-json/wp/v2/users |
Hit that URL and you get a nice JSON response with usernames, IDs, and other juicy details. No authentication required. It’s like leaving your employee directory on the front lawn.
Method 3: The oEmbed Backdoor
WordPress uses oEmbed to embed content from other sites. But guess what? When you request an oEmbed for a post, it includes author information. Yep, another way to leak usernames that most people don’t even think about.
Why Should You Actually Care?
Okay, so someone knows your username is „admin“ or „sarah“—so what? Here’s the deal:
- Brute Force Attacks Get Way Easier: Instead of guessing both username AND password, attackers only need to guess passwords. That cuts their workload in half.
- Targeted Attacks: Knowing your users helps attackers craft more convincing phishing emails or social engineering attacks.
- It’s Just Bad Security Hygiene: Defense in depth, people! Every little bit of information you leak makes an attacker’s job easier.
Let’s Fix This Thing: Solutions That Actually Work
Alright, enough doom and gloom. Here are the actual solutions, ranging from „dead simple“ to „I want to control everything.“
Solution 1: Plugin It (The Easy Way)
If you just want this fixed without getting your hands dirty, install the Stop User Enumeration plugin. It’s free, it’s maintained, and it works.
What it does:
- Blocks the
?author=queries - Disables REST API user endpoints
- Can integrate with fail2ban for repeat offenders
- Logs suspicious activity
Installation:
- Go to Plugins → Add New
- Search for „Stop User Enumeration“
- Install and activate
- Check Settings → Stop User Enumeration to make sure everything’s enabled
Done. Seriously, that’s it for most people.
Solution 2: Functions.php Method (For the DIY Crowd)
Want to handle it yourself? Add this code to your theme’s functions.php file (or better yet, create a custom plugin so theme updates don’t wipe it out):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
<?php // Block author enumeration via ?author= parameter if (!is_admin()) { // Check default URL format if (preg_match('/author=([0-9]*)/i', $_SERVER['QUERY_STRING'])) { wp_die('Nice try, buddy. No user enumeration here.', 'Forbidden', array('response' => 403)); } add_filter('redirect_canonical', 'stop_user_enum_redirect', 10, 2); } function stop_user_enum_redirect($redirect, $request) { // Check permalink format if (preg_match('/\?author=([0-9]*)(\/*)/i', $request)) { wp_die('Access denied.', 'Forbidden', array('response' => 403)); } return $redirect; } // Disable REST API user endpoints for non-authenticated users add_filter('rest_endpoints', 'disable_rest_api_user_endpoints'); function disable_rest_api_user_endpoints($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; } // Remove author info from oEmbed add_filter('oembed_response_data', 'disable_oembed_author_info'); function disable_oembed_author_info($data) { unset($data['author_name']); unset($data['author_url']); return $data; } ?> |
What this code does:
- Blocks anyone trying to access
?author=URLs - Removes REST API user endpoints for logged-out users
- Strips author info from oEmbed responses
- Returns a 403 Forbidden error instead of revealing info
Solution 3: The .htaccess Nuclear Option
If you’re on Apache and want to block this at the server level (before WordPress even loads), add this to your .htaccess file:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# Block user enumeration via author parameter <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / # Block ?author= queries RewriteCond %{QUERY_STRING} ^author=([0-9]*) [NC] RewriteRule ^(.*)$ - [F,L] # Block REST API user endpoints RewriteRule ^wp-json/wp/v2/users/?$ - [F,L] RewriteRule ^wp-json/wp/v2/users/([0-9]+)/?$ - [F,L] </IfModule> |
Nginx Users? Here’s your equivalent:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# Block author enumeration location ~ ^/\?author=([0-9]*) { deny all; return 403; } # Block REST API user endpoints location ~ ^/wp-json/wp/v2/users { deny all; return 403; } |
Solution 4: The Selective REST API Approach
Maybe you actually NEED the REST API for some functionality (like Gutenberg editor features or integrations). In that case, use this more surgical approach:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
<?php // Only disable GET requests to user endpoints add_filter('rest_endpoints', 'selectively_disable_user_endpoints'); function selectively_disable_user_endpoints($endpoints) { $routes = array( '/wp/v2/users', '/wp/v2/users/(?P<id>[\d]+)' ); foreach ($routes as $route) { if (empty($endpoints[$route])) { continue; } foreach ($endpoints[$route] as $i => $handlers) { if (is_array($handlers) && isset($handlers['methods']) && 'GET' === $handlers['methods']) { // Only remove GET methods, keep POST/PUT/DELETE for authenticated users unset($endpoints[$route][$i]); } } } return $endpoints; } ?> |
This keeps the REST API functional for authenticated requests but blocks public GET requests that expose user data.
Advanced Hardening: Go Full Paranoid Mode
If you really want to lock things down, combine multiple approaches:
1. Change Your Admin Username
Seriously, if you’re still using „admin“, stop reading and change it right now. Go to Users → Add New, create a new admin account with a weird username like „k9j3mf2x“, then delete the old „admin“ account.
2. Implement Fail2Ban Integration
The Stop User Enumeration plugin can log attempts to your system logs. Pair this with fail2ban to automatically ban IPs that repeatedly try to enumerate users:
|
1 2 3 4 5 6 |
# Example fail2ban filter (/etc/fail2ban/filter.d/wordpress-enum.conf) [Definition] failregex = ^.*WordPress user enumeration attempt from <HOST>.*$ ignoreregex = |
3. Hide Login Errors
WordPress helpfully tells attackers whether a username exists when they try to log in. Disable this:
|
1 2 3 4 5 6 7 |
<?php add_filter('login_errors', function() { return 'Invalid credentials. Try again.'; }); ?> |
Now both invalid usernames AND wrong passwords get the same generic error.
4. Implement Rate Limiting
Use a plugin like Limit Login Attempts Reloaded or configure your WAF (Web Application Firewall) to throttle repeated requests to author pages or REST endpoints.
5. Use Strong Passwords (Duh)
Even if someone knows your username, a strong password (20+ characters, random) makes brute force attacks practically impossible. Use a password manager. Please.
Testing Your Defenses
After implementing these fixes, test them:
- Test author enumeration: Try accessing
https://yoursite.com/?author=1in an incognito window. You should get blocked or see an error, not a redirect. - Test REST API: Visit
https://yoursite.com/wp-json/wp/v2/userswhile logged out. You should get an error or empty response. - Use online scanners: Services like Sucuri SiteCheck or WPScan can test your site for common vulnerabilities, including user enumeration.
Real Talk: Does This Really Matter?
Yes and no. User enumeration alone won’t hack your site. But security is about layers. Every piece of information you leak makes the next step easier for attackers. It’s like leaving your address, schedule, and alarm code written on sticky notes outside your house. Sure, someone still needs to actually break in, but you’re not exactly making it hard.
Plus, fixing this takes like 5 minutes. Why NOT do it?
The TL;DR Version
- WordPress leaks usernames by default through author archives, REST API, and oEmbed
- This helps attackers with brute force and targeted attacks
- Quick fix: Install „Stop User Enumeration“ plugin
- Manual fix: Add the code snippets from this article to functions.php
- Server fix: Use .htaccess or nginx rules to block at the server level
- Bonus points: Change default admin username, use strong passwords, implement rate limiting
Thoughts
Look, WordPress is awesome, but it’s also the #1 target for automated attacks simply because it’s so popular. User enumeration is one of those „death by a thousand cuts“ vulnerabilities—not catastrophic by itself, but it sure doesn’t help.
Take 10 minutes, implement one of these solutions, and sleep a little better knowing you’ve closed off one more avenue of attack. Your future self (and your clients, if you’re managing sites for others) will thank you.
Now go forth and stop those enumeration attempts. And maybe while you’re at it, update your plugins too. I know you’ve been putting it off. 😉
FAQ
Is WordPress secure enough for my website?
WordPress is generally secure if you keep it updated with the latest security patches and plugins. The core software is regularly audited by hundreds of developers and receives regular updates. However, it’s not 100% foolproof and requires proper precautions like using strong passwords, keeping everything updated, limiting login attempts, and installing reputable security plugins. With 810 million websites globally using WordPress, following best practices is essential to maintain security.
How often should I update WordPress plugins and themes?
Update plugins and themes immediately when security patches become available. For routine updates, check weekly and apply updates within 48 hours. You should enable automatic updates for critical security plugins and well-maintained plugins with good track records. In 2024 alone, nearly 8,000 new vulnerabilities were found in plugins and themes, making timely updates crucial for security.
What are the most common WordPress security threats?
The most common WordPress security threats include brute force attacks (where bots try thousands of password combinations per second), plugin and theme vulnerabilities (56% of WordPress vulnerabilities are plugin-related), malicious code injection, SQL injection attacks, cross-site scripting (XSS), phishing attacks, and weak passwords. WordPress faces over 90,000 automated attacks daily, with WordFence blocking over 86 billion password attacks in 2021 alone.
Should I use „admin“ as my WordPress username?
No, never use „admin“ or „administrator“ as your WordPress username. Thousands of WordPress sites still use these default usernames, making it significantly easier for attackers who only need to guess the password. Create a new account with a unique, less guessable username, give it administrator privileges, and delete the original admin account. WordPress will reassign all content to the new account.
What makes a strong WordPress password?
A strong WordPress password should have at least 20 characters and include a mix of uppercase letters, lowercase letters, numbers, and special characters. Use long, random, and unique passwords that you’ve never used elsewhere. Let WordPress generate passwords for you and store them in a password manager like Bitwarden, 1Password, or LastPass. Avoid variations of „admin123“ or easily guessable passwords, as bots can try thousands of combinations in seconds.
What is two-factor authentication (2FA) and do I need it?
Two-factor authentication (2FA) is one of the most effective low-effort security upgrades you can make. Even if your password gets leaked, 2FA can stop attackers completely. You can use apps like Google Authenticator or Authy. Most good security plugins support 2FA for admin logins. Generate backup codes and store them in a safe location in case you lose access to your 2FA device. Start by requiring 2FA for administrators at minimum.
Which WordPress security plugins should I use?
Popular and effective WordPress security plugins include Wordfence Security (provides firewall protection, malware scanning, and brute force attack prevention), Sucuri Security (offers website firewall and security monitoring), Jetpack Security (includes real-time backups, web application firewall, malware scanning, and spam protection), iThemes Security, and WPS Hide Login. These plugins offer comprehensive protection including malware scans, login security, and threat detection.
How often should I backup my WordPress site?
For static sites, once a week might be sufficient. For busy blogs or eCommerce stores, perform daily backups or more frequently. Store backups offsite using cloud storage, a secure remote server, or local storage with disciplined syncing. Never rely on your host’s backups alone. Most importantly, test your backup and restoration process to ensure it works when you need it. Always create a backup before performing any updates.
What is a brute force attack and how do I prevent it?
A brute force attack is when hackers use bots to try different username and password combinations—thousands per second—until they find the right one. It’s one of the most common ways hackers access WordPress sites. Prevent brute force attacks by using strong, unique passwords, implementing two-factor authentication, limiting login attempts with plugins like Login LockDown, changing your login URL, and using security plugins that block suspicious IP addresses.
Do I need an SSL certificate for my WordPress site?
Yes, an SSL certificate is essential for WordPress security. It encrypts data transmitted between your site and visitors, protecting sensitive information like passwords and payment details. Search engines like Google prioritize secure websites with SSL certificates in their rankings, improving your SEO visibility. Most good hosting providers offer free SSL certificates that install in just a few minutes.
What should I do if my WordPress site gets hacked?
If your site is hacked, take immediate action: reach out to your hosting provider for assistance, install a security plugin like Wordfence or Sucuri to scan for malicious files, restore your site from a recent clean backup (from before the attack), change all passwords including WordPress admin, FTP, database, and hosting accounts, update your security keys and salts in wp-config.php, and notify affected users if sensitive data was exposed. Consider hiring a WordPress security service if you need expert help.
How do I check if a plugin is safe before installing it?
Before installing a plugin, check its last update date (avoid plugins not updated in over a year), review user ratings and number of active installations, read the support forum to assess developer responsiveness, verify compatibility with your WordPress version, use tools like WPScan to identify known vulnerabilities, and test new plugins on a staging site first. Avoid nulled plugins as they lack security patches and create vulnerable entry points.
What file permissions should I use for WordPress?
Set folder permissions to 755 and file permissions to 644 for optimal security. The wp-config.php file should have restricted access. Connect to your server via SSH (Secure Shell) for secure access. Disable file editing in the wp-config.php file to prevent unauthorized code modifications. Stop directory listing by adding the required code to your .htaccess file.
What is a Web Application Firewall (WAF) and do I need one?
A Web Application Firewall (WAF) helps stop common cyberattacks including SQL injections, cross-site scripting (XSS), and cross-site request forgeries (CSRF) through complex systems of rules. Most security plugins like Jetpack Security and Wordfence include sophisticated WAFs with rulesets designed from years of experience dealing with WordPress attacks. Your best approach is to use a web host or security plugin that sets up a WAF for you automatically.
How can I hide my WordPress login page?
Install and activate the WPS Hide Login plugin, which helps hide your WordPress login details by changing the default wp-login.php URL to a custom URL of your choice. This makes it harder for automated bots to find and target your login page, reducing brute force attack attempts significantly. Remember to save your new login URL in a secure location.
Why is choosing a good hosting provider important for WordPress security?
A reliable web host offers server and site security, quality customer service, high uptime scores, automated site backups, and handles technical infrastructure securely. Managed WordPress hosting providers like WP Engine or SiteGround are optimized for WordPress and offer advanced caching, security features, and dedicated support. Poor hosting with outdated software and weak security measures significantly increases your vulnerability to attacks.
What are WordPress security keys and salts?
WordPress security keys and salts are cryptographic elements stored in your wp-config.php file that encrypt information stored in cookies, making your site more secure. They help protect your login credentials and user sessions from being intercepted. If your site is compromised, changing these keys and salts can help invalidate stolen login credentials. WordPress provides a generator for creating new security keys and salts.
Should I disable XML-RPC on my WordPress site?
Yes, disable XML-RPC if you don’t require it, as it’s a common attack target. XML-RPC allows external applications to communicate with WordPress but can be exploited for brute force attacks and DDoS attacks. Unless you specifically need it for mobile apps or external integrations, disabling XML-RPC enhances your site’s security. Most security plugins offer options to disable or restrict XML-RPC access.
What happens if my WordPress site gets hacked?
A hacked WordPress site can cause serious damage including data theft, lost revenue from decreased views and sales, costs involved in restoration, permanent loss of search engine rankings, customer trust damage, legal liabilities and fines (especially if customer data is compromised), website downtime disrupting operations, removal from ad networks affecting revenue, and distribution of malware to your users. Prevention through proper security measures is far easier and cheaper than recovery.
How do I scan my WordPress site for malware?
Scan for malware using security plugins like Wordfence Security or Sucuri Security, which go through your site’s files, plugins, and themes looking for malware infections. Run malware scans weekly or monthly to detect and clean up any viruses. Set up email alerts to receive notifications of detected threats. Tools like SiteCheck by Sucuri can also scan your site externally. If you see a sudden drop in website traffic or search rankings, perform a manual malware scan immediately.
