403 Forbidden

The short version: Visiting the page? Double-check the URL, clear your cache and cookies, switch off any VPN, and try once more. Running the website? It is almost always one of four things: file permissions set wrong, a bad .htaccess rule, a missing index file, or a firewall or security plugin turning the request away.

Key takeaways

• 403 Forbidden means the server understood you perfectly and chose to refuse. DNS resolved, the connection opened, TLS finished: this is a permission decision, not an outage.
• A 401 invites you to authenticate. A 403 does not. Per RFC 9110 the server has already decided this request is not allowed, logged in or not, and that is the whole point of the 401-vs-403 split.
• On the owner side, three things cause most 403s: file or folder permissions set wrong (644 for files, 755 for folders), no directory index, or a deny rule sitting in .htaccess or an nginx location block.
• Plenty of 403s come from the edge instead. A WAF, firewall, CDN, or security plugin can turn away an IP, a country, a user agent, or a bot, and that net sometimes catches legitimate crawlers like Googlebot or your own monitoring.
• From the outside a 403 reads like a healthy server answering fast, so a simple up-or-down ping marks the website up while real visitors hit a wall on the blocked path.

Error type

HTTP 4xx client error

Whose side

Either: your access or the website config

Fix difficulty

Easy to moderate

Common cause

Access to the resource is denied

What does 403 Forbidden mean?

A 403 Forbidden lives in the 4xx family, the side of the spec that blames the request rather than a crashed server. The server got your request, parsed it, and the resource may well be sitting right there. It is choosing not to authorize you. RFC 9110 is blunt about this: retrying with fresh or different credentials is unlikely to change anything, and that is precisely the line between a 403 and a 401. A 401 means the server has not figured out who you are yet and wants you to authenticate. A 403 means it has decided, and the answer is no, whether you are signed in or not.

Sometimes the refusal is on purpose, sometimes it is an accident. By design, the server might be enforcing a permission rule, an IP allowlist, hotlink protection, or a firewall policy. By accident, it is just as likely to be a misconfiguration: permissions clamped down too hard, a directory with no index file, or a stray deny rule lurking in .htaccess. A few servers even prefer 403 to 404, openly admitting the resource exists but is off-limits rather than pretending it is not there. Either way, the cure is in the server config, not in hammering the browser harder.

403

HTTP status code

4xx

Client-side error class

644 / 755

Correct file / folder permissions

How the 403 Forbidden error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com/admin

403

Forbidden

You don't have permission to access this resource.

• 403 Forbidden
• HTTP Error 403 - Forbidden
• Forbidden: You don't have permission to access this resource
• Access Denied
• 403 Forbidden nginx
• Error 403

403 vs 401, 404 and 400

All four sit in the 4xx client-error family, but they answer different questions about why the request failed.

Where a 403 comes from and how to confirm it

A 403 can originate at several layers, and each leaves a different fingerprint, so locating the layer is the fastest way to the fix.

What causes 403 Forbidden?

• File or folder permissions set wrong, far and away the most common cause. Files want 644, folders want 755; anything tighter and the server will not serve them.
• No index file in the directory you asked for (index.html or index.php). With directory listing off, the server has nothing to show and answers 403.
• An .htaccess file gone bad: a deny rule, a broken rewrite, or a Require directive that walls off the path.
• A WAF, firewall, or plain IP block rejecting your address, user agent, or country. These rules sometimes sweep up legitimate bots like Googlebot too.
• Hotlink protection refusing image or file requests because the referrer is not on the allowed list of domains.
• A security or caching plugin, the usual story on WordPress, that has flagged the request or sealed off wp-admin.
• An empty document root, or a CDN, reverse proxy, or origin-shield pointed at the wrong path or running its own access rules.

How to find the cause fast

1. Pin down the scope before anything else. Is it every page, or one URL or directory? A site-wide 403 points at permissions, an empty document root, or a server-level rule. A single path points at a local rule, a missing file, or a plugin.
2. Open SFTP or your host's file manager and check permissions. Files should read 644, folders 755, and an index file should actually be present in the directory you are requesting.
3. Open .htaccess on Apache, or the relevant location block on nginx, and scan for deny, Require, or autoindex rules. Rename or comment them out for a moment and watch whether the 403 clears.
4. Then look at whatever guards the app: a WAF, firewall, CDN, or security plugin. Dig through its logs for a block on your IP, your user agent, or the affected URL, and make sure it is not quietly blocking your own monitoring or crawl traffic.

