What does 403 Forbidden mean, and how do you fix it?

What 403 Forbidden means

403 is the HTTP status a server sends when it understood the request and decided not to fulfill it. Nothing broke in transit and the URL may well exist. The answer is simply no. The HTTP specification adds one useful detail: if the request carried credentials, the server considers them insufficient, so sending the same ones again will not help.

It is easy to confuse with its two neighbors, and the difference tells you where to look:

• 401 Unauthorized - the server does not know who you are. Logging in, or sending a valid token, can fix it.
• 403 Forbidden - the server may know exactly who you are, and the answer is still no. A different account, role or network might get through. The same request will not.
• 404 Not Found - the server will not confirm the page exists. Some servers answer 404 instead of 403 on purpose, so they do not reveal that a private page is there.

If you are a visitor

A 403 on someone else's site is almost always a decision made by that site, not a fault on your computer. A few things are still worth trying before you give up:

• Check the address. A URL that ends in a folder (/images/ rather than /images/photo.jpg) often returns 403 because the server will not list what is inside.
• Turn off your VPN or proxy. Firewalls and CDNs block IP ranges that VPN users share, and a 403 that disappears on mobile data is almost always this.
• Sign in, or sign in with the right account. A page for members, admins or another workspace answers 403 to everyone else.
• Clear the site's cookies. A stale session can make a server treat you as someone you no longer are.

If none of that works, the block is intentional or the site is misconfigured, and only its owner can change it.

If it is your site: the usual causes, most likely first

• A firewall, WAF or CDN rule. Country blocks, bot protection, rate rules and IP reputation lists all answer 403. On a site behind a CDN this is the most common cause, and the one most likely to catch search engine and AI crawlers by accident.
• File and folder permissions. The web server process cannot read the file. On a typical Linux host, files need to be readable (644) and folders readable and traversable (755) by the user the server runs as.
• A folder with no index file. When someone requests a directory and there is no index.html, a server with directory listing turned off answers 403. That refusal is the safe default; the missing file is the bug.
• Server rules. A deny rule in .htaccess or the server configuration, hotlink protection on images, or a rule that blocks certain user agents.
• Private object storage. Buckets on S3 and similar services refuse requests for private files that arrive without a signed URL or valid credentials, usually with a 403.
• Your own application. An API route that checks the user's role and refuses. Here a 403 is usually correct, and the real question is whether the right user is being refused.

How to fix it, step by step

Find out which layer is answering before you change anything. A 403 from your CDN, your web server and your application look identical in a browser and are fixed in three different places.

First, request the URL from outside and read the response headers. The Server header and any CDN-specific headers usually name the layer that produced the response.

curl -sI https://example.com/the-page

Then compare with a request from another network, or with the CDN bypassed. If the 403 only appears through the CDN, the rule lives there, not on your server, and its firewall event log will name the rule that fired.

If the response comes from your own server, read its error log at the time of the request. Web servers record the reason for a refusal in plain words, such as permission denied or a directory index being forbidden. For permissions, set what the server needs and nothing more:

find /var/www/site -type d -exec chmod 755 {} \;
find /var/www/site -type f -exec chmod 644 {} \;

Never fix a 403 with chmod 777 or by deleting a firewall rule outright. Both make the error disappear and open a worse problem. Narrow the rule instead: allow the verified crawler or the specific path, and keep the protection for everything else.

Finally, request the URL again from outside, and check a second page that should be covered by the same change. A fix that works on one URL and not its neighbors usually means a rule is matching the wrong pattern.

When a 403 is the right answer

Not every 403 is a bug. Some are among the most important responses your site sends, and removing them would be the real mistake:

• Admin and login areas that strangers should never reach.
• Directories. A folder that answers 403 instead of showing an index of its files is doing its job.
• Private files such as invoices, uploads and exports, which should need a signed link.
• API routes that refuse a user without the right role.

For these the questions are different: is the protected area linked from public pages where it does not need to be, and does the refusal give anything away, such as a stack trace or a server version in the error page?

What a 403 does to Google and AI crawlers

Google treats every 4xx response except 429 the same way: as a page that is not there. A URL that is already indexed and starts returning 403 is removed from the index. Google also states that 401 and 403 have no effect on its crawl rate, so answering 403 to slow the crawler down only removes pages.

The common accident is bot protection. A rule that answers 403 to unknown bots can quietly catch Googlebot, Bingbot or the crawlers AI search assistants use, and the first sign is usually pages dropping out of the index or never being cited. If crawling genuinely needs slowing, 429 or 503 is the signal crawlers understand.

What a scan can and cannot tell you

WebAuditOS records the final status of every page it crawls and reports 4xx and 5xx responses as findings. It deliberately does not grade 401, 403 and 429, because those are usually a login wall, bot protection or rate limiting answering the scanner itself, and reporting them would mostly flag your own security working as intended.

What a scan does check around a 403 is whether directory listings are exposed, whether admin paths are linked from public pages and whether error pages disclose stack traces or server versions. Whether your CDN blocks a particular crawler cannot be confirmed from outside. The places to confirm it are the Page indexing report in Google Search Console and your CDN's firewall log.

A clean scan does not prove that no visitor gets a 403. Firewall rules often depend on the visitor's country, network or browser, so a page that loads for one client can still refuse another.

Short answers

Is a 403 my fault as a visitor? Rarely. It is the site's decision. A VPN, a wrong address or a missing login are the only common causes on your side.

Is a 403 bad for SEO? Only on pages you want in search. Google drops URLs that return it, so make sure no public page does.

Should a private page return 403 or 404? Either is valid. 404 reveals less; 403 is clearer for people who might get in with another account.

Can a CDN return a 403 my server never sees? Yes, and on sites behind a CDN it is the most common case. Check the CDN's firewall events before touching the server.