Why this matters
An Azure storage account is one namespace for blobs, files, queues and tables. Public exposure usually comes from two separate settings: the account-level Allow Blob public access switch and each container's access level. Teams often check one and miss the other. A container set to Container lets anyone list blobs and read them. A container set to Blob lets anyone read a blob if they know the path.
Network exposure is a different problem. Public network access set to Enabled from all networks opens the service endpoints to the internet. Even private containers can be reached, and Azure Files over SMB on port 445 is a favorite target for password guessing and ransomware. Many teams block blob public access but leave file shares reachable from anywhere.
SAS tokens and account keys are the quiet path. A SAS with read and list rights and a long expiry is a public link without any container being public. Shared key access lets anyone with the key read, write or delete data in the account. Portal settings alone will not show you these. You have to read app configuration and code.
Before you start
Get the right access first. Reader on each subscription lets you inventory account settings. To list containers and blobs you need Storage Blob Data Reader on the account or a higher data-plane role. To change settings you need Contributor or Storage Account Contributor. With only Reader, collect findings and hand them to someone who can change.
Write down scope: subscriptions, resource groups and storage accounts. Include accounts used by functions, logic apps, Batch jobs and third-party SaaS. Check test subscriptions too, because they often hold copies of production data.
Set a change window and a rollback plan. Disabling public access can break mobile uploads, public websites, CDN origins and partner integrations. Find the owner of each account before you touch it. Export current settings to CSV or JSON so you can compare before and after.
How to do it
Start with an inventory. Azure Resource Graph covers all subscriptions in one query, which beats clicking through the portal. Run the query in Resource Graph Explorer or with az graph query, then save the results. A short query is enough: resources | where type =~ 'Microsoft.Storage/storageAccounts' | project name, resourceGroup, subscriptionId, properties.allowBlobPublicAccess, properties.publicNetworkAccess, properties.networkAcls.defaultAction. Treat null values as not set and confirm in the portal.
Then check the data plane. Account settings say what is allowed. Container settings say what is actually configured. For each account with blob public access enabled, list containers and their access levels. Do the same for file shares, queues and tables. Finish by testing a few blobs with no credentials. A 200 response means anonymous read works. A 403 or 404 means it does not.
- Inventory storage accounts with Resource Graph. Run a query against Microsoft.Storage/storageAccounts across all subscriptions. Project properties.allowBlobPublicAccess, properties.publicNetworkAccess, properties.networkAcls.defaultAction, and properties.allowSharedKeyAccess. Export the rows to CSV so you can track fixes.
- Filter accounts with public network access. Look for publicNetworkAccess equal to Enabled and networkAcls.defaultAction equal to Allow. These accounts accept connections from the internet even if blobs are private. Note the ones that host Azure Files or static websites.
- List containers with anonymous access. Use the portal Containers blade and sort by access level, or run az storage container list with --auth-mode login and filter for publicAccess not equal to null. Record each container name and its level: Blob or Container.
- Review SAS tokens and stored access policies. Check the storage account Shared access signature blade for user delegation SAS settings. In each container, open Access policy and look for stored policies with read or list permissions and long expiry. Search app configuration and Key Vault for SAS strings.
- Check Azure Files and static website endpoints. In the portal, open File shares and Networking. Confirm whether SMB or NFS is reachable from the internet. Check Static website under Data management; the $web container is public by design, so make sure it holds only public assets.
- Test anonymous access from outside the portal. Copy a blob URL and request it with curl or a browser private window, with no Authorization header. If it returns the file, anonymous access works. Try the REST list operation on a container if its level is Container.
- Record the fix for each finding. For each account, choose one of three fixes: set Allow Blob public access to false, set container access to Private, or restrict public network access and use private endpoints. Add the owner, change window, and test plan.
How to check it worked
Re-run the Resource Graph query. Every account in scope should show allowBlobPublicAccess as false, or true with a documented exception. Check publicNetworkAccess. If you chose private endpoints, confirm the account shows Disabled or Selected networks, not Enabled from all networks.
Re-list containers. No container should return Blob or Container unless it is a deliberate public website. Test again with an anonymous request. You want 403 or 404, not 200. If a public site must stay public, confirm the $web container has no sensitive files and no directory listing.
Check the apps. Upload and download a test file from each client: web app, mobile app, background job, partner integration. Check CDN or Front Door origins. Look at Azure Monitor for failed requests, 403 spikes and authentication errors. Check the activity log for storage account setting changes.
Add evidence. Enable diagnostic settings for blob, file, queue and table services and send logs to Log Analytics. Enable Defender for Storage if you want alerts on suspicious access. Put a recurring reminder in the calendar to re-run the inventory.
Mistakes to avoid
Checking only the account-level switch. Allow Blob public access set to false does not clear container access levels. If someone re-enables the account switch later, every container set to Container becomes public again. Set containers to Private as well.
Forgetting SAS tokens. A SAS link can read a private container until it expires or is revoked. Long expiry dates and SAS in client-side code are common. Rotate account keys only after you find every app that uses them, because rotation breaks shared key clients.
Disabling public network access without private endpoints. If an app uses the public endpoint, it will fail. Add private endpoints, update DNS, and test from the same network as the app before you disable public access.
Ignoring Azure Files and other services. SMB exposed to the internet is a common ransomware entry point. Check port 445 and NFS port 2049. Also check queue and table endpoints. They can leak data even when blobs are locked down. If you want an outside view, the Cloudverg Cloud security review at $6,500 fixed price is one option among others; it covers public exposure checks across up to 5 subscriptions and gives a ranked fix list.
Frequently asked questions
What is the difference between public network access and anonymous blob access in Azure?
Public network access controls whether the storage endpoint accepts connections from the internet. Anonymous blob access controls whether a container or blob can be read without credentials. They are separate settings, so an account can accept internet connections while every container stays private.
How do I find Azure storage containers that allow anonymous access?
Use the portal Containers blade and check the access level column. Or run az storage container list with --auth-mode login and filter for publicAccess not equal to null. You need Storage Blob Data Reader or a higher data-plane role.
Does disabling Allow Blob public access break SAS links?
No. SAS links carry their own signed token and are not anonymous public access. Disabling the account setting stops unauthenticated public reads, but a valid SAS still works until it expires or is revoked. Rotate the signing key or remove the stored access policy to revoke it.