Skip to content
Website Rescue Rescue

Server Errors

403 Forbidden

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Graphic options · pick what to keep

statusCompare

permissionMatrix

denyRuleStack

decisionTree

requestTimeline

Direct answer

403

A 403 Forbidden means access was denied for this URL — commonly wrong file permissions, a deny rule in `.htaccess`, ModSecurity or WAF blocks, IP denylists, hotlink protection, or ownership that PHP cannot read. Fix the specific deny rule or permissions rather than chmodding everything to 777.

HTTP 403 is an authorization failure, not a crash and not a missing page. On WordPress it often appears after hardening plugins, host security rules, or a migration that broke ownership. This guide separates permission problems from firewall and rewrite denies so you restore access without weakening the whole server.

Intermediate

What the error means

HTTP 403 tells the client the resource exists (or the path is recognized) but the server will not serve it under the current credentials, IP, or file-system rules. That differs from 401 (authentication required) and 404 (not found). On shared hosting, Apache/`Require` directives, nginx `deny`, LiteSpeed rules, ModSecurity signatures, and WordPress security plugins all can return 403. Hotlink protection and directory-index disables also produce 403 when someone requests a folder URL or an image from another referrer. Wrong ownership after a migration can make the web user unable to read files even when numeric modes look fine.

Common symptoms

  • Browser shows “403 Forbidden” or a host-branded access-denied page
  • Homepage, wp-admin, or only certain paths (uploads, ajax, REST) return 403
  • Error logs mention AH01630, “client denied by server configuration,” or ModSecurity
  • Problem started after installing a security plugin, editing `.htaccess`, or migrating hosts
  • Your IP works from home but fails on mobile data, VPN, or office network (or the reverse)
  • Images or CSS from another domain fail while same-origin assets load
  • DevTools Network confirms status 403 (not 401, 404, or 500)

Most likely causes

  1. 01 File or directory permissions too restrictive (or folders not executable for the web user)
  2. 02 `.htaccess` Deny/Require rules, IP blocks, or broken rewrite/security snippets
  3. 03 ModSecurity, Imunify, host WAF, or Cloudflare WAF blocking the request signature
  4. 04 Security plugin firewall, country block, or login/ajax path lockdown
  5. 05 Wrong file ownership after migration so PHP/Apache cannot read the document root
  6. 06 Hotlink protection or referrer checks blocking assets or entire pages
  7. 07 Directory listing disabled and no index file for a folder URL

What changed before the problem started

  • Security plugin installed or rules tightened after an attack
  • Manual `.htaccess` hardening or “permission fix” scripts
  • Host ModSecurity / WAF ruleset update
  • Site migration that changed owner/group or document root paths
  • Cloudflare firewall, bot fight, or IP access rules enabled
  • Hotlink protection or bandwidth-theft rules turned on in cPanel

Troubleshooting steps

  1. 01

    Confirm 403 and note which URL is denied

    In DevTools → Network, verify status 403 and whether it hits the homepage, `/wp-admin/`, `/wp-login.php`, `admin-ajax.php`, REST routes, or static files. Screenshot the response headers and any host error body. Scope matters: sitewide 403 points to root config; path-specific 403 points to a plugin or rule for that URI.

  2. 02

    Check file and folder permissions safely

    Folders are usually 755 and files 644 on typical shared hosts. Confirm `index.php`, `wp-admin`, and `wp-content` are readable by the web user. Do not recursively set 777 — that often triggers host security scanners and can create new 403s. Fix only paths that are wrong.

  3. 03

    Temporarily rename a suspect `.htaccess`

    Download a backup of the root `.htaccess`, then rename it to `.htaccess.bak` and retest. If the 403 clears, restore WordPress defaults via Settings → Permalinks → Save once admin works, then re-add custom rules one block at a time. A single `Deny from all` or bad `Require` line can lock the whole site.

  4. 04

    Disable security plugins and review WAF hits via FTP

    Rename security-plugin folders under `wp-content/plugins` if wp-admin or ajax returns 403. In the host panel, check ModSecurity / Imunify / Cloudflare Security events for your IP and URI at the failure time. Whitelist legitimate traffic or adjust the specific rule rather than turning off all protection permanently.

  5. 05

    Verify ownership after a migration

    If files were uploaded as root or another user, the PHP/Apache user may be denied. Reset ownership to the account the host documents (often your cPanel user). Wrong owner with “correct” chmod still produces 403.

  6. 06

    Test from another network and review IP blocks

    Try a phone hotspot or VPN off/on. If only some networks fail, look for fail2ban, host IP denylists, Cloudflare IP Access Rules, or country blocks. Remove your current IP from denylists and allowlist it before re-enabling strict rules.

When to stop troubleshooting

Stop if you cannot access hosting files or WAF logs, ownership resets are unclear on a managed host, ModSecurity keeps blocking after safe rule adjustments, or checkout and lead capture stay 403 beyond your maintenance window. Permission and firewall mistakes can lock you out of recovery — escalate rather than chmodding the whole tree to 777.

Information to collect before requesting help

  • 01 Exact URL returning 403 and whether wp-admin is affected
  • 02 Status code from DevTools (confirm it is really 403)
  • 03 Host error log / ModSecurity / Cloudflare Security event excerpts
  • 04 Recent security plugin, `.htaccess`, WAF, or migration changes
  • 05 Whether renaming `.htaccess` or security plugins changed the symptom
  • 06 Your public IP and whether another network still fails
  • 07 Hosting provider and whether Cloudflare or another CDN sits in front

How a professional repairs the problem

A technician confirms the true 403 scope, reads origin and WAF logs to the deny rule, corrects permissions and ownership without unsafe modes, restores a clean `.htaccess`, adjusts security-plugin and ModSecurity rules surgically, and verifies homepage, admin, ajax, and key assets load from multiple networks before re-enabling hardening.

Frequently asked questions

Is 403 the same as 401 Unauthorized? +
No. 401 means authentication is required or failed. 403 means access is blocked even when the path is known — often permissions, IP rules, or WAF policy rather than a missing password prompt.
Will fixing permissions with 777 clear a 403? +
Sometimes briefly, but hosts and scanners often block world-writable trees, and you create a serious security hole. Use correct owner plus 755/644 (or the host’s documented modes) instead.
Can a plugin cause 403 on only wp-admin? +
Yes. Security and firewall plugins frequently restrict admin and ajax paths while leaving the public site open. Rename the plugin folder via FTP to confirm, then whitelist your IP.
Why do images return 403 but pages load? +
Hotlink protection, CDN referrer rules, or upload-folder permissions usually target static assets. Check hotlink settings and `wp-content/uploads` ownership separately from WordPress PHP.
How is 403 different from a WordPress “critical error”? +
Critical errors are PHP fatals (often 500 or a WP recovery screen). 403 is an access denial at the web server or WAF layer before or instead of normal PHP handling.
Should I disable ModSecurity forever? +
No. Disable or whitelist the specific rule and path that blocks legitimate traffic, then leave the WAF on. Permanent full disable removes a major host defense.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.