The short version
- 01Read the error body for a permission name, rule identifier or provider-specific explanation.
- 02Verify that the intended account has access to the exact resource and action.
- 03Ask the resource owner for the required permission when access is legitimately missing.
- 04Check server and security logs when maintaining a site that refuses expected traffic.
- 05Correct the specific access rule responsible for an unintended block.
- 06Retest the affected request after the permission or rule changes instead of repeatedly refreshing.
Raw message
403 Forbidden
Likely causes
- The account lacks permission for the resource or requested action.
- An API token lacks the required scope.
- A web-server access rule denies the URL or client address.
- A firewall or CDN security rule blocks the request before the application handles it.
What 403 tells you
The server understood the request but will not fulfil it. If credentials were supplied, they were insufficient for access; a refusal can also be unrelated to credentials. Unlike a 401 challenge, repeating the request with the same identity is not expected to fix a permission refusal.
Read any application error alongside the HTTP status. A user allowed to view a record may still be forbidden from deleting it. That difference explains why one button fails even though the rest of the application works.
If you are visiting a website
Confirm the resource owner intended to share this page or action with your account. If access is missing, request the appropriate permission. If access should already work, send support the URL, approximate time and error identifier so they can find the refusal.
A 403 alone does not identify a broken browser. Our recommendation is to establish which page or action is blocked before clearing site data or changing passwords. Those changes cannot grant an account a role it does not possess.
If you maintain the site or API
Determine whether the application, origin web server or an upstream security layer generated the response. Cloudflare documents both origin permission rules and its own WAF or security features as possible causes. Check the corresponding access or security logs before editing application roles.
Branding is a clue, not conclusive proof: Cloudflare also documents some early, unstyled 403 responses, including a host/SNI mismatch. Correct the specific misconfigured rule or hostname path once identified. Avoid disabling all protection or making every file publicly writable to solve one refused request.
For an OAuth API reporting insufficient_scope, request only the necessary authorized scope and retest the operation. Keep authentication failures and permission failures distinct in your own error responses.
Sources and review notes
Checked on . Based on HTTP and OAuth standards, MDN and Cloudflare documentation. Cloudflare examples apply only to sites using that service; the status alone does not identify the component responsible.