How to Fix a 403 Forbidden Error

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

A 403 Forbidden error means the server, CDN, web application firewall, API gateway, or object-storage service understood your request but refused to fulfill it. Repeating the same request usually will not help: the URL, credentials, IP address, request method, or server policy must change.

If you are only visiting a website, you can test your browser, account, VPN, and network, then give the site owner useful evidence. If you own the site or API, identify which layer returned the response before changing permissions or disabling security controls.

First, decide which situation applies

• I am visiting someone else’s website: troubleshoot your session, account, IP address, VPN, and network. You generally cannot repair a server-side authorization rule yourself.
• I operate the website, server, API, CDN, or storage: capture the response, identify the component that generated it, determine the failure’s scope, and change only the responsible rule or permission.

The most important rule is: identify the issuer before changing permissions. A 403 is not automatically a Unix file-permission problem.

What does 403 Forbidden mean?

HTTP status 403 Forbidden indicates that the server understood the request but refuses to authorize it. The response can come from the origin web server, an application, a CDN or WAF, an API gateway, IIS, Amazon S3, or another intermediary. The HTTP specification also permits a server to return 404 Not Found instead when it does not want to reveal that a protected resource exists. See RFC 9110 for the formal definitions.

Authentication answers “Who are you?” Authorization answers “Are you allowed to do this?” A 401 Unauthorized response generally means that authentication is missing, invalid, or expired and should normally include a WWW-Authenticate header. A 403 generally means the request is not permitted under the applicable policy. In practice, sites also use 403 for anonymous access blocks, IP restrictions, WAF decisions, CSRF failures, suspended accounts, and other application-specific denials. A 403 therefore does not prove that the user successfully authenticated. See MDN’s 401 reference and 403 reference.

For OAuth bearer tokens, an invalid or expired token normally produces 401, while a valid token that lacks the required privilege can produce 403 with error='insufficient_scope'. That distinction is defined in RFC 6750.

The page text—“Forbidden,” “Access denied,” or “You don’t have permission”—is less useful than the response headers, body, request ID, and server or security logs. A branded error page may identify the product that blocked the request; a plain page may have come from the origin.

Quick fixes for visitors

Try these in order, starting with the least disruptive checks. These steps can isolate a local problem, but they cannot override a genuine server policy.

1. Check the URL and try a public page

• Remove accidental spaces, malformed encoding, obsolete query parameters, or a copied private or administrative path.
• Open the site homepage or another known-public page.
• If the homepage works but one deep link returns 403, the restriction may be intentional, path-specific, or related to that resource.
• If the address ends in /, try the intended public file or application route only if you know it. A directory URL may require an index document and may intentionally prohibit directory listing.

2. Sign in or sign out appropriately

A logged-in account may not have the required role, subscription, organization membership, or resource permission. Conversely, a stale session cookie can cause a public page to be treated as a restricted request.

• If the page requires an account, sign in with the correct account.
• If the site should be public, try a private window or sign out to test anonymous access.
• Do not assume that refreshing an unchanged session will grant a missing role.

3. Test a private window or another browser

This separates cookies, extensions, cached application state, and browser-specific behavior from a server-side rule. If every browser receives the same 403, the problem is less likely to be a browser extension or cached page.

4. Temporarily disable a VPN, proxy, privacy relay, or corporate filter

A site’s WAF may block a VPN exit address, hosting-provider ASN, corporate proxy, country, or suspicious request pattern. Test without the intermediary if it is safe and permitted. Do not install an unknown browser extension or “VPN bypass” tool to evade a security control.

5. Try another network

Test mobile data instead of home Wi-Fi, or use another trusted connection. If the site works on mobile data but not at home, likely causes include an IP block, firewall rule, IP-reputation decision, IPv6-specific configuration, or a corporate network policy—not browser file permissions.

6. Find out whether everyone is affected

Ask a trusted person on a different network to test the same public URL. A public outage-reporting service may provide additional context, but never disclose private URLs, cookies, API keys, or credentials.

7. Contact the site owner

Include the following information:

• The exact URL and, if relevant, the action you were performing.
• The date and time, including your time zone.
• A screenshot or the exact response text.
• Whether private browsing, another browser, another account, or another network changed the result.
• Any request ID, error code, or Cloudflare Ray ID shown on the page.
• Your public IP address only if the owner requests it through a trusted support channel.

