Here's an experiment you can run in thirty seconds, and I genuinely wish fewer people would. Open an incognito window and visit any WordPress site's REST API users endpoint — that's the site's address followed by /wp-json/wp/v2/users. On a shocking number of production sites, the server cheerfully hands back a list of every registered user, complete with usernames. No login. No rate limit. Just the raw material an attacker needs to start a credential-stuffing campaign against every author account on the site.
This isn't a hypothetical. Username enumeration through the REST API is one of the oldest and most consistently exploited WordPress attack vectors, and it still works in 2026 because site owners either don't know it's exposed or assume their security plugin handles it. The REST API is genuinely useful — it powers headless frontends, mobile apps, and integrations. But its defaults were designed for openness, not for a production site getting probed by bots at 3 AM. Here's how to close the gaps properly.
Know What's Actually Exposed
Before hardening anything, audit what's visible. WordPress registers dozens of REST routes, and plugins add their own — sometimes with sloppy permission checks. A quick inventory is step one. In WP-CLI, the route list command shows every registered endpoint; look specifically for anything returning user data, settings, or internal state. You can also just curl the index at /wp-json/ and read the routes yourself. What surprises most people is the volume: user endpoints, search endpoints, oEmbed, block directory lookups — a whole surface area they never asked for.
The classic leak is /wp-json/wp/v2/users, which exposes usernames (and in some configurations, enough profile data to aid social engineering). The second classic is author archive enumeration: requesting /?author=1 redirects to the author's archive page, revealing the username in the URL. Attackers automate both. The username is half of every login credential pair, and WordPress login pages are already hammered by bots guessing the other half. Handing out the first half for free is just bad manners.
Then there's xmlrpc.php, the legacy XML-RPC endpoint. It's the gift that keeps on giving to attackers: it enables system.multicall, which lets a single HTTP request carry hundreds of login attempts — a built-in amplifier for brute-force attacks. If you don't have a specific integration that needs it (the WordPress mobile app moved to the REST API years ago), it should be dead. Block it at the web server level so the request never even reaches PHP.
Shut Down User Enumeration
The single highest-value fix is restricting who can list users. For a traditional site that doesn't need public user data, the right move is simple: require authentication for the users endpoints. WordPress provides the rest_authentication_errors filter for exactly this. A small snippet in a must-use plugin can return an authentication error for unauthenticated requests to user routes while leaving the rest of the API functional for whatever your theme or integrations need.
For mixed-use sites — say a headless setup where the frontend legitimately needs author names — don't nuke the whole endpoint; restrict it surgically. Filter the users collection query so it only returns data for users with published posts, strip fields you don't need from responses, and consider a custom namespace for your own endpoints rather than piggybacking on the default ones. The principle is least privilege applied to data: every field returned to an anonymous request should be there for a reason.
Kill the author-scan vector too. A redirect rule or small filter that stops /?author=N from resolving to usernames closes a leak that REST API fixes alone won't cover. And remove the REST API discovery link from your HTML head — there's no reason to advertise the API index to every crawler that views your page source.
Authentication: Application Passwords Done Right
When something does need to talk to your REST API — a mobile app, a headless frontend's build server, an automation — the question is how it proves who it is. WordPress has had Application Passwords built into core since version 5.6, and for most agency use cases they're the sweet spot: per-user, per-purpose credentials with individual revocation, working over standard HTTP Basic Auth. No plugin required.
The discipline matters more than the mechanism. Generate a separate application password for each integration, name it clearly ("Headless build server," "Mobile app staging"), and store it like the secret it is — in your deployment platform's environment variables, never in a repo, never in a Slack message. When an integration is retired or a team member leaves, revoke its password. Stale credentials are how breaches happen quietly.
For more complex setups — a decoupled frontend with real user sessions, multiple client applications — JWT tokens are the industry standard. Token-based auth gives you expiration and validation endpoints, at the cost of more setup. And on the human side, this is 2026: every administrator account should have two-factor authentication enabled, enforced by policy rather than by hope. A strong application-password scheme means nothing if the admin account behind it logs in with "CompanyName2024!" and no second factor.
Rate Limiting: Slow the Bots Down
Here's a number worth internalizing: an unprotected wp-login.php or REST endpoint will happily accept thousands of requests per minute from a single IP. There is no legitimate reason for that. Rate limiting is not about stopping a determined attacker with a botnet — it's about making your site an expensive, annoying target so the bots move on to the next one.
The practical threshold most hardening guides settle on is around 60 requests per minute per IP for API endpoints, tighter for login-adjacent routes. Implement it at the right layer: a web application firewall or reverse proxy (Cloudflare's free tier handles this fine) is better than doing it in PHP, because the request dies before it costs you database queries. If you must do it in WordPress, use transients or an object cache like Redis rather than hammering the options table.
Apply the same thinking to login attempts. Limit Login Attempts Reloaded or equivalent, with lockouts that escalate — a few minutes for the first offenses, longer for repeat offenders. Pair it with notifications so you actually see when someone's probing you. The goal isn't a perfect fortress; it's making your site cost more to attack than the average WordPress install, because attackers are rational about effort.
Lock Down wp-config and the Server Layer
Some of the most effective hardening has nothing to do with the REST API directly. In wp-config.php, define DISALLOW_FILE_EDIT to remove the theme and plugin editors from the admin — if an attacker ever gets an admin session, you don't want them editing PHP from the dashboard. Force admin sessions over TLS with FORCE_SSL_ADMIN. Set WP_DEBUG to false in production so PHP notices don't leak paths and query details into page source. Enable automatic minor core updates so security patches apply themselves.
File permissions deserve a once-a-year audit: directories at 755, files at 644, wp-config.php at 640 or 600, and nothing world-writable. Regenerate your salts if they've been sitting unchanged since the site was built — the secret-key API at api.wordpress.org gives you a fresh set in one click, and rotating them invalidates every existing session and cookie, which is exactly what you want after any suspected incident.
Above WordPress, the server layer does heavy lifting. Enforce HTTPS everywhere with HSTS. Add security headers — X-Frame-Options, X-Content-Type-Options, Referrer-Policy — which cost nothing and blunt whole classes of attacks. Keep PHP on a supported version; running end-of-life PHP in 2026 is one of those things that's fine until the day it very suddenly isn't.
Monitor Like Someone's Watching — Because They Are
Hardening without monitoring is a lock you never check. At minimum, you want visibility into three things: failed login attempts (volume and source IPs), unexpected REST routes appearing (a plugin update can register new endpoints with weak permission callbacks — audit after every update), and file integrity (core checksum verification catches modified core files, the classic sign of a compromise).
Build a monthly routine, especially if you manage client sites. Fifteen minutes per site once you've templated it: review the security plugin's logs, check for dormant administrator accounts (there should be one or two, max — demote or remove the rest), revoke stale application passwords, confirm backups actually ran and are restorable. The number of "we had backups" stories that end with "but the restore failed" is depressing. Test the restore.
And have an incident plan before you need one. Know the order of operations: take the site offline or into maintenance mode, identify the entry point from access logs, restore from a known-clean backup, rotate every credential (database, salts, admin passwords, API tokens), then patch the hole that let them in. Writing this down when you're calm is worth more than any plugin when you're not.
Conclusion
WordPress REST API hardening isn't a single plugin or a magic snippet — it's a posture. Close the user enumeration leaks, authenticate integrations with least-privilege credentials, rate-limit everything facing the internet, lock down configuration and file permissions, and monitor the result. None of these steps is exotic. Together, they're the difference between a site that survives the nightly bot scans and one that ends up in a credential-stuffing database.
The uncomfortable truth is that most WordPress compromises aren't sophisticated. They're automated, opportunistic, and aimed at the sites that left the defaults on. Don't be the defaults.
Frequently Asked Questions
Should I disable the WordPress REST API completely?
Only if nothing needs it. For traditional brochure sites with no integrations, disabling unauthenticated access is safe and takes minutes. For headless or app-driven sites, restrict surgically instead — require authentication on sensitive endpoints and leave the public ones your frontend needs.
Are Application Passwords safe to use?
Yes, when used correctly: one per integration, stored as a secret, revoked when no longer needed. They've been in WordPress core since 5.6 and are far safer than sharing admin credentials or hardcoding passwords into integrations.
What's the first thing to check after a suspected hack?
Verify core file checksums, look for unknown administrator accounts and unfamiliar application passwords, inspect recently registered REST routes and scheduled cron events for anything you didn't install — then rotate every credential before bringing the site back online.
Does a security plugin replace manual hardening?
No. Plugins like Wordfence or Solid Security are excellent for monitoring, firewalling, and alerting, but the structural fixes — enumeration restrictions, credential hygiene, file permissions — are configuration decisions a plugin can only partially make for you.
How often should I audit a production WordPress site?
Monthly for active sites: check logs, dormant accounts, stale application passwords, and backup integrity. Plus an immediate audit after every plugin or theme update, since updates can introduce new REST endpoints or reset settings.
