401 vs 403: authentication and access errors

What the response actually says

401 Unauthorized means the request lacks valid authentication credentials for that resource. The response must include a WWW-Authenticate challenge. 403 Forbidden means the server understood the request but refuses it; the reason can be permissions or another policy. A 403 alone does not prove that login succeeded. These distinctions come from HTTP semantics.

Worked example: a report that one account cannot open

Imagine an employee can open the dashboard but cannot export a report. Start with the failing export request, not the successful dashboard page. If it returns 401, check whether the export goes to a different hostname and whether that request carries the intended session cookie or authorization header. Logging into one origin does not by itself explain what was sent to another.

If the export returns 403, compare the account’s report access with a known authorized test account. The user might have dashboard access but lack permission to export that specific report. Record the resource identifier and request ID, then correlate them with the application’s access log. Do not solve the problem by removing authorization checks.

One useful support summary is: “Account A can read report 27 but export returns 403; account B can export; both requests reach the same endpoint.” It narrows the investigation much more than a screenshot of the error page.

A repeatable troubleshooting sequence

1. Capture the exact request. Record the URL, method, response status, timestamp, and request ID if supplied. Reproduce only the operation needed.
2. Inspect the response. Read the challenge on a 401 and the service’s error body. A proxy or security service may have generated the response before your application ran.
3. Check credential delivery. Confirm presence and intended destination without copying secrets into notes. A missing cookie and an expired token require different fixes.
4. Check the account and resource. Verify scope, role, organization, and ownership using the service’s own access model.
5. Compare a controlled case. Use one authorized test account or known working request. Change one relevant variable at a time.
6. Confirm the fix. Repeat the original operation and verify that unauthorized accounts remain denied.

Avoid misleading shortcuts

Refreshing endlessly rarely explains an access failure. Likewise, a successful request in a command-line client does not prove the browser will send the same cookies, headers, or origin information. Compare the actual requests before changing server settings.

A browser CORS message is not synonymous with 401 or 403. Inspect the preflight and the actual request separately. The browser may withhold a response from page JavaScript even when the Network panel has useful details. A login redirect can also end at a successful HTML page when an API client expected JSON.

Use the tools without exposing a session

Use the HTTP reference to interpret a captured status and HAR Viewer to inspect the sequence. HAR files can contain credentials, identifiers, query strings, and request bodies. Use a sanitized export and inspect it before sharing; sanitation is not a guarantee that every private value was removed. Keep a minimal capture focused on the failing request.

The reference cannot determine which account should have access, and a saved HAR cannot prove the current state of a session. Final verification belongs in the application’s access controls and server logs.

Sources and review

• RFC 9110: client error status codes
• MDN: 401
• MDN: 403

Examples are illustrative. Reviewed September 28, 2026 against the sources above and the related tool interfaces. Editorial methodology · Report a correction.