A 403 Forbidden error means the server got your request but refused to fulfill it. That's different from a 404 (nothing there) or a 500 (something broke). A 403 almost always traces back to one of four things: file or folder permissions, file ownership, a deny rule in .htaccess, or a security module blocking the request. Work through them in that order and you'll usually find it fast.
Start with the error log. It often names the exact rule or file that triggered the block, which saves you from guessing. See enabling error logging if logging isn't already on.
Check file and folder permissions
Wrong permissions are the single most common cause of a 403, especially after a manual file upload or a restore from an old backup. The server needs execute permission on directories to even look inside them, and it needs read permission on files to serve them.
- Folders should be
755(owner: read/write/execute, group and world: read/execute). - Files should be
644(owner: read/write, group and world: read only). - Anything at
777is a red flag, not a fix. It's overly permissive and some security scanners will actually flag it and quarantine the file, producing a 403 as a side effect.
Check permissions via FTP (most clients show them in a column, or right-click → File permissions) or through the File Manager in the portal. For the full breakdown of what each permission mode means and how to set it in bulk, see file permissions.
Missing index file
If a directory has no index.html, index.php, or similar, and directory listing is disabled (the default, for security), you'll get a 403 instead of a directory listing. This is expected behavior, not a bug. Add an index file, or if you're intentionally browsing a folder, that folder needs directory indexing explicitly enabled, which we don't recommend leaving on for anything public-facing.
Check file ownership
Files uploaded through some FTP clients, restored from an old backup, or created by a script running as a different user can end up owned by the wrong account. If ownership doesn't match your hosting account's user, the web server may refuse to serve the file even if the permission bits look correct.
If you have shell access, ls -la in the affected directory shows the owner in the third column. It should match your account's username, not root or another account. Without shell access, re-upload the file through FTP or the File Manager using your account's credentials, which resets ownership correctly.
Check .htaccess for deny rules
A 403 that started right after you or a plugin edited .htaccess is almost certainly a deny rule, not a permissions issue. Common culprits:
Deny from allorRequire all deniedleft over from a maintenance mode or staging lockdown.- An IP allowlist that no longer matches your current IP (this bites people constantly after a network or VPN change).
- A security plugin (WordPress or otherwise) that wrote overly broad rewrite or deny rules.
To test: rename .htaccess to .htaccess.bak via FTP and reload the page. If the 403 disappears, the rule is in there. Open the renamed file, look for Deny, Require, or .htaccess from wp-admin → Settings → Permalinks → Save Changes, which is the fastest way to rule out a corrupted rewrite section. This is the same troubleshooting move used for a 500 Internal Server Error, since a broken .htaccess can cause either symptom depending on the specific syntax problem.
Imunify360 false positives
Imunify360 is a web application firewall that inspects requests against a ruleset and blocks anything that looks like an attack pattern: SQL injection attempts, suspicious file uploads, unusual header combinations. It's good at catching real attacks, but it occasionally flags legitimate traffic, especially form submissions with unusual content, certain plugin AJAX calls, or API requests with uncommon payloads.
If a specific action reliably triggers a 403 (submitting a particular form, hitting a particular endpoint) while the rest of the site works fine, Imunify360 is a likely suspect. The error log will show an Imunify360 rule ID and a description of what it matched, which is what you'd reference if you open a ticket asking for a rule exception. Don't try to disable Imunify360 site-wide to work around one false positive; that trades a minor annoyance for a real security gap.
Hotlink protection
If images or other assets return a 403 only when loaded from a different domain (someone else embedding your images directly, or a CDN misconfiguration), hotlink protection is likely the cause. It's a deliberate rule that blocks requests where the Referer header doesn't match your own domain, meant to stop other sites from leeching your bandwidth by linking directly to your files. If you've set this up yourself via .htaccess rewrite rules and it's now blocking a legitimate use case (your own CDN, a mobile app, a partner site), the fix is to add that referrer or user agent to the allowlist in the same rule block rather than removing hotlink protection entirely.
When to open a ticket
If you've checked permissions, ownership, and .htaccess, and the error log points at an Imunify360 rule ID you don't recognize or can't safely adjust yourself, open a ticket from Support → New ticket in the portal, or use live chat. Include the exact URL, the timestamp, and the relevant error log lines. Our support team can add a targeted Imunify360 exception for that rule and path without turning off protection for the rest of your site.