Blob public access turns containers into an anonymous, unauthenticated download link

Why it happens

This is distinct from the network-level switch (see AZF-0025). Public network access controls whether the endpoint is reachable; allowBlobPublicAccess controls whether reaching it can succeed without authenticating at all. The account switch is the master gate: with it false, no container can be anonymous no matter how it's configured; with it true, a single mis-set container leaks.

It gets turned on for ordinary-looking reasons. Someone hosts static assets or a public download, a legacy app expects anonymous blob URLs, or a default in an older template leaves it enabled. Newer accounts default it to false, but the flag is easy to flip back and easy to inherit from copied infrastructure code. Because the account keeps working, the change rarely gets a second look.

What it costs / blast radius

The blast radius is any container on the account that is (or later gets) set to an anonymous access level. Anonymous reads bypass keys and RBAC entirely, so a container holding backups, exports, logs, or customer files becomes a public, unauthenticated download endpoint. Search engines and blob-URL scanners routinely find these. The exposure is not measured breach data; it is the plainly documented Azure behavior that anonymous access requires this flag to be on, which is exactly why turning it off account-wide is the durable fix.

See it

resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'corpassets001'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    allowBlobPublicAccess: true   // any container may be set to anonymous reads
  }
}

resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'corpassets001'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    allowBlobPublicAccess: false  // no container can be anonymous, whatever its ACL says
  }
}