A 403 Forbidden error in WordPress means the server understood the request, but refused to allow access.
In simple terms, your website is saying: “This page or file exists, but you are not allowed to view it.”
This can happen on the whole website, only the homepage, only wp-admin, only media files, only REST API requests, or only specific plugin/theme pages. The fix depends on where the 403 error appears and what changed before it started.
Common causes include a broken .htaccess file, incorrect file permissions, security plugin rules, hosting firewall blocks, ModSecurity rules, hotlink protection, IP blocks, CDN/WAF rules, malware-injected rules, or server configuration issues.
This guide walks through the most common ways to fix a 403 Forbidden error in WordPress.
What Does 403 Forbidden Mean?
A 403 Forbidden error means access is being denied by the server or a security layer in front of the server.
You may see messages like:
- 403 Forbidden
- Access Denied
- You don’t have permission to access this resource
- Forbidden: You don’t have permission to access / on this server
- Request blocked by security rules
The error can be caused by WordPress, but it can also come from Apache, Nginx, LiteSpeed, Cloudflare, ModSecurity, a hosting firewall, or a WordPress security plugin.
Quick 403 Error Checklist
Before making major changes, check the basics:
- Did the error start after editing
.htaccess? - Did it start after installing or updating a plugin?
- Did it start after enabling a security plugin, firewall, CDN, or Cloudflare rule?
- Is only your IP blocked, or is the error visible to everyone?
- Does the error happen only in
wp-admin? - Does it happen only for images, CSS, JavaScript, or uploaded files?
- Does it happen only on one page, form, checkout, or REST API request?
- Did you recently migrate the site or change hosting?
If the error appeared right after a specific change, start there first.
1. Check the .htaccess File
On Apache and LiteSpeed servers, WordPress uses the .htaccess file for rewrite rules, especially permalinks. A wrong rule in this file can easily cause a 403 error. WordPress’ own Apache documentation explains that .htaccess is used for per-directory configuration and permalink handling.
You can usually find the file here:
/public_html/.htaccess
or inside the main WordPress installation directory.
To test if .htaccess is the cause:
- Connect using FTP, SFTP, hosting file manager, or SSH.
- Find the
.htaccessfile in the WordPress root directory. - Rename it to
.htaccess-backup. - Reload the website.
If the 403 error disappears, the problem is inside the old .htaccess file.
Then create a fresh default WordPress .htaccess file:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
You can also regenerate WordPress permalink rules by going to:
WordPress Dashboard → Settings → Permalinks → Save Changes
If you cannot access the dashboard, manually create the default file above and test again.
Check for Custom Deny Rules
Look for rules that may block access, such as:
Deny from all
Require all denied
RewriteRule .* - [F]
These rules may be legitimate in some locations, but if they are placed incorrectly, they can block the whole site or admin area.
Also check for rules added by security plugins, malware, hotlink protection tools, or hosting firewalls.
2. LiteSpeed and OpenLiteSpeed Note
LiteSpeed generally supports Apache-style .htaccess rules, but OpenLiteSpeed may require a restart or graceful reload before some changes fully apply.
If you use OpenLiteSpeed and recently changed rewrite rules, restart OpenLiteSpeed with:
/usr/local/lsws/bin/lswsctrl restart
On managed hosting, use the hosting panel restart option or ask the host to reload the web server.
3. Check File and Directory Permissions
Incorrect file permissions are one of the most common causes of 403 errors. WordPress files must be readable by the web server, and some directories such as wp-content/uploads must be writable by WordPress when uploads are needed. WordPress’ file permission documentation explains that permissions control who can read, write, modify, and access files.
As a general baseline:
- Directories should usually be
755 - Files should usually be
644 wp-config.phpcan often be more restrictive, such as600or640, depending on hosting setup
From SSH, you can reset common permissions from the WordPress root directory:
# Set directories to 755
find . -type d -exec chmod 755 {} \;
# Set files to 644
find . -type f -exec chmod 644 {} \;
If your WordPress root is public_html, run:
find public_html -type d -exec chmod 755 {} \;
find public_html -type f -exec chmod 644 {} \;
Do not blindly set everything to 777. That can create serious security risks.
Check File Ownership Too
Permissions may look correct, but ownership can still be wrong.
This often happens after:
- Site migration
- Manual file upload as root
- Git deployment
- Backup restore
- Moving between hosting accounts
If files are owned by the wrong Linux user, PHP or the web server may not be able to read them properly. On managed hosting, ask the host to “fix file ownership” or “reset permissions.”
4. Check for a Missing Index File
A 403 error can appear when a directory has no index file and directory browsing is disabled.
For a normal WordPress site, the root directory should contain:
index.php
wp-config.php
wp-content/
wp-admin/
wp-includes/
If index.php is missing from the WordPress root, the server may return 403 instead of loading the site.
This can happen after a failed migration, broken restore, malware cleanup, or accidental file deletion.
5. Temporarily Disable Plugins
A plugin can cause 403 errors if it adds firewall rules, blocks your IP, modifies .htaccess, changes REST API access, protects admin pages, or conflicts with server security rules.
Security, firewall, membership, caching, redirect, and access-control plugins are the most likely causes.
If you can access the WordPress dashboard:
- Go to Plugins.
- Deactivate recently changed plugins first.
- Clear cache.
- Test the page again.
If you cannot access the dashboard, disable all plugins using FTP/SFTP or file manager:
- Go to
wp-content/. - Rename
pluginstoplugins-disabled. - Reload the website.
If the 403 error disappears, rename the folder back to plugins, then disable plugins one by one until you find the cause.
6. Check Security Plugin, WAF, or IP Blocking Rules
Many 403 errors are intentional blocks from security rules.
A WordPress security plugin or firewall may block access because of:
- Too many failed login attempts
- Suspicious query strings
- Blocked country
- Blocked IP address
- Blocked user agent
- REST API restrictions
- XML-RPC protection
- Admin URL protection
- Bot detection
If you use SiteFort Security Plugin, check the firewall and audit logs to see whether your request was blocked by an IP, country, user-agent, bot, login, XML-RPC, or rate-limiting rule. This is much faster than guessing because the logs can show why the block happened.
If needed, whitelist your IP, loosen the rule, or temporarily disable the specific firewall feature causing the false positive.
7. Check Cloudflare, CDN, or Edge Firewall Rules
If your website uses Cloudflare or another CDN/WAF, the 403 may be coming from the edge layer instead of WordPress.
Check:
- Cloudflare WAF custom rules
- Bot Fight Mode or bot protection settings
- Country blocking rules
- IP access rules
- Rate limiting rules
- Page rules or redirects
- Managed challenge rules
A quick test is to pause Cloudflare temporarily or switch the DNS record to DNS-only, then test again. Do this carefully on production sites because it may expose your origin server directly.
If the error disappears after bypassing Cloudflare, the issue is likely in Cloudflare rules, not WordPress.
8. Check ModSecurity or Hosting Firewall
Some hosts use ModSecurity or similar web application firewall rules at the server level.
These rules can block legitimate WordPress requests, especially when saving forms, updating settings, using page builders, uploading files, or submitting WooCommerce checkout data.
Common signs of ModSecurity-related 403 errors:
- 403 appears only when saving a page or settings
- 403 appears only when submitting a form
- 403 appears only with certain words, scripts, or HTML content
- 403 appears in admin but not on the frontend
- Nothing changes when plugins are disabled
Ask your hosting provider to check ModSecurity logs for the exact blocked rule ID. They can usually whitelist the specific rule if it is a false positive.
9. Check Hotlink Protection
If images, CSS, JavaScript, PDFs, or uploaded files return 403, hotlink protection may be blocking them.
This can happen when:
- The domain was recently changed
- The site moved from HTTP to HTTPS
- A CDN was added
- Allowed referrers are misconfigured
- Media files are loaded from a different domain or subdomain
Check your hosting panel, CDN, or security plugin for hotlink protection settings.
10. If Only wp-admin Shows 403
If the frontend works but wp-admin shows 403, check these first:
- Security plugin admin protection rules
- Custom login URL settings
- IP restriction rules in
.htaccess - Cloudflare WAF rules
- ModSecurity blocks
- Incorrect permissions on
wp-admin - Missing WordPress core files
- Malware or cleanup rules that accidentally blocked admin access
Also check whether the 403 happens before login, after login, or only on specific admin pages. That detail can quickly narrow down the cause.
11. If REST API Requests Show 403
Modern WordPress depends on the REST API for the block editor, admin screens, plugins, WooCommerce, forms, and integrations.
If REST API requests return 403, you may see issues such as:
- Block editor not loading
- Plugin settings failing to save
- WooCommerce features not working
- Form submissions failing
- “Updating failed” or “Publishing failed” messages
Check whether a security plugin, custom code, Cloudflare rule, or server firewall is blocking /wp-json/ requests.
Do not blindly disable the REST API. Instead, restrict sensitive endpoints and allow the normal WordPress REST API routes your site needs.
12. Check for Malware or Malicious Rules
A 403 error can also be caused by malware or a bad cleanup attempt.
Attackers sometimes add rules that block admins, redirect visitors, protect backdoor files, or hide malicious content from certain users. A cleanup script or manual removal can also accidentally leave broken deny rules behind.
Check for:
- Unknown rules in
.htaccess - Unexpected PHP files in
wp-content/uploads - Modified core files
- Unknown admin users
- Suspicious security rules added recently
- Backdoor files that recreate blocked rules
SiteFort can help scan for malware, backdoors, modified core files, suspicious PHP, injected scripts, vulnerable plugins/themes, and exposed sensitive files. It also keeps audit and firewall logs so you can understand whether a 403 is caused by protection rules or something suspicious.
13. Clear All Cache Layers
After making changes, clear every cache layer:
- Browser cache
- WordPress cache plugin
- Object cache
- Server cache
- LiteSpeed cache
- Cloudflare/CDN cache
A cached 403 page can make it look like the issue still exists even after the real cause has been fixed.
14. Check Server Logs
If none of the above works, check logs. Logs usually reveal the exact reason for the block.
Useful logs include:
- Apache error log
- Nginx error log
- LiteSpeed error log
- PHP error log
- ModSecurity audit log
- Cloudflare firewall events
- WordPress security plugin logs
Look for messages such as:
client denied by server configuration
permission denied
access forbidden by rule
ModSecurity: Access denied
AH01630: client denied by server configuration
directory index forbidden
These messages usually point directly to the cause.
15. When to Contact Your Hosting Provider
Contact your host if:
- You cannot access server logs
- Permissions look correct but the error remains
- The issue started after a server update
- Only the host can change ModSecurity rules
- The error appears before WordPress loads
- The whole account or IP seems blocked
- You suspect ownership problems after migration
Send them the exact URL showing 403, your IP address, the time of the test, and what you already tried. This helps them find the block faster.
Find the Block Before You Disable Everything
A WordPress 403 Forbidden error is usually fixable once you identify where the block is coming from.
Start with the most common causes: .htaccess, file permissions, file ownership, plugins, security rules, Cloudflare/CDN settings, ModSecurity, and server logs.
If the error started after a security change, check firewall and audit logs before disabling everything. If the error appeared after a migration, check ownership and permissions. If only certain requests fail, check ModSecurity, REST API rules, or WAF events.
For ongoing protection and easier troubleshooting, SiteFort Security Plugin can help monitor firewall blocks, login activity, hardening rules, vulnerabilities, malware indicators, and suspicious requests from one WordPress security dashboard.