403 Forbidden

403 Forbidden means the server understood the request, knows (or doesn't care) who you are, and refuses to fulfil it. Unlike 401, re-authenticating won't help — this is about permissions, not identity.

Common causes

• Genuine permission checks — the account lacks the role for the resource. The most correct use of the code.
• WAF and bot-protection rules — Cloudflare, AWS WAF and friends 403 requests that trip a rule: suspicious user agent, blocked country, rate pattern, SQL-injection-looking query string. Automated checks and scrapers see these constantly. If your monitoring is blocked by your own WAF, allowlist the probe identity rather than disabling the rule.
• Filesystem permissions — nginx/Apache can't read the file (see the chmod calculator — web content typically needs 644, directories 755, owned by the right user).
• Directory listing denied — no index file and autoindex off yields 403, not 404.
• IP allowlists — office-IP-only admin panels 403 everyone else; breaks when the office IP changes.
• Hotlink protection — images 403 when the Referer isn't yours.
• Cloud storage ACLs — a private S3 object behind a public URL returns 403 (S3 also uses it to mask 404s when you lack list permission).

Is it a bug or a feature?

The hard part with 403 is that it's often correct — a security control doing its job. Ask: did the request come from an unexpected source (VPN, crawler, new region)? Did a security rule change recently? A 403 that only happens from some networks is almost always an edge rule, not your application.

Debugging

Compare the same request from different vantage points — the free HTTP header checker runs from our probes, your browser runs from your network; a difference points at IP- or fingerprint-based rules. Response headers usually reveal the blocker (cf-ray, x-amzn-waf-…). A multi-region HTTP monitor catches the day a WAF change starts 403ing real users in one geography.