sfw/fix
rest_forbidden high

REST API: Sorry, You Are Not Allowed to Do That (rest_forbidden / 401)

Something is blocking authenticated /wp-json/ requests, so the editor, Site Health, and integrations get rejected as unauthorized.

What you see

{"code":"rest_forbidden","message":"Sorry, you are not allowed to do that.","data":{"status":401}}
(also surfaces as a 403, or in the editor as "Sorry, you are not allowed to edit this post.")

What’s actually happening

A /wp-json/ call that should be authenticated comes back rejected. In practice the block editor won't load or save, Site Health reports a REST API error, and plugins like Jetpack or an SEO suite fail to sync. WordPress sees the request as coming from a logged-out user, so it refuses the action. The credentials are usually valid — they're being stripped or blocked before WordPress can read them.

Common causes

  • An Apache/Nginx config that drops the HTTP Authorization header, so Application Passwords and Basic auth never reach PHP
  • A security plugin (Wordfence, iThemes, All In One WP Security) blocking or rate-limiting /wp-json/
  • An .htaccess or server rule denying access to wp-json or to non-GET methods
  • Cookie/nonce trouble in the editor — a stale or missing X-WP-Nonce from aggressive caching or a session timeout
  • User permissions: the account genuinely lacks the capability for that endpoint (e.g. an Author trying to edit others' posts)

How to fix it

  1. Confirm it's auth, not permissionsLoad /wp-json/ logged out — public routes returning JSON means the API itself is up. Then check whether the account has the right role for what it's doing. A real capability gap (status 403, 'not allowed to edit this post') is fixed by granting the role, not by touching the server.
  2. Restore the Authorization headerIf Application Passwords or Basic auth fail, the server is likely eating the header. On Apache add: SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 (or 'CGIPassAuth On' on newer Apache). On Nginx + PHP-FPM, pass fastcgi_param HTTP_AUTHORIZATION $http_authorization;. Reload and retry.
  3. Toggle the security plugin to confirm the blockDeactivate the security plugin or its WAF/firewall module and retry the REST call. If it works, that plugin was the blocker — turn it back on and whitelist /wp-json/ for logged-in users instead of leaving it wide open.
  4. Refresh nonces in the editorFor editor-only rest_forbidden after a page sits open a while, the X-WP-Nonce has expired. Hard-refresh to pull a fresh nonce, and exclude wp-admin and logged-in sessions from full-page caching so the editor never gets a stale one.
  5. Audit .htaccess and server rulesLook for a deny rule or method restriction touching wp-json or index.php. A 'Deny from all' or a block on POST/PUT/DELETE will trigger rest_forbidden. Remove or scope it so authenticated REST requests pass.

Stop it recurring

Pass the Authorization header through at the server, whitelist /wp-json/ in any security layer, and keep wp-admin out of full-page caches.

Related errors