HTTP 403 Forbidden means the server understood the request but refuses it under authorization or policy. Check the authenticated identity, ACL/RBAC, web-server rules, WAF/CDN policy and path permissions without weakening access controls globally.
Step-by-step checks
Verify whether the request is authenticated and which user/service identity the application sees; compare with a known-authorized identity.
Check application RBAC/ACL rules and web-server location/directory rules for the exact method and path, including inherited deny rules.
Determine whether a CDN, WAF, reverse proxy, geo/IP policy or client-certificate requirement is generating the 403 before the application.
Correlate the request ID/timestamp across edge, proxy and application logs so the denying layer is identified before changing permissions.
Useful verification commands
Use commands only on systems you administer and capture the read-only output before making a configuration change.
curl -I https://example.com/restricted
curl -vk https://example.com/restricted
How to validate the result
The intended authorized identity must access the resource while unauthorized identities remain blocked by the expected control.
Evidence to keep
Keep request URL/method, authenticated identity, response headers/request ID, RBAC/ACL result and the exact edge/proxy/application log line that issued the denial.
Frequently asked question
Will making the directory writable fix a 403?
Not necessarily. A 403 can come from application authorization, WAF/CDN policy, web-server access rules or filesystem permissions. Identify the denying layer first.