Your customer clicks a link, expects a product page, and meets a locked door instead. The site is live, the browser is working, and the request clearly went somewhere, but access was refused before the page could load. That’s the heart of error 403 Forbidden, and for UK business owners it usually means one thing, the request reached a system that understood it and then said no. That “no” can come from several places, not just the web server. A permission rule, a security filter, a CDN edge, or a storage bucket can all reject the request first, which is why 403 problems feel confusing until you break the journey into layers. Think of it as a request passing through a series of doors, each with its own key or security check, and the first locked door is the one that stops the visitor. What Error 403 Forbidden Means A visitor taps a page, and instead of the content they wanted, the screen shows a refusal. The browser has not lost the connection, and the site has not vanished. The server understood the request and still chose not to serve it, which is why 403 Forbidden sits in the family of HTTP client errors rather than network failures, and why it is different from a 404 or a 401 MDN’s reference for HTTP 403.   A locked door, not a broken road The simplest way to read a 403 is as a door that opened just enough to identify the visitor, then shut again. A 404 says the page was not found. A 401 says the server wants authentication, while a 403 says the server knows the request enough to reject it anyway. That distinction matters because a retry usually won’t help. If the site or server policy has decided the request is not allowed, repeating the same request gives the same answer. In practical terms, 403 is often the first access-control layer saying that the visitor cannot reach the file, admin area, storage object, or route they asked for. Practical rule: if the browser can reach the site but the site refuses access, treat it as a permission or policy problem first, not a connectivity problem.   What the visitor, browser, and server each see The visitor sees a refusal message or a generic forbidden page. The browser usually shows a status code or a simplified error screen because it received a valid HTTP response, just not the one the user wanted. On the server side, the event is logged as a denial, not a crash, and that log entry is often the most useful clue when you’re trying to work out whether the issue came from permissions, rules, or an upstream filter. UK hosting guidance has long treated 403 this way. Heart Internet’s support article explains it as a page the browser is not permitted to view, and it ties the error to server settings such as directory permissions of 711 or 755 and file permissions of 644 in common UK hosting environments Heart Internet support guidance. That is why 403 is usually about access control, not a broken route or bad internet connection.   How Access Decisions Reach the Server A 403 often starts long before a page is rendered. A visitor clicks a link, then the request can pass through DNS, a CDN or edge cache, the web server, the application, and sometimes object storage before it reaches the content. Any one of those layers can make its own decision, so the question is not just “why did the server refuse?”, it’s “which layer refused first?”   Authentication is not the same as authorisation Authentication proves who the visitor is. Authorisation decides what that visitor may do. A logged-in user can still get a 403 if their role, token scope, path, or method does not match the policy. That’s why the same status code can appear in different places for different reasons. In the UK DVLA API documentation, 403 is used both for “Missing authentication token or unsupported API method/resource” and for “Access denied”, which shows how one refusal code can reflect either an auth-token problem or an explicit policy decision depending on the backend path MDN’s HTTP 403 reference also explains the general refusal model.   Think in layers, not guesses The browser is only the front of the chain. A CDN can deny a request before the origin ever sees it. A web server can reject a directory because the file mode is too strict. An application can block a user role. Object storage can deny a public read because the bucket policy says no. Don’t assume the origin server is guilty just because the browser shows a 403. The first deny rule in the path is usually the real cause. The safest way to diagnose the problem is to locate the layer that issued the reject. Once you know whether the refusal came from the application, the web server, the edge security layer, the CDN, or storage, the fix becomes much more precise.   Common Causes Behind a 403 Response A 403 usually means the first access-control layer in the path has already said no. That layer might be the application, the web server, the edge security system, the CDN, or object storage. The browser only shows the final refusal, so the useful work is finding which layer made the decision first. Start with the request itself. A page can be blocked because the user is not allowed, because the server cannot read the file, or because an upstream rule stops the request before it reaches the origin. The same status code can also appear when a bucket policy, signed URL, or edge filter rejects access.   Permissions and configuration issues File permissions are a common cause, especially after a deployment or migration changes ownership. If a directory cannot be traversed, the server may never reach the page even when the file exists. A missing or misnamed index file can also trigger