Unlike most error pages, a 403 Forbidden is not a sign that anything is broken. The request arrived, the server understood it perfectly, found the resource, and then refused to hand it over. That refusal is deliberate.
This matters because it changes what you should look for. There is no crash to find and no service to restart — there is a rule somewhere saying "not this, not for you". This guide explains how a 403 differs from a 401, walks through the causes in the order they actually occur, and covers the situations where a 403 means everything is working exactly as intended.
403 Forbidden vs 401 Unauthorized
These two are routinely swapped, including by developers, and the distinction is genuinely useful when you are trying to fix one.
A 401 means "I do not know who you are — prove it." Logging in may solve it. A 403 means "I know exactly who you are, and the answer is still no." Logging in will not help, because identity was never the problem.
| Code | What it means | What the visitor can do |
|---|---|---|
| 401 Unauthorized | You have not authenticated, or your credentials were rejected | Log in, or fix the credentials being sent |
| 403 Forbidden | You are identified but not permitted to access this | Nothing — the owner has to change the rule |
| 404 Not Found | The resource does not exist at that address | Check the URL for typos |
| 429 Too Many Requests | You are rate limited for sending too many requests | Wait, then slow down |
The Usual Causes, Most Likely First
- Wrong file or directory permissions. Web files normally need 644 and directories 755. A file set to 600 is unreadable by the web server and produces an immediate 403.
- No index file in the directory, with directory listing turned off. The server has nothing to show and is not allowed to show the file list, so it refuses. This is the single most common cause of "my folder gives 403".
- A rule in .htaccess or the server config. A "Deny from all", a hotlink-protection block, or an IP allowlist that no longer includes you.
- A security plugin or WAF blocking you. WordPress firewall plugins, ModSecurity and Cloudflare rules all return 403 when a request trips a rule — often a false positive on a perfectly ordinary request.
- Your IP has been blocked. Either deliberately, or automatically by a brute-force blocker after failed logins.
- The file is owned by the wrong user. Common after uploading over SSH as root or restoring a backup — the files exist and look fine but the web server user cannot read them.
- Geographic or bot blocking. Some sites return 403 to entire countries, to datacenter IP ranges, or to anything that looks automated. VPN users hit this constantly.
Work Through It in This Order
Start by establishing whether it is only you or everybody, because that single fact eliminates half the list above.
- Open the page in a private window, and then on mobile data with Wi-Fi off. If it works on mobile data, your IP is being blocked and the problem is not the file permissions.
- Ask someone in another country to open it, or use an online checker. A 403 for you and a 200 for them means geographic or IP-based blocking.
- If it is broken for everyone, check permissions first: 644 for files, 755 for directories. On shared hosting the File Manager shows and changes these; over SSH use "chmod 644" and "chmod 755".
- Check that an index file exists in the directory — index.html or index.php. If you genuinely want visitors to see a file list, directory listing has to be turned on explicitly.
- Rename .htaccess to .htaccess.bak and reload. If the 403 disappears, a rule in that file is responsible and you can bisect it from there. Put the file back once you know.
- Disable security plugins one at a time. Firewall and "hardening" plugins are a frequent source of false-positive 403s, particularly on admin URLs and REST API endpoints.
- Check the server error log. Apache and ModSecurity both record which rule triggered, which turns guesswork into a single line of text.
- Check file ownership. On a typical Linux host the web server runs as www-data, nginx or a per-account user; files owned by root will not be readable no matter how the permissions look.
When a 403 Is Correct
Not every 403 is a bug. A great many are the server protecting something exactly as designed, and "fixing" them would be the actual mistake.
Configuration files, backup directories, .git folders, environment files and upload directories that should never execute code are all routinely and correctly blocked. If you find a 403 on /.env or /.git/config, that is good news — those files being readable would be a genuine security incident.
Rate limiting and bot blocking also show up as 403. If your scraper, monitoring tool or API client is getting 403s while a browser works fine, the server is telling you it does not want automated traffic at that rate. The fix is to slow down or ask for access, not to disguise the requests.
Before changing anything, ask whether this resource is supposed to be public. If the answer is no, the 403 is doing its job and the right move is to leave it alone.
Want full control over your own permissions and firewall rules?
Cloud VPS with full root access, real error logs and no shared-hosting restrictions — from ฿150/month.
Frequently Asked Questions
Why do I get 403 but my colleague does not?
Something is treating your request differently — almost always your IP address. Either it has been blocked deliberately, or a brute-force blocker banned it after failed logins, or you are on a VPN whose exit IP is on a blocklist. Test on mobile data: if the page loads, your IP is the difference.
I set the file to 777 and it still gives 403. Why?
Because permissions were probably not the problem, and now you have created a security risk as well. If 777 does not fix it, look at the parent directory's permissions, at file ownership, or at an explicit deny rule in .htaccess. Set the file back to 644 either way.
Can a 403 hurt my search rankings?
Yes, if Googlebot is the one receiving it. Aggressive firewall rules sometimes block search engine crawlers, and a page Google cannot fetch will eventually drop out of the index. Use Search Console's URL Inspection to see exactly what Googlebot gets — it may be very different from what you see.
What is the difference between a 403 from Cloudflare and one from my server?
Cloudflare's 403 pages are branded and carry a ray ID; a server 403 is usually a plain page from Apache or Nginx, or your own custom error page. If it is Cloudflare, the rule lives in your Cloudflare dashboard, not on your server — which is why editing .htaccess achieves nothing.
GUIDES
Related articles
Keep reading on similar topics
404 Not Found — Causes, SEO Impact and When It Is Correct
Every site has 404s and most of them are fine. The ones that matter are the pages that used to exist, that people still link to, and that quietly returned a 200 while showing "not found". This guide separates the harmless from the costly.
Read more
500 Internal Server Error — Causes and How to Fix It
A 500 is the least informative error on the web: it means "something went wrong and I am not telling you what". The good news is that the server almost always wrote the real reason to a log file. This guide shows you where that log lives and how to work through the causes in the order that finds the culprit fastest.
Read more
502 Bad Gateway — What It Means and How to Fix It
A 502 means one server asked another server for the page and got back something it could not use. This guide explains which two machines are involved, how 502 differs from 500 and 504, and the order to work through the causes so you find the real one first.
Read more