Fixing 403 Forbidden Errors

What a 403 actually tells you

A 403 is a decision, not a crash. The server received the request, knew what was being asked for and chose not to serve it. That makes it different from its neighbours:

Because a 403 is a deliberate refusal, the fix is always to find the rule or setting that made the decision. Almost every 403 comes from one of five layers, and each has its own tell-tale sign:

1. The file system. The web server process is not allowed to read the file or enter the folder. Every file under that folder usually fails the same way.
2. The web server configuration. A Require, Deny or deny directive, or a folder with no index file and directory listing turned off.
3. The application. WordPress, Laravel or a similar app returns 403 itself, often for a failed security token, a blocked user role or a plugin rule.
4. A web application firewall. ModSecurity, Imunify360, Wordfence or similar rules match something in the request, such as a query string or user agent.
5. The CDN or edge. Cloudflare, a load balancer or a hosting firewall blocks the request before it reaches your server at all.

Working from the outside in, starting with the CDN and ending with the file system, is quicker than guessing, because the outer layers leave obvious fingerprints in the response.

Finding the layer that refused

Start with the response itself. Request the failing URL from a terminal and look at the headers and the body, not just the status code.

curl -sI https://www.example.co.uk/brochure/price-list.pdf
curl -s https://www.example.co.uk/brochure/price-list.pdf | head -30

• A server: cloudflare header with a cf-ray value, and a Cloudflare-branded body, means the edge blocked it. Look in the Cloudflare security events for that Ray ID.
• A body mentioning ModSecurity, Imunify360, a hosting provider's firewall, or a reference number, points to a web application firewall on the server.
• A plain page reading "You don't have permission to access this resource" is the standard Apache refusal. It comes from the configuration or the file system.
• A page styled like your own site, with your header and footer, came from the application.

Then check whether the refusal depends on who is asking. Many 403s in an audit only happen to automated clients.

# As a normal browser
curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://www.example.co.uk/services/
# As a bare script
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.co.uk/services/
# Claiming to be Googlebot
curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://www.example.co.uk/services/

If the browser string gets 200 and the others get 403, a bot rule is responsible. Note that a request claiming to be Googlebot from your own machine is often blocked on purpose, because good firewalls verify that Googlebot really comes from Google. That is correct behaviour, so test from the crawler's point of view with the URL Inspection tool in Search Console instead.

Log lines worth recognising

If the web server log has no entry at all for the request, it never reached the server and the block is upstream, at the CDN, the load balancer or a network firewall.

Permissions and ownership

On Linux hosting, the web server runs as a particular user, and it can only serve files that user is allowed to read. It also needs the execute bit on every folder along the path, which is what allows a process to pass through a folder. A single parent folder set to 700 can make everything beneath it forbidden.

A common and safe starting point for a typical PHP site is folders at 755 and files at 644, with the files owned by the site's own user. Some managed hosts use tighter settings, such as 750 on the web root with a shared group, so follow your host's documentation where it differs.

# Show the permissions on every folder from the root down to the file
namei -l /var/www/example/public/brochure/price-list.pdf

# Reset folders to 755 and files to 644 inside the web root
find /var/www/example/public -type d -exec chmod 755 {} +
find /var/www/example/public -type f -exec chmod 644 {} +

# Give the files back to the site user if an upload or root copy changed them
chown -R exampleuser:examplegroup /var/www/example/public

• Files uploaded as root. Files copied in over SSH as the root user, or extracted from an archive, often end up owned by root with restrictive modes. The folder listing looks fine but the web server cannot open the files.
• Configuration files you want private. A file such as wp-config.php or .env may deliberately be tighter, for example 600 or 640. That is fine as long as the PHP process still runs as a user that can read it.
• SELinux. On servers with SELinux enforcing, correct Unix permissions are not enough; the files also need the right security context. If ls -Z shows an unexpected type on files you moved into the web root, restorecon -R on that folder usually resolves it.
• Symbolic links. Apache only follows links when Options FollowSymLinks or SymLinksIfOwnerMatch allows it, and the second option refuses links whose target has a different owner.

Configuration rules that refuse requests

Access rules are meant to refuse some requests. The problem is a rule that matches more than intended. Look for these patterns in the server configuration and in every .htaccess file from the web root down to the failing folder, because Apache applies them all.

# Apache 2.4: refuses everything in this folder and below
Require all denied

