WordPress REST API Rate Limits for Application Passwords
WordPress application passwords give external systems REST API access without sharing the main user password. That does not make them harmless. Unknown owners, broad roles, noisy scripts, and missing rate limits can turn a helpful integration into a quiet security risk.
Use this for WordPress sites with CRMs, publishing tools, automation scripts, mobile apps, headless frontends, or vendors that authenticate to the REST API.
Quick answer
WordPress REST API Rate Limits for Application Passwords should be handled with a narrow evidence-first workflow: map owners, review api logs, add rate limits, then verify the result before making broader changes.
What to check first
- List users that own application passwords and match each credential to a named integration.
- Review recent REST API traffic for failed authentication, high request volume, and unusual IPs.
- Rate limit authenticated REST API requests without blocking normal publishing or CRM syncs.
- Revoke credentials for old vendors, staff, test scripts, and retired integrations.
- Rotate credentials after malware cleanup, staff changes, or vendor handoffs.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|---|---|
| Map owners | List users that own application passwords and match each credential to a named integration. | Every active application password has a named owner and business purpose. |
| Review API logs | Review recent REST API traffic for failed authentication, high request volume, and unusual IPs. | Normal integrations work after rate limits are applied. |
| Add rate limits | Rate limit authenticated REST API requests without blocking normal publishing or CRM syncs. | Stale vendor credentials are revoked and documented. |
| Revoke stale keys | Revoke credentials for old vendors, staff, test scripts, and retired integrations. | Security logs show no repeated failed REST API authentication bursts. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp user list --fields=ID,user_login,user_email,roles
wp user application-password list 12
wp user application-password delete 12 app-password-uuid
# Check access logs for /wp-json/ requests by IP, method, status, and user agent.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Map owners
- Review API logs
- Add rate limits
- Revoke stale keys
- Rotate after changes
Production verification checklist
- Every active application password has a named owner and business purpose.
- Normal integrations work after rate limits are applied.
- Stale vendor credentials are revoked and documented.
- Security logs show no repeated failed REST API authentication bursts.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit WordPress REST API credentials.