The WordPress REST API is on by default and exposes real attack surface if left unconfigured — the most common real-world abuse in 2026 is user enumeration through the /wp/v2/users endpoint, which hands an attacker your usernames for a subsequent brute-force attempt. The fix isn’t disabling the REST API entirely, which breaks the block editor and most modern plugins — it’s selective hardening of the specific endpoints that leak information you don’t want public.
Why Full Disabling Is the Wrong Move
A full disable of the REST API breaks more than it fixes on most production sites — the block editor, many plugin admin screens, and increasingly the frontend itself depend on it. The better approach is blocking unauthenticated access to specific sensitive endpoints while leaving the routes your actual plugins need untouched.
What Actually Needs Hardening
| Endpoint / Feature | Risk | Fix |
|---|---|---|
/wp/v2/users |
User enumeration for brute-force targeting | Block unauthenticated access; keep it available to logged-in requests your plugins need |
Author archives (?author=1) |
Same enumeration risk via a different route | Disable if you don’t need public author pages |
| Application Passwords | A leaked or over-scoped credential grants broad access | One password per integration, lowest role that works, rotate and revoke when unused |
| Login / auth endpoints | Brute-force attempts | Rate limiting and a login-attempt limiter plugin |
| All REST traffic | Credentials and tokens in transit | TLS 1.2/1.3 only, HTTPS enforced, HSTS enabled |
Application Passwords Done Right
Application Passwords are the standard way to authenticate REST API requests without exposing your actual login password, but they’re only as safe as how they’re issued. Create a dedicated, low-privilege account for each integration rather than generating one under an administrator account — a compromised Application Password should never be able to do more than the specific task it was created for. Revoke it the moment an integration is retired, and don’t reuse the same password across multiple tools.
Testing Before You Lock Anything Down
- Inventory what actually calls your REST API — plugins, mobile apps, any automation you’ve built.
- Block the user-enumeration endpoint first — it’s the highest-value, lowest-risk fix.
- Test every integration after each change on staging, not production, since selective hardening can still break something you didn’t account for.
- Confirm HTTPS and HSTS are actually enforced, not just available.
If you’re running any custom REST API integration and want its authentication and endpoint exposure reviewed, get in touch.
Frequently Asked Questions
Should I just disable the REST API entirely for security?
Not on a typical site — that breaks the block editor and most modern plugin functionality. Selective endpoint hardening addresses the real risk without the collateral damage.
What’s the single highest-value REST API fix?
Blocking unauthenticated access to /wp/v2/users. It’s the most commonly abused endpoint in real-world attacks and rarely needs to be public.
How often should Application Passwords be rotated?
A commonly cited baseline is every 90 days for active integrations, plus immediate revocation the moment an integration is no longer in use.
Featured image: original illustration.