Azure Blob Public Access: The Default Nobody Disables
Azure Blob Public Access: The Default Nobody Disables sits in the Azure Storage Security risk register because a small configuration shortcut can widen access, weaken control boundaries, or hide failure conditions. The risk usually starts with provision a Storage Account through an older ARM template, a Terraform module pinned below azurerm provider 3.x, or a Bicep file that omits the In production, the concern is anonymous access at the "Container" level does not just serve known
The Trap
The allowBlobPublicAccess property on an Azure Storage Account, and the per-container public access level that inherits from it.
The Default State
Provision a Storage Account through an older ARM template, a Terraform module pinned below azurerm provider 3.x, or a Bicep file that omits the property entirely, and allowBlobPublicAccess resolves to true at the account level. The Azure Portal changed its own toggle to “Disabled” for interactively created accounts some time ago, but every script, pipeline, or module written before that change still creates accounts with the flag open. Because the setting is account-wide and container-level access (“Private”, “Blob”, “Container”) sits on top of it, a developer who flips one container to “Blob” access to serve a public asset unknowingly leaves the door open for every container created afterwards, since nothing at the account level is stopping them.
The Blast Radius
Anonymous access at the “Container” level does not just serve known blob URLs, it permits unauthenticated List Blobs calls against the entire container. Attackers running subdomain enumeration against *.blob.core.windows.net find the account, issue an anonymous LIST, and receive a full manifest of every object inside, including backup exports, application configuration files with embedded connection strings, and customer data dumps that were never meant to be internet-facing. Because the account-level flag is inherited silently, this pattern replicates across every new container added by CI/CD pipelines that reuse the same Storage Account, turning one forgotten toggle into a standing exfiltration channel that surfaces in a security scan months after the account was created, by which point the blobs have already been indexed by automated scrapers.
The Lead Mechanic Fix
Disable the flag explicitly at account creation and retrofit existing accounts:
az storage account update --name <account> --resource-group <rg> --allow-blob-public-access false
Audit every container for a lingering public access level with az storage container list --account-name <account> --query "[?properties.publicAccess!=null].{name:name,access:properties.publicAccess}" and reset any hits to off. Enforce the setting fleet-wide with the built-in Azure Policy definition “Storage accounts should have public network access disabled” set to Deny, and add a second policy denying Microsoft.Storage/storageAccounts deployments where allowBlobPublicAccess equals true. Replace public container access with Azure AD RBAC roles such as Storage Blob Data Reader, or time-boxed SAS tokens issued through a broker, so every access is authenticated and logged rather than anonymous.