Question
"The specified container does not allow anonymous access, and no authentication information was provided." – Azure Blob Storage
Rahul Indigo
0 reputation · 18 Mar 2026, 11:22 UTC
19.2K views1
Loading…
0 reputation · 18 Mar 2026, 11:22 UTC
When hardening an Azure Storage account, administrators often set the allowBlobPublicAccess property to false to prevent new containers from being configured for anonymous read access. However, the documentation indicates that this account‑level flag does not automatically change the access level of containers that were already made public.
The goal is to confirm whether disabling allowBlobPublicAccess also revokes anonymous access for blobs that reside in containers whose ACL was previously set to blob or container. If the flag alone is insufficient, what additional step is required to ensure those existing containers no longer serve unauthenticated requests, and what error response should be expected when attempting to read a blob from such a container after the change?
allowBlobPublicAccess=false immediately block anonymous reads on existing public containers?Setting the account‑level property allowBlobPublicAccess=false immediately blocks anonymous read access to blobs in containers that were previously made public (ACL set to blob or container). No additional ACL change is required.
The account‑level flag acts as a guardrail that overrides the container‑level public access setting. When the flag is false, the storage service treats every blob as if the container ACL were private, regardless of the stored ACL value.
azure# Azure CLI example
az storage account update \
--name <storage-account-name> \
--resource-group <resource-group> \
--allow-blob-public-access false
# Check the property
az storage account show \
--name <storage-account-name> \
--resource-group <resource-group> \
--query allowBlobPublicAccess
After the flag is disabled, an anonymous GET to a blob URL returns:
<Error>
<Code>AuthorizationFailure</Code>
<Message>The specified container does not allow anonymous access, and no authentication information was provided.</Message>
</Error>
If you receive a different status code, check the API version used by the client or confirm that the account property is indeed set to false.
Use comments to ask for clarification. Post a solution as an answer.
34,275 reputation · 18 Mar 2026, 21:14 UTC
Disabling allowBlobPublicAccess at the storage‑account level does block anonymous data‑plane requests to any container, even if that container’s publicAccess property is still set to blob or container. The flag is a guardrail that overrides the stored ACL for anonymous traffic.
However, the flag does not rewrite the container’s publicAccess setting. Management‑plane queries (e.g., az storage container show) will still report the old value until you explicitly set the container to off (private) with az storage container set-permission --public-access off or the corresponding SDK call.
When an anonymous GET is made to a blob in such a container after the flag is disabled, the service returns HTTP 403 Forbidden with the message:
The specified container does not allow anonymous access, and no authentication information was provided.Authenticated requests (account key, SAS, Managed Identity) continue to succeed.
So, to fully clean up the environment you should:
allowBlobPublicAccess to false.off if you want the property to reflect the private state.