A 403 Forbidden response means the server received your request, understood exactly what you asked for, and refused to serve it. Nothing timed out and nothing crashed. That makes 403 fundamentally different from the 5xx family: the site is not broken, it is blocking. The diagnostic work is figuring out which layer made that decision, and whether it was aimed at you specifically.
The one-line definition ¶
403 Forbidden is an HTTP response status code indicating the server understood the request but refuses to fulfill it.
Per RFC 9110, the refusal is about authorization or policy, not about the request being malformed. The spec adds a detail that matters in practice: if the request already included credentials, the server considered them and refused anyway, so repeating the same request with the same credentials will not change the answer. A 403 is a closed door, not a broken one.
403 vs 401 vs Cloudflare error 1020 ¶
| Code | Message in plain terms | Typical source | Does retrying help? |
|---|---|---|---|
| 401 Unauthorized | "I don't know who you are." | Missing or invalid credentials | Yes, log in or send a valid key |
| 403 Forbidden | "I know what you want, and no." | Policy, permissions, or a security layer | Not without a policy or account change |
| Cloudflare 1020 | "The owner's firewall rule matched you." | A Cloudflare WAF rule, served with HTTP 403 | Not from the same IP or client |
Cloudflare's error 1020 deserves the extra row because it is the most common branded 403 on the web: the HTTP status is 403, but the page body says "Access denied, error 1020," meaning a firewall rule the site owner configured matched your request. It has its own diagnostic path, covered in our error 1020 guide.
Five different things a 403 can mean ¶
The same three-digit code is emitted by at least five unrelated mechanisms, and working out which one you hit is most of the fix.
- Authentication state. An expired session cookie, a deleted API key, or a token signed for the wrong environment. Strictly this should be a 401, but plenty of applications return 403 for any credential problem.
- Entitlement. You are logged in and the server knows exactly who you are, your account simply does not include this resource. A viewer role opening an admin page, a free plan calling a paid endpoint, a repository you were removed from.
- WAF or bot block. A web application firewall in front of the site classified your request as automated or malicious before the application ever saw it. Classification keys on User-Agent strings, TLS fingerprints, header order, request rate, and IP reputation.
- Geo or IP block. The site refuses entire countries, cloud-provider address ranges, VPN exits, or individual IPs with a bad reputation history. Same request, different network, different answer.
- Hotlink protection. Images and other assets requested without the Referer header the server expects get a 403 so other sites cannot embed them for free. The same asset loads fine inside its own page.
The classic signature: 403 in curl, 200 in a browser ¶
The most common 403 confusion looks like this:
curl -I https://example.com/
HTTP/2 403while the same URL renders instantly in Chrome. Nothing is down. A filter in front of the site is classifying requests, and yours only passes when it looks like a human browser. curl announces itself with a User-Agent of curl/8.x, sends a minimal header set, and produces a TLS fingerprint no consumer browser produces. Bot filters key on exactly those signals.
The reverse also happens: a script with a spoofed browser User-Agent gets 200 on GET while every HEAD request gets 403, because the operator refused the HEAD method outright. Either way the lesson is the same, a single request type tells you almost nothing about whether a site is actually reachable.
How a multi-method check makes the block visible ¶
isitdown.io probes every monitored site with 4 independent methods in parallel, every 5 minutes: an HTTP/1.1 request with strict TLS validation, an HTTP/2 request with relaxed TLS, a GET sent with a real browser User-Agent, and a HEAD sent with a curl User-Agent. The diversity is in the request types, not in geography, and that is deliberate: 403-class problems are request-type problems.
Read the pattern like this:
- Browser-UA GET passes, curl-UA HEAD fails. User-Agent filtering. The site is up for humans and blocking obvious automation. Not an outage.
- Both GETs pass, HEAD fails. HEAD refusal. Some origins and firewalls reject the HEAD method entirely, which breaks naive uptime checkers but no real users.
- Strict-TLS HTTP/1.1 fails, relaxed-TLS HTTP/2 passes. A certificate problem rather than a block. Check the chain with the SSL checker.
- All four fail. Either a real outage or an edge that refuses everything unauthenticated. The response bodies decide which.
- All four pass but you personally get 403. The block targets your IP, region, account, or client, not the world. Run the down-for-everyone diagnostic.
A mixed result, some methods passing and some failing, means the site is up but blocking or mishandling a specific request type. Incidents only open after 2 consecutive failed 5-minute rounds and resolve after 2 consecutive passes, so a one-off WAF hiccup never pages anyone. The full reasoning behind the four-method design is in multi-method checks explained, and you can test any domain right now at isitdown.io.
Fixes by cause ¶
| Cause | If you are a visitor | If you own the site |
|---|---|---|
| Auth state | Log out and back in, clear cookies for the site, regenerate the API key | Return 401 for missing or invalid credentials, reserve 403 for genuine policy refusals |
| Entitlement | Confirm your plan or role includes the resource, then ask an admin | Say in the error body which permission is missing, silent 403s become support tickets |
| WAF or bot block | Use a normal browser, slow your request rate, drop automation-only headers | Tune the rule, allowlist known-good monitors and partners by token rather than by UA string |
| Geo or IP block | Turn the VPN off or pick a different exit, try another network | Document which regions you block, use 451 where the block is a legal requirement |
| Hotlink protection | Open the asset from the page it belongs to | Exempt your own domains and your monitoring from Referer checks |
For owners, one rule pays for itself repeatedly: never let your WAF 403 your own monitoring. If your uptime checker reports 403 while customers see 200, every real incident afterwards hides inside that noise.
FAQ ¶
Does a 403 mean the site is down?
No. A 403 is positive proof the server is up: it received your request, parsed it, and answered. The practical effect for you may be identical to an outage, but the fix lives on the policy side, not the infrastructure side.
Why do I get 403 on one network but not another?
IP-based filtering. VPN exits, cloud-provider ranges, and shared corporate NATs accumulate bad reputation because earlier traffic from those addresses misbehaved. Switching networks changes your source IP, and often the answer.
Is 403 ever returned by mistake?
Frequently. Overly aggressive WAF rules, expired allowlists, and clock skew that invalidates signed tokens all produce 403s the operator never intended. If a page you use daily suddenly returns 403 and a multi-method check shows a mixed result, report it, the operator likely tightened a rule without noticing the collateral damage.
Should monitoring treat 403 as a failure?
Treat it as a state change worth an alert, not automatically as an outage. A sudden 403 on all four methods right after a deploy usually means an auth or firewall change shipped by accident, which is exactly the kind of transition a webhook alert on every status change is built to catch.