Terminal

curl -sI https://example.com/adminHTTP/1.1 403 ForbiddenServer: Apache# file permissions, an IP rule, or a WAF blocked it

How 403 Forbidden looks from the outside

To anything checking from the outside, a 403 looks like a server in perfect health. The connection opens, TLS finishes, a real HTTP response comes back fast, just carrying the wrong status code. That is what makes 403 so sneaky: a plain up-or-down ping happily calls the website up while real visitors get turned away. The only way to catch it is to read the actual status code on the URL that matters, not just whether the host answers at all. A firewall or WAF rule that starts blocking a whole path, or even your own monitoring agent's IP, can flip a page to 403 with nothing else looking out of place.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 403 Forbidden

If you are a visitor

1. Read the URL again for typos. Make sure you are asking for a page, not a directory the website will not let you browse.
2. Refresh once. A brief, one-off 403 sometimes just clears itself.
3. Clear your browser cache and cookies, or open the page in a private window, in case a stale or bad cookie is what is triggering the block.
4. Drop any VPN or proxy and try again. Some websites forbid whole VPN IP ranges or specific countries.
5. Switch off browser extensions or security software that could be getting in the way, then reload.
6. Still stuck? Then the block is on the website's end. Wait and retry later, or tell the website owner the page is coming back forbidden.

If you run the website

1. Set permissions straight: 644 for files, 755 for folders, and 440 or 400 for wp-config.php, applied recursively over SFTP or your host's tools.
2. Confirm the requested directory has a real index file (index.html or index.php), or that the server is set to serve one.
3. Reset a broken .htaccess. Back it up, delete it, and let the app write a clean one (in WordPress, open Settings then Permalinks and hit Save Changes).
4. Comb through your firewall, WAF, and any IP allow or deny lists for rules catching legitimate visitors, bots, or your own monitoring agents, then adjust or allowlist them.
5. Turn off security and caching plugins one by one (on WordPress, rename the plugins folder, then reactivate each in turn) until the plugin forcing the 403 shows itself.
6. Open your hotlink protection settings and make sure every domain that should be loading your assets is on the allowed-referrer list.
7. Bypass or reconfigure your CDN or reverse proxy for a moment to see whether the 403 is coming from the edge rather than your origin.
8. Run a malware scan, since an infected website can inject rules that block access, and loop in your host if the cause turns out to be a server-level config.

Still not fixed? Next steps

• Reproduce it from somewhere that is not your own network: curl -sI from a server or a different connection. If the 403 trails your IP wherever you go, an allowlist, firewall, or country rule is blocking you, not a broken file.
• Now bisect the stack from the top. Bypass the CDN by hitting the origin IP, then turn off the WAF or security plugin, then rename .htaccess. Check after each step, and the layer that stops returning 403 is your culprit.
• Read the access and error logs for the request that actually 403d. Apache writes the matched rule or the permission that failed; nginx writes the directory-index or rule failure. More often than not the log names the cause outright.
• Origin clean but the edge still turning away real traffic or crawlers? Take it to your host or CDN support with the request ID or ray ID printed on the 403 page so they can trace which rule fired.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Reset file and folder permissions over SFTP

# folders to 755, files to 644 (run from the website root)
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Regenerate a clean Apache .htaccess

# back up the old file, then let the app rebuild it
mv .htaccess .htaccess.bak
# in WordPress: Settings > Permalinks > Save Changes writes a fresh one

Define a directory index (nginx) so the folder is not refused

# inside the relevant location / server block
index index.html index.php;
# a missing index file with autoindex off returns 403 Forbidden

How to prevent 403 Forbidden

A 403 tends to show up after a permissions change, a fresh security rule, or a bad deploy, and on a key page it locks out every visitor without a sound. Pulsetic checks your website and the URLs you care about from multiple locations every 30 seconds, runs keyword checks to confirm the right content actually loaded, and pings you over email, SMS, Slack, and more the instant a page starts returning 403 instead of what it should. It watches availability from the outside, never touching your server's internals.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.