To stop anonymous reads on Azure Blob Storage, set the storage account's AllowBlobPublicAccess property to false. This overrides every container setting in the account. Check logs for anonymous requests first so you do not break a client, then use Azure Policy to audit or deny accounts that allow it.
Two switches, not one
Anonymous read access depends on two settings. The account has an allow or disallow setting. Each container has an access level of Private, Container or Blob.
A container serves anonymous reads only if the account allows it and the container is set to Container or Blob. If the account disallows anonymous access, the container setting is ignored. That is why the account switch is the one to fix.
Microsoft states anonymous access is prohibited by default, and recommends disabling it for best security. A request that includes an Authorization header ignores the anonymous setting and is authorized by its credentials.
Detect before you change
Turning the setting off makes future anonymous requests fail. To avoid surprises, look at what is happening now.
- In Metrics Explorer, chart Blob transactions summed, filtered where Authentication equals Anonymous.
- Turn on a diagnostic setting that sends storage logs to a Log Analytics workspace, then query the blob logs for AuthenticationType equal to Anonymous. That shows which containers receive anonymous requests.
- Set an alert on that query if you want to hear about new ones.
Failed anonymous requests return 401 for newer service versions, and 404 or 409 for older ones depending on the account setting, so do not treat a 404 as proof that nothing is calling.
Change the setting
In the portal, open the storage account, go to Configuration and set Allow Blob anonymous access to Disabled. You can also use PowerShell or the Azure CLI, setting the allow blob public access parameter to false. Microsoft says it can take up to 30 seconds to propagate.
Static websites are the exception to remember. Microsoft notes that disallowing anonymous access does not affect a static website, because the web container is always publicly accessible.
If a few containers really need public reads, move them into a separate account reserved for that purpose and lock down every other account.
Check many accounts at once
Azure Resource Graph can list the setting across subscriptions with one query on storage accounts. A blank value means the property was never set, so treat blank like a finding, not like a pass.
Keep it from drifting
Azure Policy can run in two modes for this property. With the audit effect, noncompliant accounts show in a compliance report. With the deny effect, nobody can create or update an account that allows anonymous access. Start with audit, clear the backlog, then move to deny.
Watch out for the broader permission trap too. Roles that can edit storage accounts also include the permission to list account keys, which gives data access. Grant data roles such as Storage Blob Data Reader to people who only need data.
Quick check
Do I also need to change each container?
No. When the account disallows anonymous access, that setting overrides all containers in the account.
Will private containers be affected?
No. Requests with valid credentials still work. Only requests without an Authorization header that relied on public access will fail.
Sources
Last reviewed: 19 October 2026.
