How to Fix a 403 Forbidden Error in WordPress
A 403 is not a crash. Something looked at the request and said no. The trick is finding out what.
Updated 29 August 2026
Unlike a 500, a 403 is a decision. Some layer — the filesystem, the web server, a security plugin, a firewall, or your CDN — examined the request and refused it. Finding the fix means finding the layer.
Narrow it down first
Answer these before changing anything:
- Is it the whole site or just wp-admin? Admin-only 403s point at a security plugin or an IP restriction.
- Is it only when you submit a form or save a post? That is mod_security reacting to the request body.
- Does it happen on another network or on mobile data? If not, your IP is blocked.
- Is the page styled like your site or a bare server page? A styled page means WordPress served it; a bare one means the server refused before WordPress ran.
Cause 1: File permissions
Directories should be 755, files 644. If a directory is 644, the server cannot list or traverse it and returns 403. Over SFTP, set folders to 755 recursively and files to 644.
Also check that an index.php or index.html exists in the site root. Without one, and with directory listing disabled, the server returns 403 for the root URL.
Cause 2: A security plugin blocked you
Wordfence, iThemes Security, All In One WP Security and similar tools lock out IPs after failed logins, and some block admin access by country or by IP range. If you cannot get into wp-admin at all, disable the plugin from the filesystem: rename its folder inside wp-content/plugins/, log in, then whitelist your address before re-enabling it.
Check your own IP first — many home connections change address daily, so yesterday's whitelist entry may be worthless today.
Cause 3: mod_security
This is the one people spend longest on, because it looks random. mod_security is a server-level firewall that inspects request contents. Its rules routinely fire on legitimate WordPress activity — saving a post containing a code sample, submitting a form with a URL in it, using the theme editor.
The fingerprint is a 403 that happens only on certain submissions, not on ordinary browsing. You usually cannot fix this yourself; ask your host to check the mod_security audit log for your IP at the exact time, and to whitelist the specific rule ID. Do not ask them to disable mod_security entirely.
Cause 4: A bad .htaccess
A stray Deny from all, or a rule left by a plugin you removed, will 403 the site. Rename .htaccess to .htaccess-old and reload. If the site returns, regenerate a clean file via Settings → Permalinks → Save Changes.
Cause 5: Cloudflare or your CDN
If you use Cloudflare, check Security → Events in its dashboard. It logs every blocked request with the rule that fired. A "Managed Challenge" or WAF rule blocking your own admin traffic is common after enabling a new security setting. The events log gives you the rule to adjust — guessing at settings does not.
Cause 6: Hotlink protection
If images 403 but pages load, hotlink protection is rejecting requests whose referrer it does not recognise. That is usually intentional, but it misfires when the site is reached over a different hostname — for example the bare domain when only the www version is allowed.
A quick decision tree
- Styled 403 page → WordPress or a plugin. Disable security plugins from the filesystem.
- Bare server 403 on every URL → permissions or
.htaccess. - 403 only on save or submit → mod_security. Contact the host with the timestamp.
- 403 only from your connection → an IP block, in the plugin, the firewall, or Cloudflare.
Common questions
Why can I browse the site but not log in?
Login attempts are the most-protected request on a WordPress site. A security plugin, the host firewall or Cloudflare is refusing that specific endpoint — usually after failed attempts from your address.
The 403 only happens when I save a post with code in it.
That is mod_security inspecting the request body and matching a rule intended to catch injection attempts. Your host can whitelist the specific rule for your site.