# Older Apache 2.2 syntax that still appears in copied snippets
Order deny,allow
Deny from all

# A narrow rule that only protects dotfiles such as .env and .git
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

A Deny from all block copied into the wrong folder, such as an uploads folder that also holds public PDFs, will forbid every file in it. Mixing the old Order and Deny syntax with the Apache 2.4 Require syntax in the same place can also behave in surprising ways, so rewrite older snippets in the 2.4 form.

The nginx equivalents live in the server block. A location that is too broad, such as one meant to hide dotfiles, can catch real pages:

# Too broad: any path containing a dot after a slash, including /.well-known/
location ~ /\. { deny all; }

# Better: keep /.well-known/ open for certificate checks and similar files
location ^~ /.well-known/ { allow all; }
location ~ /\.(?!well-known) { deny all; }

Folders with no index file

If someone visits /services/ and there is no index.html or index.php in that folder, the server can either list the files or refuse. On most hosts listing is turned off, so the visitor gets a 403. The fix is to add an index file, to point the link at the real page, or to add a redirect. Do not turn directory listing back on to make the error go away; it exposes every file in the folder.

Hotlink protection and referrer rules

Rules that block images or files unless the referrer is your own domain will return 403 to anyone who opens the file directly, to social networks building previews and to search engine image crawlers. Allow empty referrers and the crawlers you care about, or remove the rule if bandwidth is not a real concern.

Firewalls, bot protection and crawlers

Web application firewalls block requests that look like attacks. They are useful, but generic rule sets are cautious and sometimes refuse normal traffic. Typical false positives include search pages with unusual characters in the query string, form posts containing code snippets or HTML, long tracking parameters and uncommon user agents.

• ModSecurity. Find the rule id in the error log or audit log, then disable that single rule for the affected path rather than turning ModSecurity off for the whole site.
• Security plugins. Wordfence, Solid Security and similar plugins keep their own block logs and country or rate rules. A crawler that requests many pages quickly can be blocked for a period by rate limits meant for attackers.
• Cloudflare and other CDNs. Bot Fight Mode, custom WAF rules and country blocks all return 403 before the request reaches you. The security events log shows which rule matched.
• Hosting firewalls. Some hosts run their own firewall in front of shared servers. If there is no trace anywhere you can see, send your host the URL, the time and your audit's IP address and ask them to check.

Why this matters for search

Google does not index a URL that returns 403, and a site-wide 403 for Googlebot looks like the whole site has disappeared. Google also advises against using 403 or 404 to slow its crawling; if you need to reduce crawl load temporarily, it recommends 429 or 503 responses, which it treats as a signal to back off rather than as a refusal. Allow verified search engine crawlers by checking reverse DNS or the IP ranges they publish, not by trusting the user agent, which anyone can fake.

The fix, step by step

Platform notes

• WordPress. A 403 on /wp-admin/ or when saving a post is often a security plugin or ModSecurity reacting to the content being saved. A 403 on every page after a plugin install usually means the plugin wrote rules into .htaccess. The WordPress HTTP errors guide covers plugin conflicts in more detail.
• Plesk and cPanel. Both panels can reset permissions and both show ModSecurity hits in their own interfaces. The Plesk and cPanel guide explains where those tools live.
• Static hosts and object storage. A 403 from a storage bucket or static host usually means the object is not public, or the address points at a folder with no index document configured. Many of these services return 403 rather than 404 for missing files, so check that the file really exists.
• Frameworks. Laravel, Django and Rails return 403 for failed CSRF checks and authorisation policies. These appear in the application log, not the web server log, and usually affect form submissions rather than page views.

Keeping 403s from coming back

• Deploy with the right user. Upload and deploy as the site user, not root, so ownership stays consistent. If a deploy script must run as root, have it reset ownership at the end.
• Keep access rules in one place. Scattered .htaccess files in many folders are hard to review. Collect rules in the main configuration or one top-level file where possible, with a comment explaining each.
• Review firewall changes. When you add a bot or country rule, test it immediately against a normal browser, Googlebot through URL Inspection, and your own monitoring tools.
• Watch for 403 spikes. A sudden rise in 403s in the access log, especially for search engine user agents, usually follows a plugin update or a new firewall rule. Catching it the same day avoids pages dropping out of the index.
• Audit after changes. Re-run the HTTP Error Audit after security changes, server moves and plugin updates, not only when something looks wrong.