HTTP 403 Forbidden Error: Causes and How to Fix It

The 403 Forbidden error informs that the server understood the request but refused to execute it. Unlike 401, repeating the login does not necessarily resolve the issue: the identity may be valid but without permission for that resource or action.

Direct Response: How to Resolve the 403 Error

Discover which layer produced the response. Check the body and headers, compare with an authorized request, validate the user's role and scope, application rules, file permissions, server configuration, WAF, and CDN. Change only the responsible rule and test again with an allowed account and another that is prohibited.

Step 1: Capture the Complete Response

curl -i https://api.exemplo.com/relatorios \
  -H "Authorization: Bearer YOUR_TOKEN"

Do not share tokens in calls or captures. Note the status, message, request-id, server, and proxy headers. A page generated by the CDN looks different from a JSON created by the application.

Step 2: Differentiate Authentication and Authorization

An expired or missing token should normally cause a 401 and include WWW-Authenticate. A valid token without the required role causes a 403. Inspect issuer, audience, expiration, and scopes without logging the full secret. In the application, authorize on the server; hiding a button on the front-end does not protect the operation.

Example decision:

authenticated? no -> 401
authenticated? yes, has reports:read? no -> 403
has permission? yes -> execute and respond 200

Step 3: Check Nginx and File System

The server process needs to traverse directories and read published files. On Linux, check without applying broad permissions:

namei -l /var/www/site/public/index.html
sudo nginx -T
sudo tail -n 100 /var/log/nginx/error.log

Avoid chmod 777. Correct owner, group, and minimum permissions. Also check deny rules, basic authentication, absence of index file, and more specific location blocks.

Step 4: Evaluate WAF, CDN, and Rate Limit

Look for the event by the response identifier. Managed rules may block payload, method, IP, header, or pattern interpreted as an attack. Create a narrow exception for the route and proven condition; do not turn off the entire firewall.

Step 5: Review CORS Only When Necessary

CORS is a browser policy and often appears in the console without the main response being 403. Test the API outside the browser. If the preflight OPTIONS receives 403, allow the method and necessary headers for known origins. The tutorial on CORS error delves deeper into this investigation.

Secure API Response

Provide enough information for the client to correct the issue without revealing sensitive internal rules:

{
  "error": "forbidden",
  "message": "Your account does not have permission for this action",
  "requestId": "req_abc"
}

Log user, tenant, action, denied rule, and request ID on the server. Do not place unnecessary token or personal data in the log.

Correction Checklist

• reproduce with a minimal request;
• identify the layer that generated 403;
• validate role, scope, tenant, and resource ownership;
• check logs at the same time and request ID;
• test allowed and prohibited accounts;
• maintain denial by default and least privilege;
• document the change and monitor recurrence.

Frequently Asked Questions

Does clearing the cache resolve 403?

Only if an incorrect credential or response is stored. Generally, the server will continue to deny while the rule remains.

What is the difference between 401 and 403?

401 requests valid authentication; 403 indicates that the known request does not have the right to the action.

Primary Sources

• MDN: status 403 Forbidden
• RFC 9110: status 403
• Nginx: access control module