Introduction

A WordPress REST API 403 error usually means the request reached the site but was refused somewhere along the way. That matters because the refusal may come from WordPress permissions, a security plugin, a web application firewall, basic authentication, or even a proxy rule in front of the site. The right fix is to determine which layer is denying the request before changing editor settings or plugin code blindly.

Symptoms

  • The block editor, plugin integrations, or external tools fail with REST API 403 errors
  • Public pages load, but save actions or API endpoints are denied
  • The issue started after enabling security rules, a CDN, or login protection
  • Some REST routes work while others fail
  • Browser or application logs show forbidden responses from /wp-json/ endpoints

Common Causes

  • A security plugin or WAF blocks REST API paths or specific request patterns
  • Authentication cookies, nonces, or headers are not reaching WordPress correctly
  • Basic auth or server-level restrictions protect paths the editor needs to access
  • Permalink or rewrite issues cause REST requests to resolve incorrectly
  • A CDN or reverse proxy changes request headers, origin host, or authentication flow

Step-by-Step Fix

  1. Identify the exact REST endpoint returning 403 and note whether the request is public, authenticated, or coming from an external integration.
  2. Check browser developer tools or application logs to confirm whether the 403 response comes from WordPress, a security plugin, the server, or a proxy layer.
  3. Review security plugin logs, firewall events, and CDN protections for blocked /wp-json/ requests or suspicious signatures tied to the failing endpoint.
  4. Verify authentication context, including cookies, nonces, and headers, especially if the request passes through a proxy or alternate domain.
  5. Test the same endpoint directly at the origin if possible so you can see whether the block exists before or after the proxy layer.
  6. Refresh permalink rules and confirm REST routes resolve correctly on the canonical hostname and protocol.
  7. Add narrow exceptions for required REST endpoints only after you identify the exact control denying legitimate traffic.
  8. Retest the editor, plugin workflow, or integration that originally failed so you confirm the real business path is restored.
  9. Keep REST API protections documented so future hardening does not block the authenticated requests WordPress relies on internally.