HTTP 403 Forbidden: What Causes It and How to Fix It

A 403 is one of the few status codes that tells you almost nothing on its own and almost everything once you know where it came from. The same three digits are returned by a Django view checking a role, an nginx directory with the wrong permissions, an API gateway rejecting a token scope, and a bot-management layer that decided your TLS fingerprint did not match your User-Agent. Those four problems share no fix.

Start here: which situation are you in

403 versus the codes it gets confused with

Getting the code right narrows the search enormously, because each one points at a different subsystem.

Fixing 403 as a visitor

Most consumer 403s are mundane. Work through them in order and stop at the first one that changes the result.

1. 1Log in, or switch accounts. A surprising share of 403s are a paid or gated resource behind an anonymous session.
2. 2Clear cookies for that site alone. A stale or half-written session cookie is refused more often than no cookie at all.
3. 3Turn off the VPN. Consumer VPN ranges are among the most heavily blocked address space on the internet.
4. 4Disable extensions that rewrite requests. Ad blockers, privacy tools and header spoofers all trip WAF rules.
5. 5Try a different network. School, office and carrier NAT pools share one address across thousands of users; one of them got you blocked.

Refreshing hard is the one thing not to do. If the 403 came from abuse controls, repeated retries extend the penalty and can escalate a soft block into a durable one.

Fixing 403 on a site you own

Identify the layer before you change a rule. A 403 generated by nginx looks identical in the browser to one generated by your framework, and the two live in different files.

• Static files — almost always filesystem permissions, a missing index file, or directory listing disabled.
• Application routes — role checks, subscription state, feature flags, or middleware that runs before your handler.
• API endpoints — token scope, organisation or workspace mismatch, or an endpoint gated behind a higher plan.
• CDN and WAF — country rules, ASN rules, bot scores, or a managed ruleset that fired on a header you added last week.
• Hotlink protection — a referrer check refusing requests that did not originate from your own pages.

Fixing 403 when scraping

For automated traffic the interesting question is whether the site refused your address or refused your request. One test separates them: send the identical request again through a different exit IP. Success means the previous address was the problem. Failure means the request itself is, and no amount of rotation will change that.

When the address is the problem

Blocks tied to the address show up as clean failure on some exits and clean success on others, with the same headers and the same payload. The usual causes are a datacenter ASN that the target rejects wholesale, a residential IP with a poor fraud score from previous abuse, or too much of your own volume concentrated on one address.

This is the case proxies actually solve. Residential proxies route through consumer connections that sit in the same address space as the site's real customers; ISP proxies give you one stable, residential-registered address for workflows that cannot rotate.

When the request is the problem

If every exit fails identically, the site is reacting to how the request looks. The signals that most often give an automated client away are internally inconsistent rather than individually wrong.

• A User-Agent claiming Chrome 140 next to a TLS handshake that belongs to Python.
• Accept-Language absent, while every real browser sends one.
• Header order that no browser produces, which is trivially fingerprintable.
• A session that changes User-Agent mid-flight, which no real client does.
• Missing cookies the site set on an earlier page in the flow you skipped.

Fix consistency before adding sophistication. Most 403s in scraping come from a mismatch between what the client claims and what it demonstrably is — the full picture is in how to avoid getting blocked.

When 403 is really a bot wall

Protection layers rarely announce themselves in the status line. The body is where the tell is: a challenge page, a support ray ID, a block reason, or a JSON envelope naming the vendor. Cloudflare in particular returns branded codes that look like a 403 but carry a much more specific meaning — error 1020 is a custom firewall rule, and a rate-limit block is 1015 rather than 429.

Log the response body on failure, not just the status. A scraper that records 403 and nothing else throws away the only field that would have told you which of six causes applied.

A diagnosis order that holds up

1. 1Reproduce with curl. Removes your framework, your middleware and your retry logic from the picture.
2. 2Repeat on a second exit. Splits address problems from request problems in one step.
3. 3Compare against a real browser on the same connection, with the network tab open.
4. 4Diff the two requests header by header. The difference that matters is usually boring.
5. 5Read the response body and record it alongside the status, the exit IP and the target host.

Individual 403s tell you very little. The distribution across exits, targets and time is what actually identifies the cause, and you only get that distribution if the logging is in place before the incident.