A 403 response can block a page, editor save or upload at WordPress, the web server or a firewall. First identify the exact action and whether access is intended for that account.
Use matching logs and a working comparison to separate a valid restriction from a filesystem or security-rule fault.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Pattern | Investigation | Next evidence |
|---|---|---|
| One save blocks particular content | Security false positive | Matched rule and redacted reproduction. |
| One account cannot use a feature | Expected capabilities and session | Authorized working comparison. |
| Static files fail too | Server access and ownership | Failing file compared with a working one. |
| One network is affected | Client or IP policy | Matching event and second connection. |
Describe the blocked action precisely
Note the URL, time, and action that produced the response. For a form or editor failure, record whether ordinary pages still load and whether a small test submission works. A firewall can reject particular content while allowing the same endpoint with other content.
Try the page from a second connection if the failure seems limited to your device. A network-specific block suggests an IP or client rule; a failure affecting every visitor suggests a broader access configuration. Neither result proves the cause on its own, but both help locate the relevant logs.
A request identifier or security event number is especially useful when a CDN or hosting firewall supplies it. Preserve that number for support. Repeatedly submitting the same blocked request can trigger additional rate limits and make the original event harder to find.
Check the intended access first
Some 403 responses are correct. A private resource may require an account with a particular role, and a public visitor may not be entitled to use an administrative endpoint. Confirm the intended permissions before treating the refusal as a fault.
If a logged-in editor can open a post but cannot save it, refresh the session and compare the account’s capabilities with the action involved. A valid login does not grant every WordPress permission. REST requests can also fail because their authentication state has expired.
If the login page itself is blocked, follow the WordPress login guide. An application permission problem needs a different repair from a server that never lets the request reach WordPress.
Use the firewall event to narrow the repair
Focused report: give the path, request time, action and rule identifier. Compare a harmless plain submission with the blocked content when appropriate. A reviewed exception should match the confirmed false positive rather than bypass unrelated protection.
Hosting firewalls, security plugins, and CDN rules may inspect requests before the application handles them. Look for an event at the same time as the failure. The matched rule and request path are more helpful than a generic “access denied” screen.
For example, a rule may reject a code example pasted into a tutorial while permitting a plain sentence in the same post. Keep the example and give the security provider a redacted reproduction. A narrowly reviewed exception may resolve a false positive without opening unrelated endpoints.
Turning off every protection hides useful evidence and can leave the site exposed. Test the specific rule or component on staging where possible, and restore any temporary change once the comparison is complete.
When files or server rules are involved
- Back up the applicable custom rules.
- Identify the server handling the request.
- Compare ownership and access on failing and working files.
- Ask the host for the correct configuration for that environment.
If static files and ordinary pages also fail, your host should inspect file ownership, directory access, and the applicable web-server rules. Common permission values such as 755 for directories and 644 for files are not a complete recipe for every host. The process serving the site must also have the correct access.
Do not apply permission 777 throughout the installation. It can add unnecessary write access while leaving the actual ownership issue unresolved. Give the host an example of a file that fails and ask it to compare that file with one that loads correctly.
On Apache, a custom .htaccess rule can deny access. Keep a backup and review the relevant rule rather than replacing the entire file with a generic example. It may also contain redirects or security settings you still need. On Nginx, the equivalent investigation belongs in the server configuration; saving WordPress permalinks does not rewrite that configuration.
Verify the original request after the change
Repeat the blocked action once with the intended account, then check its actual result. A form needs a recorded submission, and an editor save needs the text to remain after reopening the post. Also check that private resources remain restricted to the right users.
If unexplained rules or files keep changing, investigate the possibility of a compromised site. For the normal permission model, WordPress provides file-permission guidance. Its REST authentication documentation explains the separate requirements for browser-based API requests.
Confirm intended access and restrictions
Repeat the original action with the intended account and check the stored result. Confirm private resources remain protected. Record the exact rule, capability or server access issue repaired instead of treating every 403 as a reason to open file permissions.