Microsoft Defender for Cloud · Storage
Storage accounts should prevent anonymous public read access
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Storage accounts should prevent anonymous public read access" check?
Flags any storage account where 'Allow Blob anonymous access' is enabled, which means a container or blob can be set to public read so anyone on the internet can list or download objects without credentials. It checks whether the option is possible at the account level, not whether a container is currently public.
Why does "Storage accounts should prevent anonymous public read access" matter?
Anonymous-readable containers sit behind a large share of cloud data leaks: backups, exports and personal data one unauthenticated GET away. Attackers scan for them continuously and discovery is usually automated within minutes of exposure. Disabling anonymous access at the account level removes the option entirely, so a single misconfigured container can no longer be made public by accident.
How do I fix "Storage accounts should prevent anonymous public read access"?
- Set 'allowBlobPublicAccess' to false on the storage account to block anonymous access account-wide.
- For content that must be public, front it with Azure Front Door or Azure CDN over a private origin rather than exposing the container directly.
- Default new storage accounts to anonymous-access-disabled in your Bicep or Terraform modules so the safe setting is the one nobody has to remember.
Remediation script · bash
# Close the highest-impact storage exposure first: anonymous read AND plain HTTP.
for acct in $(az storage account list \
--query "[?allowBlobPublicAccess].name" -o tsv); do
az storage account update --name "$acct" \
--allow-blob-public-access false \
--https-only true \
--min-tls-version TLS1_2
echo "$acct: anonymous access disabled, secure transfer required, min TLS 1.2"
done
# Ratchet it shut: deny any future account that allows anonymous access.
az policy assignment create \
--name deny-anon-blob \
--policy 13e6c4f1-e83f-4b50-a677-2cf6e2b9c885 \
--scope "/subscriptions/00000000-0000-0000-0000-000000000000" Full walkthrough (console steps, edge cases and verification) in the lesson Harden Azure Storage accounts.
Is "Storage accounts should prevent anonymous public read access" a false positive?
An account deliberately hosting public static assets still flags, because the control is about whether anonymous access is possible, not whether you intended it. Serve legitimate public content through Front Door so the account itself can stay locked down.