Clearing all cookies, flushing DNS, and repeatedly refreshing may help isolate a session or routing issue, but none of these actions can override a server authorization rule.

Identify who returned the 403

Before changing configuration, compare the response body and headers. Look for branding, a Server header, Via, CF-Ray, a vendor request ID, or an application-specific error format. A Cloudflare-branded page or Cloudflare Ray ID points to Cloudflare’s edge layer; plain Nginx or Apache wording often points to the origin, although an application behind that server may still be responsible.

Using a browser

1. Open the browser’s developer tools.
2. Select the Network panel.
3. Reload the failing page or repeat the failing action.
4. Open the request with status 403.
5. Review the request method, URL, redirect chain, response headers, response body, cookies, and timing.

Pay attention to whether the browser is reporting an actual HTTP 403 or only a CORS-related message. CORS and HTTP authorization are separate observations: inspect the network response before concluding that CORS caused the denial.

Using curl

These commands are useful for comparing browser and non-browser requests:

curl -sS -D - -o /dev/null https://example.com/path

This prints response headers without printing the body.

curl -sS -D /tmp/headers.txt -o /tmp/body.html https://example.com/path

This saves the headers and response body for inspection.

curl -v https://example.com/path

Verbose mode shows connection details, TLS information, redirects, and request and response headers.

curl -IL https://example.com/path

This follows redirects while requesting headers only. However, curl -I sends a HEAD request, and some servers or WAFs treat HEAD differently from GET. A HEAD-only 403 is not conclusive; test the normal GET request as well. See curl’s HTTP scripting documentation.

Never paste authorization headers, cookies, signed URLs, API tokens, or personal information into a public bug report. Redact them before sharing diagnostic output.

Website-owner diagnostic flow

Step 1: Preserve evidence

Before changing a rule, record:

• URL, HTTP method, query string, and request body type.
• Request time and time zone.
• Affected account, IP address, region, and user agent.
• Status code, response body, response headers, and request ID.
• Whether the failure is global or selective.
• Recent deployments, plugin updates, firewall or WAF changes, DNS changes, certificate changes, or filesystem-permission changes.

Step 2: Determine the scope

Compare the failing request with controlled variations:

• Homepage versus the failing path.
• Static file versus dynamic route.
• Anonymous versus authenticated request.
• One account versus another account.
• One IP or network versus another.
• GET versus the method that actually fails.
• IPv4 versus IPv6, if both are available.
• CDN URL versus the origin, using an authorized and controlled test.
• Browser versus curl.

Pattern	Likely direction
Everything fails	Virtual-host selection, wrong origin, global WAF or server rule, document-root access, or site-wide application failure.
Only one path fails	Path rule, missing index, directory permission, route authorization, or object policy.
Only one user fails	Account role, session, token scope, IP reputation, or a security rule associated with that user.
Only one method fails	Method authorization, CSRF protection, API policy, or proxy/WAF behavior.
Only the CDN path fails	Edge rule, cached response, origin allowlist, or incorrect client-IP handling.
Only the origin fails	Web-server configuration, filesystem, application, or operating-system policy.

Step 3: Inspect the layer that generated the response

Check the log that corresponds to the issuer. Typical Linux paths include:

# Nginx
sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log

# Debian/Ubuntu Apache
sudo tail -f /var/log/apache2/error.log

# RHEL/Fedora Apache
sudo tail -f /var/log/httpd/error_log

These paths are distribution and configuration dependent. Inspect the configured Nginx error_log or Apache ErrorLog directive rather than assuming a particular filename. Apache specifically recommends using its error log to locate messages such as client denied by server configuration; see the Apache security guidance and Apache access-control documentation.

Check Linux permissions, ownership, ACLs, and mandatory access controls

For a file served directly by a Unix-like web server, the service account generally needs:

• Read permission on the requested file.
• Search or execute permission on every directory in the path.
• Suitable ownership or group membership.
• Access permitted by any filesystem ACL.

Directory x permission means the ability to search or traverse the directory. Missing it on any parent directory can prevent access even when the final file appears readable. The behavior is described in Linux’s path_resolution(7).

