8 Ways to Fix a 403 Forbidden Error on Your Website

A 403 Forbidden error is an HTTP status code returned by a web server when it understands the client's request but actively refuses to fulfill it due to insufficient permissions. Unlike a 404 (resource not found), a 403 confirms the resource exists — the server simply will not allow access to it. This distinction matters enormously when diagnosing the root cause.

The error can originate from a dozen different layers: filesystem permissions, .htaccess directives, server-level configuration blocks, IP deny rules, CDN or WAF policies, or even a misbehaving WordPress plugin. This guide walks through every meaningful fix in order of likelihood, with exact commands, configuration snippets, and the edge cases most tutorials skip entirely.

What Triggers a 403 Forbidden Error

Before applying any fix, it helps to understand the decision tree a web server follows. When Apache or NGINX receives a request, it evaluates:

1. Filesystem permissions — does the server process user have read access to the file?
2. Ownership — is the file owned by the correct user (typically www-data, apache, or nginx)?
3. Server configuration directives — do <Directory>, <Location>, or server {} blocks explicitly deny access?
4. .htaccess rules — are there Deny, Require, or Options directives overriding defaults?
5. Application-layer rules — does a CMS plugin, WAF, or security module intercept the request?
6. IP-level blocks — is the requesting IP address on a deny list?

Identifying which layer is responsible cuts your troubleshooting time in half.

Fix 1: Correct File and Directory Permissions

Incorrect UNIX permissions are the single most common cause of 403 errors on shared and VPS hosting environments. The web server process must have at least read (r) permission on files and read + execute (rx) permission on every directory in the path to the requested resource.

Standard permission values:

Critical edge case: If any parent directory in the path lacks execute (x) permission for the server user, every file inside it will return 403 — even if the file itself has correct permissions. Always audit the entire path, not just the target file.

To fix permissions recursively via SSH:

# Fix directory permissions
find /var/www/html -type d -exec chmod 755 {} ;

# Fix file permissions
find /var/www/html -type f -exec chmod 644 {} ;

# Fix ownership (replace www-data with your server user)
chown -R www-data:www-data /var/www/html

To check the effective user your web server runs as:

ps aux | grep -E 'apache|nginx|httpd' | grep -v grep | awk '{print $1}' | sort -u

If you are on a VPS Hosting plan with root access, you can run these commands directly. On shared hosting, use your control panel's File Manager or an FTP client like FileZilla, right-click the file or directory, and select "Change Permissions."

Fix 2: Diagnose and Repair the .htaccess File

Apache reads .htaccess files at every directory level from the web root down to the requested resource. A single malformed directive — or a directive inserted by a security plugin — can block access to an entire section of your site.

Step 1: Isolate whether .htaccess is the cause

Rename the file to disable it temporarily:

mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

Reload the page. If the 403 disappears, the .htaccess file is the culprit.

Step 2: Identify the offending directive

Common .htaccess directives that cause 403 errors:

# Overly broad IP deny rule
Deny from all

# Missing Allow directive paired with Deny
Order deny,allow
Deny from all
# (Allow from all is absent)

# Incorrect Options directive
Options -Indexes -ExecCGI
# This is fine, but the following blocks everything:
Options None

# Require directive blocking all (Apache 2.4+)
Require all denied

Step 3: Generate a clean .htaccess for WordPress

Navigate to Settings > Permalinks in the WordPress dashboard and click Save Changes without modifying anything. WordPress will regenerate a valid .htaccess. The standard WordPress .htaccess looks like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Step 4: Verify AllowOverride in the main server config

If AllowOverride None is set in httpd.conf or a virtual host block, Apache ignores .htaccess files entirely — but some directives may still apply from the main config and conflict with expected behavior.

grep -r "AllowOverride" /etc/apache2/

For .htaccess to function, you need at minimum:

<Directory /var/www/html>
    AllowOverride All
</Directory>

Fix 3: Deactivate WordPress Plugins and Themes

Security plugins (Wordfence, iThemes Security, Sucuri) frequently add IP-based blocking rules, mod_security directives, or custom .htaccess entries that produce 403 errors — sometimes locking out the site owner.

Bulk-deactivate all plugins via FTP or SSH:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

If the error clears, reactivate plugins one at a time by renaming the folder back, then moving individual plugin directories out and in until the offender is identified.

Theme-specific 403 errors are less common but occur when a theme's functions.php hooks into request handling or when a theme enforces login requirements on specific pages. To test, switch to a default WordPress theme (Twenty Twenty-Four) via phpMyAdmin if you cannot access the dashboard:

UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';

Fix 4: Clear Browser Cache and Cookies

