Access Denied

The short version: Work out who is refusing you before you change anything. A block from the website itself usually shows an Apache or nginx signature and is the owner's to fix. A Cloudflare block page, headed Error 1020 and printing a Ray ID, means a rule at the edge. ERR_BLOCKED_BY_ADMINISTRATOR means your own device or network, so only IT can lift it. As a visitor, try incognito, then a different network: those two tests separate a cookie problem from an IP or policy block in under a minute.

Key takeaways

• Access Denied is a message, not a status code. On the web it is nearly always an HTTP 403 in plainer words, but the same two words also come out of Windows, out of a corporate web filter, and out of object storage, so the first job is working out which system printed it.
• Read the signature on the page before you change anything. An Apache or nginx footer means the origin refused you. A Cloudflare block page, the kind headed Error 1020 that prints a Ray ID, means the edge refused you and the origin never saw the request. A native dialog with no address bar is a file-permission problem, not a website problem.
• Two of the longer strings name their own source. You don't have permission to access / on this server is the stock 403 body from older Apache builds, and Your client does not have permission to get URL is Google's own frontend turning your client away, usually over a flagged VPN address or a corrupted cookie.
• A browser page reading This page is blocked with ERR_BLOCKED_BY_ADMINISTRATOR underneath is a different animal entirely. Nothing is wrong with the website: a browser policy, a DNS filter, or a network proxy stopped the request before it left your machine, and only whoever manages the device or the network can lift it.
• For the status code itself, its spec wording and the server-side permission work, read the companion guide to 403 Forbidden. If the server is inviting you to sign in rather than refusing you outright, that is 401 Unauthorized.

Error type

Access refusal message, usually HTTP 403

Whose side

Usually the website or your network, not you

Fix difficulty

Easy to moderate

Common cause

A rule refusing the request, not a broken server

What does Access Denied mean?

Access Denied is not an HTTP status code, and that is precisely why it needs its own guide. It is a human-readable message, and at least five unrelated systems print it. On the public web it is usually an HTTP 403 dressed in friendlier language, so the mechanics in our 403 Forbidden guide apply. But the same words come out of Windows when a file permission stops you, out of a corporate web filter when a policy stops you, out of Google's frontend when it distrusts your client, and out of an S3 bucket when a policy never granted read access. The useful question is never what Access Denied means in the abstract. It is which system just said it to you.

Identify the author and you have identified the fix, because none of these are fixed the same way. Apache and nginx sign their own error pages. Cloudflare stamps a CF-RAY header on the responses it proxies and prints a Ray ID on its block pages. Google finishes its refusal with That's all we know. Windows opens a dialog box with no address bar in sight. Object storage answers with an XML document rather than HTML. Each of those points at a different owner, and three of them are not the website owner at all. If instead of refusing you the server is asking you to authenticate, you are looking at 401 Unauthorized, which is a different problem with a different answer.

403

HTTP status behind most Access Denied pages

1020

Cloudflare error code for a firewall-rule block

AADSTS53003

Entra ID code for "You cannot access this right now"

chrome://policy

Where Chrome lists an administrator URL block

How the Access Denied error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com/reports/

403

Access Denied

You don't have permission to access /reports/ on this server.

• Access Denied
• Access is denied
• You don't have permission to access this resource
• You don't have permission to access / on this server
• Your client does not have permission to get URL / from this server
• This page is blocked
• Your organization doesn't allow you to view this site
• You cannot access this right now
• Error 1020: Access denied
• ERR_BLOCKED_BY_ADMINISTRATOR
• This website has been blocked by your administrator

Which system is saying Access Denied?

Match the exact wording on your screen to the row below. The middle column tells you what actually refused the request, and the right column tells you who is able to undo it.

Fingerprints that name the system blocking you

The wording on the page is a hint; the full response, headers and body together, is the proof. Run one curl, read these signals, and you know which layer to go and fix.

What causes Access Denied?

• File or folder permissions on the origin that stop the web server reading what it is being asked to serve, the single most common cause of an Apache or nginx refusal
• An access rule written on purpose: a Require block in Apache, an allow or deny pair in an nginx location, or an IP allowlist protecting an admin path
• A WAF, CDN, or firewall rule refusing the request at the edge before it reaches the origin, which is what a Cloudflare Error 1020 page represents
• Geo-blocking, or an IP-reputation rule that turns away VPN exit nodes, Tor, and datacentre address ranges regardless of who is behind them
• A corporate or school network filter, a DNS-level blocklist, or a browser enterprise policy such as Chrome's URLBlocklist stopping the request on your side
• A conditional-access or SSO policy refusing a session that authenticated correctly but came from an unmanaged device, an unexpected location, or a blocked client app
• Object storage permissions: an S3 bucket policy with no matching allow, Block Public Access left enabled, or an object-ownership setting that disables the ACL you were relying on
• Hotlink or referrer protection refusing asset requests whose Referer header is not on the allowed list of domains
• Windows file-system permissions or ownership, which produce the identical phrase with no web server involved at all
• A stale or corrupted cookie, or a browser extension rewriting request headers, which is what makes many Google and CDN refusals clear the moment you open a private window

