Storage accounts that permit anonymous public access to blob containers
What does ZopNight detect here?
ZopNight flags a storage account whose `allowBlobPublicAccess` property is true. That account-level switch lets any container be opened to anonymous reads; it does not prove a container is public today, which is why the finding is rated high rather than critical. Setting the property to false blocks all anonymous blob access in one step.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1323 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Threshold | allowBlobPublicAccess = true |
| Source | ZopNight |
| Permissions used | Microsoft.Storage/storageAccounts/read |
Where it applies
Two switches control anonymous blob reads
Azure Blob Storage anonymous access
is governed by two settings working together. The account-level allowBlobPublicAccess
property decides whether anonymous access is permitted at all. Each container then has its own
access level: private (the default), blob, or container.
Anonymous reads happen only when both are open. Microsoft’s default configuration for new Resource Manager accounts disallows anonymous access, so an account with the property set to true has had it opened up, and any user with rights on a container is one command away from publishing its contents to the internet.
Finding permissive accounts and public containers
az storage account list \ --query "[?allowBlobPublicAccess].{name:name, rg:resourceGroup}" -o table
az storage container show-permission --account-name mystorage --name mycontainerThe second command reports a container’s public access level; anything other than off
means anonymous reads are live for that container.
An account-level flag, not proof of exposure
ZopNight reads the account’s allowBlobPublicAccess value from Azure and fires when it is true.
It does not collect container-level access today, so the finding says the account permits public
containers, not that one exists. That distinction is why it is rated high: a permissive
configuration, with confirmed exposure left for you to check.
Accounts that produce nothing
When the property was not reported, ZopNight treats the account as unknown and stays quiet. Accounts with the property false are never flagged, because Azure then rejects anonymous requests regardless of container settings. Customer tags about public access are ignored.
A leak waiting for one container change; no saving
No saving is attached. The risk is data exposed to anyone with the URL the moment a container’s access level is changed, often by someone who did not realise the account allowed it.
Closing anonymous access
- Check for real anonymous use first. Microsoft recommends enabling logging and metrics and analysing anonymous requests over a period before disallowing access.
- Move genuinely public content behind SAS tokens or Microsoft Entra authorization, or into a dedicated account that is allowed to be public.
- Disallow anonymous access on the account:
az storage account update --resource-group my-rg --name mystorage --allow-blob-public-access false. - Enforce the setting for new accounts with Azure Policy.