Trace every component of a path:

namei -l /var/www/example/public/path/file.html
stat -c '%A %a %U:%G %n' /var/www/example/public/path/file.html
ls -ld /var /var/www /var/www/example /var/www/example/public

Test as the actual web-server account, replacing www-data with the account used by your deployment:

sudo -u www-data test -r /var/www/example/public/path/file.html && echo 'readable' || echo 'not readable'

For a conventional WordPress installation, WordPress documents 0755 for directories and 0644 for files as a common baseline. This is not universal: hosting models, deployment users, ACLs, containers, shared groups, and writable upload or cache directories may require different settings.

A narrowly scoped baseline command for an ordinary static-content or WordPress tree is:

find /path/to/site -type d -exec chmod 755 {} +
find /path/to/site -type f -exec chmod 644 {} +

Do not run this blindly. Exclude secrets, sockets, virtual environments, uploads with special requirements, shared hosting trees, and files that need executable or restricted modes. Do not use chmod -R 777, and do not recursively change ownership to www-data, apache, or nginx without understanding the service-account and deployment model. Making a page load by making the entire site writable can create a serious vulnerability.

SELinux, AppArmor, and ACLs

SELinux can deny a web process even when ordinary mode bits look correct. On an SELinux-enabled system, investigate the policy rather than disabling it:

getenforce
sudo ausearch -m AVC -ts recent
sudo sealert -l '*'

For content outside a standard web root, Red Hat documents comparing and restoring labels. The exact path and policy determine the correct command:

matchpathcon /var/www/html /var/test_www/html
sudo semanage fcontext -a -e /var/www /var/test_www
sudo restorecon -Rv /var/test_www

Use the Red Hat SELinux troubleshooting guide for the appropriate policy-specific procedure. AppArmor, filesystem ACLs, NFS permissions, containers, and symlink policies can create analogous denials.

Missing index files and directory listing

A URL ending in / commonly asks the server to process a directory. Depending on configuration, it may:

• Serve index.html, index.php, or another default document.
• Route the request to an application.
• Generate a directory listing if explicitly enabled.
• Return 403 if no index exists and directory listing is disabled.

On Apache, DirectoryIndex controls index-file lookup, while automatic directory listing is separately controlled through Options +Indexes. On Nginx, the index directive controls slash-terminated directory requests:

location / {
    root /var/www/example/public;
    index index.html index.php;
}

Nginx documents that index processing can perform an internal redirect, so a directory request may ultimately be handled by a different location block. Check the Nginx index module.

The preferred fix is to deploy the intended index file, correct the document root, or configure the application fallback. Do not enable directory browsing merely to eliminate a 403: listings can expose backups, source code, configuration files, and private uploads.

Fix Apache 403 errors

Validate and inspect the effective Apache configuration:

sudo apachectl -t
sudo apachectl -S

Check the selected virtual host, document root, and these possible denial sources:

• .htaccess.
• <Directory>, <Files>, and <FilesMatch> blocks.
• Require all denied, Require ip, Require host, and combined <RequireAll> rules.
• mod_rewrite rules using the [F] flag.
• ModSecurity or another WAF.
• Filesystem, ACL, and SELinux access.
• A custom ErrorDocument 403 that is itself inaccessible.

Apache 2.4 uses Require authorization directives. Older tutorials using Order, Allow, and Deny rely on compatibility behavior and should not be copied into a new configuration without understanding the version and module in use. Apache’s access-control guide explains the current model.

A rewrite rule can deliberately return 403:

RewriteRule '^/private' '-' [F]

The [F] flag means “forbidden”; see Apache’s rewrite flags documentation.

To test whether .htaccess is responsible, back it up and disable it for one controlled request:

cp .htaccess .htaccess.backup
mv .htaccess .htaccess.disabled

Restore it immediately after testing. If the 403 disappears, reintroduce rules incrementally or regenerate only the intended framework rules. Do not permanently remove authentication, upload protection, sensitive-file blocks, or other security rules just because the page loads.

For a public document root, a narrowly scoped authorization block may be appropriate:

<Directory '/var/www/example/public'>
    Require all granted
</Directory>

Do not apply such a rule broadly to the filesystem root, private directories, configuration files, or administrative paths.