Browsers aggressively cache HTTP responses, including error responses. A 403 served once can be cached and replayed even after the underlying issue is resolved. This is especially true when a CDN or reverse proxy (Cloudflare, Varnish) sits in front of your server.

Browser-level fix:

Open your browser's developer tools (F12), navigate to the Network tab, right-click the failing request, and select Clear Browser Cache — or use a hard refresh:

• Windows/Linux: Ctrl + Shift + R
• macOS: Cmd + Shift + R

CDN/proxy-level fix:

If you use Cloudflare, purge the cache for the specific URL from the Cloudflare dashboard under Caching > Cache Purge > Custom Purge.

Important nuance: If the 403 is being served by Cloudflare itself (you will see "Error 1020" or a Cloudflare-branded error page), the block is enforced at the CDN layer via a Firewall Rule or IP reputation block — not by your origin server. Fixing server permissions will have zero effect in this scenario. Check Cloudflare's Security > Events log to confirm.

Fix 5: Review IP Deny Rules and Firewall Blocks

IP-based 403 errors are common when security plugins, fail2ban, or manual iptables rules block a legitimate IP address — including your own.

In cPanel (IP Blocker):

1. Log in to cPanel.
2. Navigate to Security > IP Blocker.
3. Review the blocked IP list and remove any entries that should not be there.

In Apache .htaccess or httpd.conf:

# Apache 2.2 syntax
Order deny,allow
Deny from 203.0.113.45

# Apache 2.4 syntax
<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

Via fail2ban (common on VPS environments):

# List all jails
fail2ban-client status

# Check if your IP is banned in the apache-auth jail
fail2ban-client status apache-auth

# Unban an IP address
fail2ban-client set apache-auth unbanip 203.0.113.45

Via iptables:

# List rules with line numbers
iptables -L INPUT -n --line-numbers

# Remove a specific DROP rule (replace 5 with the actual line number)
iptables -D INPUT 5

On a Dedicated Server where you control the full network stack, always verify both application-level and kernel-level firewall rules before concluding the issue is in your web server config.

Fix 6: Disable or Reconfigure Hotlink Protection

Hotlink protection works by inspecting the HTTP Referer header. If a request arrives with a Referer that is not on the approved list, the server returns 403. This mechanism can misfire in several scenarios:

• Direct URL access — some configurations block requests with no Referer header, which is the case for users typing the URL directly, clicking links in email clients, or using privacy-focused browsers that strip referrer headers.
• HTTPS to HTTP transitions — browsers do not send a Referer header when navigating from an HTTPS page to an HTTP resource, causing hotlink protection to block the request.
• API or script access — programmatic requests often omit the Referer header entirely.

In cPanel (Hotlink Protection):

1. Navigate to Security > Hotlink Protection.
2. Ensure your domain (both http:// and https:// variants) is in the URLs to Allow Access list.
3. If testing, temporarily click Disable and confirm whether the 403 resolves.

In .htaccess directly:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www.)?yourdomain.com/ [NC]
RewriteRule .(jpg|jpeg|png|gif|webp|svg)$ - [F,L]

To allow direct access (empty Referer), remove the line RewriteCond %{HTTP_REFERER} !^$.

Fix 7: Correct Apache or NGINX Server Configuration

When you control the server — as you would on a VPS with cPanel or a bare-metal dedicated instance — misconfigured virtual host or server block directives are a frequent source of 403 errors.

Apache Configuration

Common misconfiguration — missing Require all granted:

In Apache 2.4, the authorization model changed significantly. The old Allow from all directive is deprecated. Without an explicit Require statement, Apache denies access by default.

<VirtualHost *:80>
    ServerName yourdomain.com
    DocumentRoot /var/www/html

    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Check for Options -Indexes: This directive prevents directory listing (returning 403 when no index file exists). If a directory has no index.html or index.php, Apache returns 403. This is intentional security behavior — but if you expect a directory listing, add Options +Indexes.

Verify your config and restart:

apachectl configtest
systemctl reload apache2

NGINX Configuration

Common misconfiguration — incorrect root path or missing index:

server {
    listen 80;
    server_name yourdomain.com;
    root /var/www/html;
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

If the root directive points to a path that does not exist or that the nginx process user cannot read, every request returns 403.

Check NGINX error logs for the exact cause:

tail -n 50 /var/log/nginx/error.log

A 403 from NGINX almost always produces a log entry like:

2024/01/15 10:23:45 [error] 1234#0: *1 "/var/www/html/index.html" is forbidden (13: Permission denied)

Error code 13 means Permission denied at the OS level — go back to Fix 1 and audit filesystem permissions and ownership.

Test and reload NGINX:

nginx -t
systemctl reload nginx

Apache vs. NGINX: 403 Troubleshooting Comparison

Fix 8: Audit SSL Certificate and HTTPS Redirect Configuration

This fix is absent from most 403 guides, yet it is a genuine and frequently overlooked cause. Misconfigured SSL redirect rules can produce 403 errors in specific scenarios.

Scenario 1: Forcing HTTPS before the certificate is valid

If an .htaccess redirect forces all traffic to HTTPS but the SSL certificate is not yet provisioned or has expired, some server configurations return 403 rather than a certificate error.

# Problematic if SSL is not configured on the server
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Verify your certificate is active and properly installed before enforcing HTTPS redirects.

Scenario 2: mod_ssl client certificate requirement

If your Apache configuration requires client-side SSL certificates for authentication and the browser does not present one, Apache returns 403:

<Directory /var/www/secure>
    SSLVerifyClient require
    SSLVerifyDepth 1
</Directory>

Unless you intentionally implemented mutual TLS (mTLS), remove or set SSLVerifyClient none.

Scenario 3: HSTS preload with incorrect redirect chain

A redirect loop caused by conflicting HSTS headers and HTTP-to-HTTPS rules can manifest as a 403 in certain browser/proxy combinations. Inspect the full redirect chain with:

curl -I -L --max-redirs 10 http://yourdomain.com

Systematic Diagnosis: Reading Your Error Logs

Every fix above should be paired with real-time log monitoring. Guessing without reading logs wastes time.

Apache — watch the error log live:

tail -f /var/log/apache2/error.log | grep 403

NGINX — watch the error log live:

tail -f /var/log/nginx/error.log | grep 403

cPanel environments — access logs via:

tail -f /usr/local/apache/logs/error_log

The log entry will almost always tell you exactly which file triggered the 403 and why — permission denied, missing index, or an explicit deny rule.

Decision Matrix: Choosing the Right Fix

Use this matrix to identify the most likely fix based on your symptoms:

Key Technical Takeaways

• Always read the server error log first — it pinpoints the exact file and reason for the 403 in seconds.
• On Apache 2.4+, Require all granted is mandatory in every <Directory> block. Omitting it is the most common cause of 403 on fresh server setups.
• File permissions alone are insufficient — ownership must match the web server process user (www-data, apache, nginx).
• A 403 served by a CDN (Cloudflare, Fastly) is entirely separate from a 403 served by your origin server. Fixing one has no effect on the other.
• On WordPress sites, always test with plugins bulk-disabled before spending time on server-level diagnosis.
• If you manage your own infrastructure on a VPS or Dedicated Server, keep fail2ban logs and iptables rules in scope — they operate below the web server layer and are invisible to application-level debugging tools.
• Hotlink protection rules that block empty Referer headers will affect legitimate users on privacy browsers and email link clicks — always include an exception for blank referrers.

FAQ

What is the difference between a 403 Forbidden error and a 401 Unauthorized error?

A 401 Unauthorized error means the server requires authentication and the client has not provided valid credentials — re-authenticating may resolve it. A 403 Forbidden means the server has identified who you are (or does not require authentication) but explicitly refuses access regardless. Providing credentials will not help with a 403.

Can a 403 error affect my website's SEO rankings?

Yes. If Googlebot receives a 403 when crawling a page, it cannot index that page. Persistent 403 errors on important URLs will cause them to drop from search results. Use Google Search Console's URL Inspection tool to check whether Googlebot can access your pages, and monitor the Coverage report for 403-related crawl errors.

Why do I get a 403 error only on specific file types (images, PDFs)?

This almost always points to hotlink protection (Fix 6) or a MIME-type-specific rule in .htaccess. Check for FilesMatch or RewriteRule directives that target specific extensions. Also verify that the directory containing those files has 755 permissions and is owned by the correct server user.

How do I fix a 403 error if I do not have SSH or FTP access?

Use your hosting provider's web-based File Manager (available in cPanel, Plesk, or DirectAdmin) to inspect and modify file permissions and .htaccess files. For WordPress-specific issues, the WP-CLI tool (if available via your control panel's terminal) or direct database access via phpMyAdmin can help deactivate plugins and switch themes without SSH.

Does a 403 error mean my website has been hacked?

Not necessarily, but it can be a symptom. Malware sometimes injects deny rules into .htaccess files or modifies file permissions to prevent access. If you cannot identify a configuration-based cause for the 403, scan your files for unauthorized modifications using a tool like rkhunter, Wordfence (if you can access WordPress), or your hosting provider's malware scanner. Compare file hashes against known-good backups if available.