How to find the cause fast

1. Read the page carefully before touching anything. Note the exact wording, any error number, any Ray ID or request ID, and any server name printed at the bottom. That text alone usually identifies the system refusing you and saves every step below.
2. Open the same URL in an incognito or private window. If it loads there, the cause is riding along with your normal profile: a stale cookie for that website, or an extension altering the request. Clear that one website's cookies rather than everything.
3. Switch networks. A phone on mobile data, with Wi-Fi turned off, is the fastest test there is. Loading fine off the office or home network points at your IP address, your DNS resolver, or a filter on that network, not at the website.
4. Try a different device on the same network. Still blocked on the network but fine on another device means a device-level browser policy or local security software; blocked on both devices means the network or the website.
5. Establish the scope. Load the homepage and one deep URL. One path refusing you points at a rule or a permission local to that path, while a website-wide refusal points at an IP block, an edge rule, or permissions applied across the document root.
6. Confirm the real status code from outside your own network with curl -sI https://example.com/path/ run on a server, or a third-party status checker. The Server header names who answered, and if the body is a Cloudflare block page rather than your own template, the edge is what refused it.
7. On a managed computer, open chrome://policy and search for URLBlocklist. If the URL matches a pattern listed there, the block is administrative and no amount of browser troubleshooting will move it.

Terminal

curl -sI https://example.com/reports/HTTP/2 403server: cloudflarecf-ray: 8f2a1c9d4e7b0a12-FRA# cloudflare is in front: read the body to see if the edge or the origin said no

How Access Denied looks from the outside

A refusal answers quickly and reads as healthy from outside, so the check has to assert the status code on the URL that matters rather than ask whether the host is up. What makes this error awkward to watch is that the refusal is often not uniform. A geo-block, a country rule, or an IP-reputation rule fails from some places and works from others, so one probe can report everything fine while an entire market is locked out, and only comparing probes from several regions exposes it. The mirror image is worth guarding against too: a WAF or firewall rule can refuse your monitoring probes while real visitors sail through, which produces an alert about nothing. Allowlisting the monitoring source is what keeps that second mistake off the table.

How to fix Access Denied

If you are a visitor

1. Reload once, then check the URL for a typo or a trailing path that points at a directory the website will not let you browse.
2. Open the page in an incognito or private window. If it works there, clear the cookies and cache for that one website in your normal browser.
3. Disable browser extensions one at a time, starting with ad blockers, privacy tools, and anything that rewrites headers, then reload after each.
4. Turn off any VPN or proxy, or move to a different exit location. A great many refusals are aimed at VPN, Tor, and datacentre address ranges rather than at you.
5. Try the same URL on mobile data with Wi-Fi off. Loading there tells you the block belongs to your network, not to the website.
6. If the page mentions your administrator, stop troubleshooting. Send IT the URL and the error code on the page; it is a policy, not a fault.
7. If nothing works and the block clearly sits on the website, contact the owner and quote any Ray ID or request ID shown, since that is what lets them find the rule.

If a work or school network is blocking it

1. Open chrome://policy (or edge://policy) and look for URLBlocklist and URLAllowlist. A matching pattern is your answer.
2. Check whether the block follows the device or the network by testing the same URL on a personal phone using mobile data.
3. Ask your administrator for an exception rather than trying to route around the filter, which usually breaches acceptable-use policy and often gets logged.
4. For an administrator: add the URL pattern to URLAllowlist, which takes precedence over the blocklist, and confirm the DNS filter and proxy carry the same exception.
5. If a sign-in succeeded and then failed the policy check, read the Entra ID sign-in logs for AADSTS53003 to see exactly which conditional-access rule fired.

If you run the website

1. Reproduce the read as the web server user before you change any mode bits: sudo -u www-data cat /var/www/example.com/public/reports/index.html. Every parent directory needs the execute bit as well, which is the part a chmod on the file alone misses. The full permissions and index-file checklist is in the 403 Forbidden guide.
2. On a host running SELinux in enforcing mode, correct modes are not enough: a wrong security label refuses the read on its own. Inspect with ls -Z and relabel with restorecon -Rv /var/www/html. Debian and Ubuntu systems can hit the equivalent problem through an AppArmor profile.
3. Search your Apache config and .htaccess for Require and deny, or the nginx location block for allow and deny, and confirm the rule matches only what you meant it to.
4. Read the error log for the exact request. Apache and nginx both record which rule matched or which file could not be read, which usually ends the investigation immediately.
5. Bypass the CDN and request the origin directly. If the origin answers 200, the block is an edge rule and belongs in the CDN dashboard, not in your server config.
6. In Cloudflare, search Security Events for the Ray ID from the block page, then adjust the WAF custom rule, IP Access rule, or managed rule that fired.
7. Behind a proxy, make sure set_real_ip_from and real_ip_header are configured before you write IP rules. Without them every request looks like it came from the proxy, so IP rules either block everyone or nobody.
8. Allowlist the traffic you actually want: your own monitoring, your partners, and legitimate search crawlers, so an anti-abuse rule never quietly de-indexes a public page.

