WordPress REST API 403 on /wp-json/: WAF Fix Checklist
The WordPress REST API powers the block editor and many plugin workflows. A 403 response from `/wp-json/` may come from WordPress permissions, a security plugin, hosting rules, Cloudflare, ModSecurity, or another WAF layer.
Use this when Site Health reports a REST API error, the block editor fails to save, plugin screens fail to load, or a headless frontend cannot fetch WordPress JSON.
Quick answer
WordPress REST API 403 on /wp-json/ should be handled with a narrow evidence-first workflow: fetch rest routes, identify 403 source, review waf logs, then verify the result before making broader changes.
What to check first
- Fetch `/wp-json/` and a specific REST route with response headers visible.
- Check whether the 403 body is a WordPress JSON error, WAF page, host page, or CDN challenge.
- Review WAF, CDN, and security plugin logs for the exact path and timestamp.
- Allow required REST routes while keeping sensitive routes protected.
- Retest the block editor, Site Health, form plugins, and any headless frontend.
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 |
|---|---|---|
| Fetch REST routes | Fetch `/wp-json/` and a specific REST route with response headers visible. | `/wp-json/` returns a valid REST API response for public routes. |
| Identify 403 source | Check whether the 403 body is a WordPress JSON error, WAF page, host page, or CDN challenge. | Protected routes still require the right authentication and permissions. |
| Review WAF logs | Review WAF, CDN, and security plugin logs for the exact path and timestamp. | The block editor and Site Health REST checks pass after WAF tuning. |
| Tune allow rules | Allow required REST routes while keeping sensitive routes protected. | WAF logs explain any remaining blocked REST API request. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -I --max-time 15 https://example.com/wp-json/
curl -sS --max-time 15 https://example.com/wp-json/wp/v2/types/post?context=edit
# Compare headers, status, body shape, and WAF logs for the same timestamp.
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.
- Fetch REST routes
- Identify 403 source
- Review WAF logs
- Tune allow rules
- Retest workflows
Production verification checklist
- `/wp-json/` returns a valid REST API response for public routes.
- Protected routes still require the right authentication and permissions.
- The block editor and Site Health REST checks pass after WAF tuning.
- WAF logs explain any remaining blocked REST API request.
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, fix WordPress REST API 403 errors.