403 vs 405: Forbidden vs Method Not Allowed
403 and 405 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 403 — Forbidden | HTTP 405 — Method Not Allowed |
|---|---|---|
| Definition | Authentication is not the issue — the authenticated user simply does not have permission to access the resource. Re-authenticating will not help. | The server knows the resource but the HTTP method used (e.g., DELETE on a read-only endpoint) is not allowed. The Allow header lists the permitted methods. |
| Plain-language summary | The client is authenticated but does not have permission to access the resource. The server understood the request and knows who the client is — it simply refuses to authorize this specific action. Re-authenticating will not change the outcome. | The HTTP method used in the request (GET, POST, DELETE, etc.) is not allowed on the target resource. The server knows the resource exists but does not support the requested action on it. The response includes an Allow header listing the permitted methods. |
| When to use | Return 403 when the client is authenticated but lacks the required permissions, role, or scope. Use 401 when the issue is authentication (unauthenticated or invalid credentials). Use 404 when you do not want to reveal whether a resource exists at all (security-sensitive resources). | Return 405 when the resource exists but the method is not supported. Must include an Allow header listing supported methods. Use 404 when the resource does not exist. Use 501 when the method is not implemented globally (rather than for a specific resource). |
| Client behavior | Client should not retry without a change in permissions. Users should contact an administrator. Automated clients should surface the error and stop retrying. | Do not retry with the same method. Read the Allow header to determine which methods are supported and retry with a valid method. |
| Caching behavior | Not cached. Permission checks are per-request. | Not cached. |
| SEO / crawler impact | Search crawlers interpret 403 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 405 (client-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 403 expect Forbidden semantics. | API clients branching on 405 expect Method Not Allowed semantics. |
| Safe to retry? | Only after fixing the underlying cause | Only after fixing the underlying cause |
Common real-world scenarios
When you see HTTP 403
In logs, 403s indicate RBAC policy mismatches, tenant isolation violations (user A trying to access user B's data), or scope insufficient errors on OAuth tokens. Common production scenarios: a new user missing a required role, an API token created without a needed scope, or an IP allowlist blocking a new service IP.
When you see HTTP 405
Common when API clients use incorrect HTTP methods (GET instead of POST, DELETE on a read-only endpoint). Also appears after API design changes that restrict previously-allowed methods. Spikes in 405 after a deployment indicate a breaking API change.
Decision rule
Use 403 when the response should communicate forbidden behavior; use 405 when method not allowed is the accurate protocol signal.
A frequent mistake is swapping 403 and 405 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 403 when the correct protocol signal is Forbidden. Use 405 when the correct signal is Method Not Allowed. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 403 and 405?
403 communicates Forbidden, while 405 communicates Method Not Allowed. Choosing the right one keeps clients and intermediaries predictable.
Do 403 and 405 have SEO or caching impact?
Yes. Search engines and caches interpret status classes differently. Use each code according to its semantics to avoid accidental indexing, stale responses, or crawl inefficiency.
Can APIs safely return 403 instead of 405?
Only when it matches contract semantics. API clients often branch logic by exact code, so swapping them can break retries, auth handling, or user-facing errors.
Full guides
HTTP 403 Forbidden — full guide · HTTP 403 status reference · HTTP 405 Method Not Allowed — full guide · HTTP 405 status reference · All comparisons