Fix Nginx 403 errors

Validate and dump the effective configuration, including included files:

sudo nginx -t
sudo nginx -T > /tmp/nginx-effective.conf
grep -nEi 'deny|return 403|auth_basic|root|alias|try_files|index|limit_except|disable_symlinks' /tmp/nginx-effective.conf

Review:

• deny all; and IP or CIDR restrictions.
• return 403; rules.
• auth_basic or authentication subrequests.
• limit_except blocks.
• root versus alias path construction.
• Incorrect try_files fallbacks.
• Missing index files.
• disable_symlinks restrictions.
• The location block actually selected for the request.
• Filesystem traversal and read access for the Nginx worker account.

Nginx documents these as separate mechanisms in its core module, rewrite module, and index module. A plain Nginx-branded 403 therefore does not by itself identify the exact cause.

After making a verified, narrowly scoped change:

sudo nginx -t && sudo systemctl reload nginx

Reload rather than restart where possible, then verify with both the original browser request and a normal GET using curl.

Fix IIS 403 errors using the substatus code

IIS commonly provides a more specific substatus code. Find it in the IIS logs or detailed error page.

Code	Typical meaning	What to check
403.6	IP address rejected	IIS Manager → IP Address and Domain Restrictions; check explicit denies and allowlist mode.
403.9	Too many users or connections on certain Windows client editions	Connection limits and edition-specific restrictions.
403.14	Directory listing denied and no usable default document	Deployment folder, published files, default document, application fallback, and web.config.
403.16	Client certificate is invalid or untrusted	Certificate chain, trusted root store, expiration, and IIS client-certificate settings.

For 403.6, IIS may deny listed IPs or deny all clients not present in an allowlist. For ASP.NET Core deployments, Microsoft identifies wrong deployment folders, missing published files, and missing or malformed web.config as common contributors to 403.14. For 403.16, inspect the client certificate’s trust chain and IIS configuration.

Do not confuse every IIS filtering problem with 403. IIS Request Filtering commonly produces 404.x substatus codes for denied verbs, hidden segments, blocked extensions, and URL filtering. See Microsoft’s Request Filtering documentation.

Fix Cloudflare, CDN, and WAF 403 errors

A Cloudflare-branded page, Cloudflare error code, or cf-ray header usually means the edge layer generated or participated in the response. Cloudflare explains that an unbranded 403 generally came from the origin, while Cloudflare can generate branded 403 responses through WAF rules, security level, DDoS protection, Browser Integrity Check, bot controls, validation, and related products. See Cloudflare’s 403 documentation.

1. Record the Cloudflare Ray ID and exact timestamp.
2. Open the zone’s Security Events and locate the request.
3. Identify the matched control: WAF managed rule, WAF custom rule, IP Access rule, Security Level, Browser Integrity Check, bot protection, Zone Lockdown, hotlink protection, or another product.
4. Check whether the rule matched the path, IP, country, ASN, user agent, method, query string, or request body.
5. Narrow or correct the rule, then retest the original request.
6. Check that the origin is not blocking Cloudflare’s published IP ranges and that the origin is recording the real visitor IP correctly.

Cloudflare custom-rule block actions commonly return 403. Current Cloudflare documentation recommends custom rules for newer IP and geographic policies rather than relying on older firewall-rule terminology; see custom rules, IP Access Rules, and the firewall-rule migration guidance.

Do not make “allow my IP globally” the default fix. Cloudflare warns that a global allow can bypass multiple security products. Prefer a narrow, temporary, purpose-specific exception limited to the affected path or rule, and remove it after testing. See Cloudflare’s rule-action guidance.

Disabling a CDN can help isolate edge and origin behavior, but it may expose the origin to attacks, alter TLS behavior, bypass caching, and produce misleading results. Prefer a controlled origin test, request-ID comparison, or temporary narrow bypass.

WordPress-specific 403 troubleshooting

WordPress is one possible application behind a 403, not the universal explanation. Use this branch when the site is actually running WordPress:

1. Determine whether all visitors are blocked or only administrators, logged-in users, REST requests, admin-ajax.php, uploads, or login requests.
2. Review recently installed or updated security, firewall, caching, membership, image-protection, or optimization plugins.
3. If the dashboard is available, temporarily disable plugins one at a time. Otherwise, rename the plugins directory through SFTP or the hosting file manager as a controlled test.
4. Back up and temporarily rename .htaccess. Test once, then restore it.
5. If the rewrite rules are the cause, regenerate the intended rules through Settings → Permalinks after restoring appropriate backups and security protections.
6. Check file ownership, directory traversal, standard permissions, hosting ModSecurity rules, CDN events, and application logs.
7. Check whether a security plugin blocked the current IP or country.
8. If rules changed unexpectedly or unknown files or users appeared, scan for malware and investigate the account.

WordPress-specific guidance commonly recommends testing plugins and regenerating .htaccess. Those are diagnostic steps, not substitutes for identifying whether WordPress, Apache, the host, or the CDN actually returned the response. WordPress’s own file-permission guidance also warns that the correct settings depend on the hosting model.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

API 403 errors: roles, scopes, and request policy

For an API, inspect the response body and headers instead of automatically refreshing the token:

curl -i 
  -H 'Authorization: Bearer REDACTED_TOKEN' 
  https://api.example.com/resource

Check for:

• WWW-Authenticate.
• error='insufficient_scope'.
• The required role or scope.
• A vendor request ID and application error code.
• The intended environment, tenant, organization, audience, and resource identifier.
• Account suspension, IP allowlists, organization policy, or environment restrictions.

Missing, invalid, or expired credentials usually produce 401. Valid credentials lacking a role or scope often produce 403. CSRF checks may also produce an application-specific 403. An unsupported method should normally produce 405 with an Allow header, although imperfect APIs sometimes return 403. Rate limiting is normally 429, but some providers use 403 or a vendor-specific body. Refresh a token for an invalid or expired-token response; insufficient scope generally requires a new authorization grant or changed permissions.

Amazon S3 and CloudFront AccessDenied responses

S3’s AccessDenied is an object-storage authorization problem, not necessarily a web-server permission problem. Check:

• Explicit Deny statements in IAM or bucket policies.
• A missing Allow.
• Object ownership and ACL configuration.
• Account-, bucket-, or access-point-level Block Public Access settings.
• KMS key permissions for encrypted objects.
• Requester Pays.
• VPC endpoint policies and AWS Organizations policies.
• S3 access-point network origin.
• CloudFront Origin Access Control or Origin Access Identity.
• The correct S3 website endpoint versus REST endpoint for static website hosting.

AWS documents both explicit and implicit authorization denials and provides a detailed S3 403 troubleshooting checklist. Do not disable S3 Block Public Access as a generic fix; review the intended access model first.

For a Requester Pays bucket, the requester must identify that they will pay the request charge:

aws s3 cp s3://example-bucket/object.txt ./object.txt 
  --request-payer requester

AWS explains this case in its Requester Pays documentation.

Important edge cases

DNS points to the wrong server

DNS does not itself generate an HTTP 403. An incorrect or stale A or AAAA record can route the request to a different server, and that server may return its own 403. Check the destination as a routing-to-the-wrong-policy problem:

dig +short A example.com
dig +short AAAA example.com

If you know the authorized origin IP, compare it carefully without changing public DNS:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/path

Use --resolve only with an authorized origin and a valid TLS setup. Bypassing a CDN can expose infrastructure and should be a controlled operator test.

IPv4 and IPv6 behave differently

A site can work over IPv4 but fail over IPv6 when the AAAA record points to another host, the IPv6 firewall has a different allowlist, the origin is not configured for CDN IPv6 traffic, or the application sees a different client address. This is a valuable explanation for “works on mobile data but not home Wi-Fi” reports.

Proxy and real-client-IP mistakes

Behind a CDN or reverse proxy, the origin may accidentally block the proxy’s address instead of the visitor’s address. The opposite mistake—trusting arbitrary X-Forwarded-For headers—allows clients to spoof their identity. Configure the provider’s documented trusted proxy ranges and the appropriate real-IP module; do not trust every forwarded header by default.

Error-document loops

A custom 403 page can itself be inaccessible, creating a secondary error or misleading body. Verify that the configured error document is readable or internally routable and does not match the same denying rule. Apache documents ErrorDocument in its core module; Nginx documents error_page in its core module.

