How to fix a 403 Forbidden error

A 403 Forbidden error is the server telling you, deliberately, that it will not hand over the page you asked for. That is a distinct thing from a page that doesn't exist — a 403 means the server found something at that address and actively refused it. Somewhere, a permission, a rule, or a firewall has decided the request should be blocked.

Nothing about a 403 implies your files are damaged or your data is at risk. It means access control is working exactly as configured, and the job is finding out which piece of configuration is doing it — because it usually isn't the one you expect.

The causes, in the order worth checking

1. File or folder permissions are wrong

This is the most common cause by a wide margin, especially right after a manual upload or a restore, because some FTP clients and archive tools don't preserve the original permission values.

Check permissions on the specific file that's returning the 403 first, then work upward through its parent folders — a single restrictive folder anywhere in the path will produce a 403 for everything inside it, even if the file itself is set correctly.

2. There is no index file, and directory listing is off

When a folder has no index.php or index.html and directory browsing is disabled at the server — which it is by default, and should stay that way — the server has nothing to serve and nothing it's willing to show instead, so it returns 403 rather than a file listing. This is normal, correct behaviour for any folder that isn't meant to be browsed directly, but it's a common surprise on the homepage folder itself if the index file was never uploaded, was uploaded with the wrong name, or was uploaded with the wrong capitalisation — Linux servers treat Index.html and index.html as two different files.

3. A Deny rule in .htaccess is blocking the request

Open .htaccess in the affected folder and look for lines containing Deny from, Require all denied, or Order deny,allow. These are sometimes left behind deliberately — to lock a staging area, for instance — and sometimes left behind by accident after testing something else. Comment out the block with a # at the start of each line and reload to confirm it was the cause before deciding whether to remove it for good.

4. Hotlink protection is blocking your own site

Hotlink protection stops other websites embedding your images directly, and it works by checking the referring page for each request. Configured too strictly, it can end up blocking requests that come from your own site — most often when a page loads assets from a different subdomain, a CDN, or over a different protocol than the rule expects. If the 403 is limited to images or specific file types rather than the whole site, this is worth checking before anything else on this list.

5. A firewall or security rule is blocking the request

A web application firewall can return a 403 when it flags a request as suspicious — an unusual URL pattern, a blocked country, a rate limit, or a signature match on something that looks like an attack but isn't. This is the one genuinely platform-side cause, and it's worth checking after the four above rather than before them, because the great majority of 403s trace back to something in your own files.

Finding the exact rule from the log

Apache's error log records which directive caused a 403, not just that one happened. Open the error log section of your control panel and look for a line near the time you saw the error — it typically reads something like client denied by server configuration alongside the exact file path, which tells you precisely which folder's permissions or rules to check first rather than working through the whole list blind.

If you've worked through all of that

Note the exact URL that returns the 403, the time it happened, and whether it affects every visitor or only some. With those three details, support can check the server-side logs directly and tell you within one exchange whether it's a file-level issue or something at the platform firewall.