A 403 Forbidden error means the website has received your request but will not let you continue. The page may exist and you may even be logged in, but a rule says you are not allowed to access it.
That rule might belong to the website, the hosting platform or a security service. The important first step is finding the rule-not turning off every security feature until the page loads.
This article is part of our Common Web Server Errors Explained series.
The short version
If only you see the error, try signing in again and turning off any VPN. If everyone sees it, the website owner should check permissions and security rules.
A 403 often means protection is working, but it may be blocking the wrong person. The safest fix is to change the specific rule responsible.
What does a 403 Forbidden error mean?
Every web request receives a status code describing what happened. A normal page commonly returns 200 OK. A 403 response says the server understood the request but refused it.
The refusal may apply to a single file, a directory, an administration area, an API method or an entire website. Visitors may see "403 Forbidden", "Access Denied", "You don't have permission to access this resource" or a branded security page from a CDN or firewall.
The wording is important. A 403 is not the same as a page that does not exist. If the resource cannot be found, the normal response is 404 Not Found. If authentication is missing or invalid, it is usually 401 Unauthorised.
With a 403, the request reached a component that deliberately said no.
Common causes of a 403 error
Incorrect file and directory permissions are a traditional cause. The web server must be able to read public files and enter the directories containing them. If permissions or ownership change during a migration, deployment or manual upload, the server may reject access.
Web server configuration can also deny a request. Apache directives, .htaccess rules and NGINX location blocks can restrict directories, file types, IP addresses and request methods. A small syntax or inheritance mistake may block far more than intended.
Security systems frequently generate 403 responses. A web application firewall may detect a request pattern that resembles an attack. Rate controls, IP reputation services, geographic restrictions and bot protection can all refuse access before WordPress or another application is reached.
Inside an application, user roles may lack permission for a particular action. A valid account can still be forbidden from viewing an administration page, editing another user or calling a protected API operation.
Missing index files and disabled directory listings can create a 403 as well. If someone requests a directory that has no index.php or index.html, the server may refuse to show its contents. This is usually a sensible default, not a fault.
Finally, hotlink protection, content protection and cross-origin rules can reject requests coming from unexpected domains or applications. The page might work when visited directly but fail when embedded or requested through another service.
How to diagnose a 403 error
Start by determining who is affected. If only one person receives the error, test another browser, network and device. A blocked IP address, security cookie, VPN exit node or browser extension may be involved.
If everyone is affected, find out whether the error covers the whole site or one path. A site-wide 403 suggests a broad server, permission or firewall rule. A single forbidden URL is more likely to involve that directory, file, application route or user role.
Record the exact URL, time, public IP address and action that triggered the response. Those details allow a hosting provider to match the request against access, error and firewall logs. "The website showed 403 yesterday" provides very little to investigate.
Look at the response headers and error page. A CDN-branded page suggests the request stopped at the edge. A standard NGINX or Apache response points towards the web server. A WordPress-styled page or JSON response suggests the application or a plugin generated it.
Then review what changed. Recent plugin updates, firewall rule changes, migrations, permission changes and DNS or CDN cutovers are all useful leads. Avoid changing several controls at once, because doing so can remove the evidence you need.
How to fix a 403 error
If you are a visitor, confirm the address first. Remove any obvious path errors, sign in again if the area requires an account and try without a VPN. If the problem only affects you, contact the site owner with the time of the request and your public IP address.
If you manage the site, check file ownership and permissions against the platform's expected values. Do not solve the problem by giving every file unrestricted permissions. Settings such as 777 may make the error disappear while weakening the site's security. Apply the narrowest permissions required by the web server and application.
Review .htaccess, Apache and NGINX rules for explicit deny, Require, IP or location restrictions. If the error began after a configuration change, compare against the last known working version and validate syntax before reloading the service.
For firewall-related blocks, locate the specific event and rule ID. If a legitimate request has triggered a managed WAF rule, create the narrowest practical exception for the affected URL or parameter. Turning off the entire firewall is rarely justified.
Check application roles and capabilities when the user can access the site but not a particular function. The correct fix may be assigning the intended role rather than changing server permissions.
Purge caches after correcting the underlying rule. CDN and browser caches can preserve a forbidden response longer than expected, particularly when the cache policy is poorly configured.
403 errors in WordPress
WordPress sites can return 403 errors at several layers. A security plugin may block login attempts, REST API calls, XML-RPC, file editing or access from selected countries. A caching or optimisation plugin may write unexpected .htaccess directives. A migration can leave files owned by the wrong user, and a CDN firewall can block a legitimate administration request.
If /wp-admin is affected but the public site works, inspect security controls and authentication first. If media files return 403, check file ownership, permissions, hotlink protection and object storage rules. If saving a post triggers the error, a WAF may be reacting to content in the request body.
WordPress permalink problems normally produce 404 responses, but damaged or overly restrictive rewrite rules can produce 403 errors. Preserve a copy of .htaccess before replacing or regenerating it.
If you disable a plugin for testing, do so in staging where possible and change one component at a time. A blanket decision to disable all security controls on a live WordPress site creates unnecessary exposure.
Is a 403 a hosting issue or an application issue?
The answer depends on where the response originates.
The hosting provider is generally responsible for file ownership created by the platform, web server configuration, host-level firewall rules and infrastructure access controls. A good provider should be able to identify the responding layer and explain which rule denied the request.
The website owner or developer is usually responsible for application roles, custom access logic, plugin configuration and code that deliberately returns a forbidden response. CDN rules may sit with either party depending on who manages the service.
There is no value in debating responsibility before locating the fault. The practical sequence is to trace the request, identify the component returning 403 and then assign the correction to the right person.
How to prevent future 403 errors
Manage configuration through controlled changes rather than editing live files without a record. Retain known-good copies of web server and .htaccess rules, and test permission changes after migrations or deployments.
Use least privilege for files, users and APIs, but document deliberate restrictions so support teams know what is expected. Review WAF events before creating exceptions, and keep those exceptions narrow and time-limited where possible.
For WordPress, keep security plugins and the hosting layer aligned. Duplicating the same control across a CDN, server and plugin can make troubleshooting harder and sometimes causes conflicting rules. Test important administration and checkout workflows after security changes.
Monitor repeated 403 responses. A rise may indicate a broken feature, but it may also show that bots or attackers are being blocked. Context matters more than the count alone.
Frequently asked questions
Does 403 Forbidden mean I have been hacked?
No. It means access was refused. A security rule may be protecting the site correctly, although an unexpected site-wide 403 can also follow a misconfiguration or compromised .htaccess file. Logs and recent changes will provide context.
Can a 403 error be caused by a firewall?
Yes. WAFs, CDN security services, IP reputation tools and WordPress security plugins commonly return 403 responses. Find the matching security event before changing the rule.
What file permissions should WordPress use?
The correct settings depend on the platform, but directories are commonly 755 and files 644, with more restrictive settings for sensitive files where supported. Ownership is just as important. Follow your hosting provider's configuration rather than applying permissions indiscriminately.
Why can I access the site on mobile data but not office internet?
The office public IP may be blocked, rate-limited or associated with a firewall rule. A VPN or corporate proxy can have the same effect. Provide the affected public IP and timestamp to the site administrator.
Is 403 bad for SEO?
It is appropriate for private resources. An accidental 403 on public pages prevents search engines from crawling them and can eventually affect visibility, so unexpected blocks should be corrected promptly.
Final thoughts
A 403 Forbidden error is usually a policy decision, not a random failure. The challenge is working out whether that decision came from the web server, permissions, firewall, CDN or application-and whether it was the right decision.
Resist the temptation to remove every restriction until the page works. Trace the request, identify the exact rule and make the smallest safe correction.
At Network Dynamics, our engineers can help diagnose the error, explain the cause in plain English and recommend a practical next step. You will not be left wondering whether access was blocked by the hosting platform, a firewall, WordPress or the application-or who needs to fix it.
Continue with What Is a 404 Error and How Do You Fix It on WordPress?, or return to Common Web Server Errors Explained.
