403 Forbidden Error: What It Means and How to Fix It

A 403 Forbidden error means the server received the request, understood it and refused to answer it. Unlike a 401, logging in won’t necessarily help: the server is saying that this client, from this address, with these permissions, may not have this resource. The cause is almost always a rule, not a crash: file permissions, a missing index file, a deny rule in the server configuration, a firewall or bot protection, an IP or country block, or an account without the right role. Site owners find the rule in the error log or the firewall’s event log; visitors can mostly only change what they send.

403 vs 401 vs 404

Code	What the server says	What helps
401 Unauthorized	Who are you? Send credentials.	Logging in, or a valid API key or token
403 Forbidden	I know what you want, and you can’t have it.	Different permissions, address or request
404 Not Found	There is nothing here.	The right address

Servers don’t always follow the textbook. Some answer 404 instead of 403 to hide that a private page exists, and some answer 403 for missing files: a private storage bucket, for example, can answer 403 for an object that isn’t there when the client isn’t allowed to list the bucket. The HTTP status code reference has the rest.

Common causes

• File and folder permissions. The web server’s user can’t read the file or enter the folder, often after an upload or a deploy that copied files as another user.
• No index file. A request for a folder without index.html or index.php, on a server with directory listing turned off, answers 403. A failed deploy that left the folder empty does the same.
• Deny rules. A deny all in nginx, a Require all denied in Apache, or a rule in .htaccess that blocks a path, a file type or a user agent.
• A firewall or bot protection. A WAF, a CDN’s bot protection or a security plugin decides the request looks automated or malicious and blocks it, sometimes with a challenge page.
• IP and country blocks. The visitor’s address, network or country is on a block list, or the page is limited to an office network or VPN.
• Missing rights. The visitor is logged in, but their role doesn’t allow the page, or an API key lacks the scope for the endpoint.
• Expired or wrong signed links. Download links with a signature or an expiry time answer 403 once they run out.
• Hotlink protection. Images or files requested from another site, or without the expected Referer, are refused.

What visitors can try

• Check the address. A link that ends in a folder rather than a page, or a mistyped path, can hit a folder the server won’t list.
• Log in, or log in with the right account. Some sites show 403 to visitors who aren’t signed in, or to accounts without access.
• Clear the site’s cookies and reload. An old session or a stale challenge cookie can keep a firewall refusing you.
• Change network. Turn a VPN or proxy off, or on, or try mobile data. Shared and data center addresses are blocked more often than home connections.
• Turn off extensions for the site. Some privacy extensions change headers in ways that trip a firewall.
• Tell the site owner, with the time and any reference number the error page shows. That number lets them find the exact rule.

How site owners find and fix it

First work out who answered. Look at the error page and the response headers: a CDN or firewall usually names itself, with a page in its own style, a Server header or a request ID. If it is your web server, its error log names the reason. If it is the CDN or WAF, its event log does.

Permissions and index files

On Linux hosts, folders usually need 755 and files 644, owned by the user the web server or PHP runs as. Check before changing anything, and never fix a 403 with 777, which lets every user on the server write to your site:

ls -la /var/www/example.com/public
find /var/www/example.com/public -type d -exec chmod 755 {} +
find /var/www/example.com/public -type f -exec chmod 644 {} +

nginx logs “directory index of … is forbidden” when a folder has no index file; Apache logs that it can’t find an index and directory listing is off. Check that the deploy put the files where the server’s document root points.

Server rules

nginx logs “access forbidden by rule” for a deny, and Apache logs “client denied by server configuration” for a Require rule. Search the configuration and every .htaccess on the path for the matching rule. On WordPress, saving the permalink settings rewrites the core part of .htaccess, and security plugins add their own blocks there and in their settings.

Firewalls, CDNs and security plugins

Find the blocked request in the event log by time, address or request ID, see which rule matched, and decide whether the rule is wrong or the request really was unwanted. Add exceptions for specific addresses or paths rather than turning a rule off for the whole site. After a firewall change, test from a network outside your office, since your own address may be allowlisted.

Why a monitor gets 403 when your browser doesn’t

A common case: the site works for you, but your uptime monitor reports 403. Usually nothing is broken. Something in front of the site treats the check as a bot, because it is one:

• Bot protection. CDNs and WAFs challenge clients that don’t run JavaScript or look automated. A browser solves the challenge; a monitor can’t, so it gets a 403 or a challenge page.
• Data center addresses. Monitors check from servers, and some rules block hosting networks by default.
• Country blocks. A site that only allows its home country blocks a monitor checking from abroad.
• Rate rules. Some firewalls answer 403 instead of 429 when a client makes too many requests.

The fix is to allowlist the monitor, preferably by its IP addresses, since anyone can copy a user agent. Don’t solve it by accepting 403 as “up” for the whole site: then a real block of your visitors goes unnoticed. If a page really must stay behind the protection, monitor a health check endpoint outside it. The guide to reducing false alerts covers other causes of alerts that aren’t outages.

403 errors and Uptimecheck

An HTTP(S) monitor in Uptimecheck uptime monitoring counts statuses from 200 to 399 as up by default, so a 403 counts as down. A second check confirms it before you are alerted, and the incident explains what answered: when the 403 or a challenge page comes from Cloudflare, Sucuri, Imperva, Akamai, DataDome, Vercel, Wordfence or AWS WAF, it names that service and what to allow there. Website checks come from Stockholm, Sweden, with a user agent that contains “Uptimecheck”. How to allow Uptimecheck through a firewall lists our addresses with ready-made rules for Cloudflare, WordPress security plugins and nginx, and why a monitor can be down when the site works covers the other reasons.

Want to know whether a site answers at all? The free Is it down? checker counts any answer below 500, a 403 included, as up: the server responded, even if it refused.

Tell a blocked check from a real outage. Try Uptimecheck free for 14 days, no credit card required.