403 - Forbidden
HTTP 403 Forbidden means the server understood the request and often knows who the caller is, but policy or business rules still block this action on the target resource.
Last reviewed: April 12, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Forbidden Mean?
Treat 403 as an authorization or restriction decision. Authentication may already be valid; the failure is that this principal, source, tenant, or geography is not allowed to do this here.
Common Causes
- -The caller is authenticated but lacks the exact action scope or role needed for this resource.
- -An explicit deny, ACL rule, WAF policy, tenant restriction, or geo/legal block overrides the apparent allow.
- -Signed URL or session is valid, but object ownership, moderation state, or business-rule policy still forbids the action.
- -Cross-tenant or cross-project access is blocked by resource ownership checks even though the caller can read adjacent resources.
- -A CSRF, anti-bot, or origin restriction is enforced as 403 at the edge before the application logic runs.
How to Fix Forbidden
- 1Capture the identity, action, resource, and request ID for the blocked call and confirm whether authentication already succeeded.
- 2Inspect audit logs, policy simulation, or edge enforcement logs to find the decisive deny or restriction rule.
- 3Fix the smallest scope or rule mismatch at the correct boundary instead of broadening access globally.
- 4Retest the same route with the same identity and confirm the policy decision changed as intended.
Step-by-Step Diagnosis for Forbidden
- 1Record the principal, denied action, target resource, route, and request ID from the failing 403 response or audit trail.
- 2Determine whether the request would still fail after re-authentication; if yes, continue with authorization diagnostics instead of 401 diagnostics.
- 3Inspect effective permission evaluation at the exact resource scope, including explicit denies and inherited restrictions.
- 4Check edge controls such as WAF, CIDR allowlists, bot rules, geo policies, and CSRF enforcement for alternate 403 sources.
- 5Verify tenant, project, account, or ownership scope matches the resource the caller is trying to access.
- 6Replay the request after a minimal policy or configuration change and verify adjacent higher-risk actions remain blocked.
Seen in Production
- -User can
GET /projects/123, butPOST /projects/123/archivereturns 403 because the role grants read access and not archive or delete actions. - -An object download signed URL is valid, yet the bucket or CDN policy blocks the request from a non-approved source IP or country and responds with 403.
- -Admin dashboard works from office IPs and fails from home broadband because an outdated CIDR allowlist still fronts the route.
Auth-vs-Authz Decision Check
- -If a fresh login with the same identity still fails on the same action, treat the incident as 403 policy debugging rather than 401 credential debugging.
- -If the server returns
WWW-Authenticateand the same route succeeds after presenting valid credentials, you are likely in 401 territory instead of 403 territory.
Policy Decision Trace
- -Inspect the decisive allow or deny rule for the exact action-resource pair (example: principal can read invoices, but explicit deny blocks
invoice.closeoutside finance group). - -Verify non-IAM controls too, such as WAF, ACL, geo, bot, referer, and origin rules that can emit 403 before app authorization logic runs.
Wrong Fix to Avoid
- -Do not force a re-login and assume the issue is solved; 403 often persists because the identity is valid but the action is still blocked.
- -Do not grant administrator-level access just to clear one route; first identify the exact denied action and the rule that produced it.
Implementation Examples
POST /v1/projects/123/archive HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...
HTTP/1.1 403 Forbidden
Content-Type: application/json
X-Request-Id: req_9fd12a
{
"error": "Forbidden",
"code": "insufficient_scope",
"message": "Missing project.archive permission for project 123",
"requestId": "req_9fd12a"
}curl -i https://api.example.com/v1/projects/123/archive \
-X POST \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"Seen in Production
Service identity can read but not mutate after a role change
Frequency: common
Example: Background job stays authenticated but starts receiving 403 on write operations after a least-privilege role rollout.
Fix: Restore the missing action at the correct scope and verify no explicit deny still overrides the grant.
Geo or source-network rule blocks a subset of valid users
Frequency: medium
Example: Requests from one region or NAT range return 403 while the same identity succeeds from another network.
Fix: Audit the network and geo restriction layer and align it with the documented access policy.
Tenant isolation hides cross-tenant objects behind 403
Frequency: common
Example: Support operator can read tenant A objects but gets 403 for tenant B archive actions because ownership checks fire after authentication.
Fix: Use the correct tenant context and document the required cross-tenant escalation workflow instead of broadening roles.
Debugging Tools
- -Audit logs or authorization decision traces
- -WAF, CDN, ACL, and geo-block logs
- -curl -v with explicit auth headers and request IDs
- -Policy simulation tools
- -Tenant or ownership context inspection tools
How to Verify the Fix
- -Replay the same blocked request with the same identity and confirm the route no longer returns 403 for the intended action.
- -Validate audit logs, WAF logs, or policy traces now show an allow decision or no block for that request ID pattern.
- -Confirm least-privilege still holds by testing adjacent actions that should remain forbidden.
- -Verify the fix is scoped correctly for the intended tenant, project, region, or network boundary.
How to Prevent Recurrence
- -Codify policy and ownership rules so routes, actions, and scopes are reviewed together before rollout.
- -Continuously audit WAF, ACL, geo, and tenant restrictions alongside application authorization rules.
- -Add CI and post-deploy tests for critical read/write/admin routes with expected allow and deny identities.
Pro Tip
- -log the resolved policy decision with action, resource, identity, and request ID so every 403 can be traced back to one deterministic rule outcome.
Decision Support
Compare Guide
401 Unauthorized vs 403 Forbidden: Auth vs Access Denied
Fix 401 Unauthorized vs 403 Forbidden by separating authentication failures from authorization denials, then apply the right login or permission fix fast.
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Playbook
Authorization Denial Playbook (403 / AccessDenied / PERMISSION_DENIED)
Use this playbook to triage policy-based access denials after authentication succeeds, isolate the deny layer, and apply least-privilege remediation safely.
Playbook
Auth Incident Playbook (401 / UNAUTHENTICATED)
Use this playbook to separate missing, expired, or invalid identity proof from authorization and transport failures, and apply credential-source-correct fixes safely.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.