403 - Forbidden
HTTP 403 Forbidden means the server understood the request but refuses to authorize this action.
Last reviewed: March 5, 2026|Editorial standard: source-backed technical guidance
What Does Forbidden Mean?
The request was understood and authenticated context might be present, but policy evaluation denies this action at the current resource scope.
Common Causes
- -IAM or RBAC policy denies write action because request lacks required condition such as encryption or project scope.
- -Ingress allowlist blocks source CIDR after NAT egress IP change, so authenticated users are denied at policy layer.
- -Service authorization matrix grants read scope only, and POST or DELETE operations fail explicit permission checks.
How to Fix Forbidden
- 1Inspect effective access policy decisions for the exact blocked resource and action.
- 2Apply least-privilege policy updates or legal-scope corrections at the correct boundary.
- 3Retest with the same identity and confirm access behavior matches intended policy.
Step-by-Step Diagnosis for Forbidden
- 1Capture denied action context and policy details associated with Forbidden (403).
- 2Evaluate effective permissions and policy precedence at the exact resource scope.
- 3Verify legal, regional, or tenant-level restrictions that can explicitly block access.
- 4Retest with the same identity after policy adjustments to confirm behavior change.
Authorization Decision Path
- -Inspect effective allow/deny evaluation for the exact action and resource (example: role includes read permission but explicit deny at project scope blocks it).
- -Verify scope alignment for identity and resource tenancy (example: token belongs to tenant A while resource is constrained to tenant B).
Policy and Restriction Context
- -Audit WAF, ACL, geo/legal, and business-rule controls that return 403 independently of IAM (example: country block or organization policy denial).
- -Confirm that re-authentication is not incorrectly treated as a fix when the blocking condition is authorization policy, not identity validity.
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 403 Forbidden
# {"error":"Forbidden","code":"403"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 403) {
console.error('Handle 403 Forbidden');
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 403:
print('Handle 403 Forbidden')How to Verify the Fix
- -Retry the blocked request and confirm 403 no longer appears for the intended access path.
- -Validate audit trails show expected authorization decisions for the affected operation.
- -Confirm least-privilege policy updates did not broaden access beyond intended scope.
How to Prevent Recurrence
- -Enforce policy review workflows with deny-precedence checks before rollout.
- -Continuously audit access controls and legal restriction mappings per environment.
- -Run authorization tests in CI for critical routes and policy combinations.
Pro Tip
- -record the resolved policy decision (allow path and deny path) with request IDs so every 403 can be traced 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.