Intentional 403 responses

Some 403s are correct and should remain in place: private administration pages, disabled directory listings, protected .env files and backups, IP allowlists, geographic restrictions, anti-hotlink rules, WAF blocks for malicious-looking requests, insufficient API roles, and private S3 objects. The objective is not to eliminate every 403; it is to distinguish an intended denial from a false positive or broken deployment.

403 versus similar HTTP errors

Status	Usually means	Typical next step
401	Authentication is missing, invalid, or expired.	Authenticate or correct the credential; inspect WWW-Authenticate.
403	The request is not permitted by the applicable policy.	Check role, scope, account state, IP, path, WAF, object policy, or permissions.
404	The resource is unavailable, or the server is deliberately concealing it.	Verify the path, routing, deployment, and intended privacy behavior.
405	The method is recognized but not allowed for that resource.	Check the Allow header and endpoint method.
429	Rate limit or quota exceeded.	Reduce request rate and inspect quota or retry headers.
451	Access is restricted for legal reasons.	Contact the provider or rights administrator.

HTTP defines 405 as Method Not Allowed and uses the Allow header to advertise supported methods. See RFC 9110.

Verify the fix safely

1. Repeat the exact URL, method, account, headers, and request conditions that originally failed.
2. Test anonymous and authorized access separately.
3. Test from the previously blocked network or IP where appropriate.
4. Check access, application, WAF, CDN, or S3 logs for the successful response and absence of a new security error.
5. Compare the response headers and request ID to confirm that the request is reaching the intended layer.
6. Purge or invalidate CDN cache only after confirming that the origin and policy are correct; a cache purge cannot repair an active denial rule.
7. Confirm that authentication, private-path protection, directory-listing restrictions, and other security controls remain enabled.
8. Add a staging smoke test or monitoring check for the affected public path or API method.

Prevent future 403 errors

• Use least-privilege filesystem, IAM, application, and WAF policies.
• Document the web-server service account, deployment ownership, writable directories, and required ACLs.
• Run staging smoke tests after deployments, plugin updates, virtual-host changes, and CDN rule changes.
• Keep WAF exceptions narrow, logged, time-limited, and tied to a documented reason.
• Configure trusted proxy and real-client-IP handling correctly.
• Monitor sudden increases in 403 responses by path, account, country, ASN, IP, method, and user agent.
• Keep directory listings disabled unless there is a deliberate, reviewed reason to expose them.
• Never make an entire application tree world-writable just to resolve an access error.
• Maintain tested backups and a rollback plan for configuration, plugin, DNS, and deployment changes.

Frequently Asked Questions

Can clearing my browser cache fix a 403 Forbidden error?

It can help isolate a stale session, cookie, or cached application state, but it cannot override a server, WAF, account, or IP-access policy. Test a private window and another network before assuming the cache is responsible.

Should I change the website’s permissions to 777?

No. 777 makes files and directories broadly writable and can create a serious security vulnerability. Check the web-server account, parent-directory traversal, ownership, ACLs, SELinux or AppArmor, and the specific file or directory instead.

Why does a website work on mobile data but not Wi-Fi?

The home or office public IP, IPv6 path, firewall, proxy, or network reputation rule may be blocked. Compare IPv4 and IPv6 and provide the site owner with the time, URL, and any request ID rather than repeatedly refreshing.

Is a 403 always caused by bad file permissions?

No. Common causes include application roles, expired or insufficient API credentials, Apache or Nginx rules, IIS restrictions, CDN/WAF decisions, S3 policies, missing index files, directory-listing settings, and operating-system security policies.

Does a 403 mean the user is logged in?

No. Although 403 often represents an authorization decision, sites can return it for blocked anonymous requests, IP restrictions, WAF rules, CSRF checks, account state, or other policies. A 401 more generally indicates missing or invalid authentication.

The Bottom Line

A 403 Forbidden error is an access-policy decision, not a generic connectivity failure. Visitors should isolate browser, account, VPN, and network causes and then contact the site owner. Operators should capture the exact response, identify whether it came from the application, web server, CDN/WAF, storage service, or operating system, and make the smallest safe policy or permission change needed.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.