If it is object storage or a Windows file

1. For S3, check Block Public Access at both account and bucket level first, since it overrides a permissive bucket policy.
2. Confirm the bucket policy grants s3:GetObject to the principal actually making the request, and remember that AWS denies by default when no allow matches.
3. Check the object-ownership setting. With ACLs disabled, an object ACL you were relying on has no effect at all.
4. If the object is encrypted with a customer-managed KMS key, confirm the caller has kms:Decrypt on that key as well as read on the object.
5. On Windows, right-click the file, open Properties then Security, and confirm your account appears with the rights you need; an explicit deny always beats an allow.
6. From an elevated prompt, read the ACL with icacls "C:\path\to\file", then repair it with icacls "C:\path\to\file" /grant Username:RX. If the owner is wrong, take ownership first with /setowner.

Still not fixed? Next steps

• Prove which side is refusing you before you argue with anybody. Ask the origin directly and bypass the edge with curl -sI --resolve example.com:443:198.51.100.10 https://example.com/path/. A 200 from the origin and a 403 through the front door means the CDN or WAF owns the block.
• When the block is at the edge, take the Ray ID or request ID printed on the page to whoever runs it. Cloudflare records every block in Security Events against that ID, so the rule that fired can be found in seconds rather than guessed at.
• On a managed laptop, or a school or office network, you cannot fix this yourself and should not try. Send IT the exact URL, the error code shown on the page, and whether the same URL also fails on a phone that is off the Wi-Fi. That last detail tells them immediately whether it is the device policy or the network filter.
• A successful sign-in that still ends in You cannot access this right now is a conditional-access decision, not a bad password. An Entra ID administrator can open the sign-in logs, find error AADSTS53003, and see exactly which policy refused the session and on what grounds.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Apache 2.4: allow, restrict, and refuse a path with Require

# Apache 2.4 syntax. Order / Allow / Deny is the deprecated 2.2 form,
# kept alive only by mod_access_compat. Do not use it in new config.

<Directory "/var/www/example.com/public">
    Require all granted
</Directory>

<Directory "/var/www/example.com/public/reports">
    # office range only, with one abusive host excluded
    <RequireAll>
        Require ip 203.0.113.0/24
        Require not ip 203.0.113.66
    </RequireAll>
</Directory>

<Directory "/var/www/example.com/private">
    # never served to anyone
    Require all denied
</Directory>

# Check the syntax, then reload:
#   apachectl configtest && systemctl reload apache2

nginx: allow and deny inside a location block

# ngx_http_access_module. Rules are checked in order and the first
# match wins, so the catch-all deny goes last.

location /reports/ {
    allow 203.0.113.0/24;    # office IPv4 range
    allow 2001:db8::/32;     # office IPv6 range
    deny  all;               # everyone else gets 403 Forbidden
    proxy_pass http://backend;
}

# Behind a CDN or load balancer, $remote_addr is the proxy, not the
# visitor, so IP rules match the wrong thing until you set this up:
#
#   set_real_ip_from 203.0.113.0/24;
#   real_ip_header   X-Forwarded-For;
#
# Check and reload:  nginx -t && systemctl reload nginx

curl: see the 403, its headers, and its body

# -s quiet, -S keep errors, -D - dump the response headers to stdout
curl -sS -D - https://example.com/reports/

# HTTP/2 403
# server: cloudflare
# cf-ray: 8f2a1c9d4e7b0a12-FRA
# content-type: text/html; charset=UTF-8
#
# <html><head><title>Access denied</title></head> ...
#
# The server header names who is answering, not always who refused.
# Apache and nginx sign their own error pages. A cf-ray only proves
# Cloudflare is in front: the body settles it, because a Cloudflare
# block page prints "Error 1020" and its own Ray ID. When in doubt,
# ask the origin IP directly and compare:

curl -sI --resolve example.com:443:198.51.100.10 https://example.com/reports/

# 200 here plus 403 through the front door = the block lives at the edge.

How to prevent Access Denied

A permissions change, a new firewall rule, or an edge policy can lock visitors out of one important path while the homepage keeps loading normally, so nobody notices until someone complains. Pulsetic checks the URLs you choose from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, or webhook when a page starts answering 403 instead of the content it should. Because the checks run from several places, a rule that only refuses one region shows up as a difference between probes rather than silence. It watches availability from outside your network, so it will tell you a page has started refusing visitors, not which rule did the refusing.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.