Check and stop anonymous access to Azure blobs

Test the object rather than trusting its container name

To stop anonymous reads from ordinary Azure Blob Storage endpoints, disable anonymous blob access at the storage-account level, then verify that an unauthenticated request to a known blob is denied. Also verify that the intended application can still read the object using its approved credentials. Container names and a successful portal visit are not sufficient evidence. The account setting and the container setting work together, and the test must exercise the right endpoint. ^{[1] [2]}

Begin with one account and an identified application owner. Record which containers hold private application data and whether any intentionally publish files to the public. A storage account shared between public downloads and internal files requires a deliberate migration decision. Disabling anonymous access across the account affects existing anonymous readers, including legitimate ones that the original administrator may no longer remember.

Use a harmless known blob for the verification. Give it recognizable content and keep its exact ordinary blob URL. Do not use a customer document as a public-access test object, and do not enable anonymous access on private data to create a before screenshot. If an account already disallows anonymous access, verify and retain that state. The absence of a dramatic before-and-after result does not make the check less useful.

This guide focuses on anonymous blob reads and the settings that control them. Shared access signatures, account keys, Entra data roles, public network access and the static website endpoint have separate behavior. They appear here because confusing them can lead to a false conclusion, not because one switch is intended to replace every storage security control.

Understand the two anonymous access settings

For Azure Resource Manager storage accounts, Microsoft documents anonymous blob access as prohibited by default. An account-level setting determines whether containers can permit anonymous access. If the account disallows it, that restriction overrides a container that was configured for public reads. If the account allows it, each container still needs an appropriate access level before anonymous reads are permitted. Inspect the saved values instead of relying on defaults for an existing account. ^[2]

Container access levels distinguish private access, anonymous blob reads and anonymous container-and-blob reads. A Blob-level public setting permits reading individual blobs without authorizing container listing. A Container-level setting also permits the relevant anonymous container access. Knowing a blob's URL can therefore matter even when listing the container fails. A failed listing is not proof that its blobs are private. ^[3]

Think of the account setting as permission for containers to be public, and the container setting as the choice for a particular container. Both conditions must permit the relevant anonymous operation. The decision tree summarizes that relationship for ordinary blob reads. It is a conceptual control explanation, not a scan result or a count of exposed resources.

Check the actual property names when using a command-line tool. The account property is commonly represented as allowBlobPublicAccess, while a container has its own public-access value. A report that flattens both into one column labeled public can hide the difference. Retain the account value and the selected container's state separately so that a later operator can reconstruct the decision.

Source. Microsoft documentation: Overview of remediating anonymous read access for blob data - Azure Storage ^[1]; Remediate anonymous read access to blob data (Azure Resource Manager deployments) - Azure Storage ^[2]; Configure anonymous read access for containers and blobs - Azure Storage ^[3].

Method. Original conceptual synthesis of the cited Microsoft documentation. No deployment measurements or risk scores. Reviewed 2026-09-12.

Accessible table and figure data

Figure 1 accessible table

Account setting	Container setting	Ordinary anonymous blob read
Disallowed	Any container setting	Denied
Allowed	Private	Denied
Allowed	Blob public	Individual blob read permitted
Allowed	Container public	Blob read and relevant container access permitted

Figure 1 accessible table

Account setting	Container setting	Ordinary anonymous blob read
Disallowed	Any container setting	Denied
Allowed	Private	Denied
Allowed	Blob public	Individual blob read permitted
Allowed	Container public	Blob read and relevant container access permitted

Download imageDownload table CSV

Separate anonymous access from public networking

Anonymous access asks whether a request without credentials may read the blob. Public network access asks which network paths can reach the storage service. An account can be reachable through its public endpoint while still requiring authorization for every blob read. Conversely, permitting anonymous access does not guarantee that every network source can reach the account. These are different controls with different tests. ^{[4] [10]}

A private endpoint provides a private network path for the relevant storage subresource. It does not, by itself, remove all public network paths or decide which identity may read a blob. If the account is intended to be private, validate DNS, endpoint approval, public-network settings and data permissions through the separate private-access procedure. Do not infer all of those outcomes from the presence of a private endpoint resource.

The task here can still be valuable for an account that remains publicly reachable. Many applications legitimately use authenticated requests to a public service endpoint. Disabling anonymous reads narrows who can retrieve blob data without requiring a network redesign. Whether that is sufficient for the application's data classification is a separate architecture decision for its owner.

Keep the acceptance statement precise. Saying anonymous reads to the checked blob endpoint are denied is supported by the account setting and a suitable test. Saying the storage account is completely private would require a wider review. Precise language helps the next operator know whether they should investigate credentials, network routing or the particular endpoint used by the application.

Inventory the account and its intended readers

Open the storage account's configuration and record the account-level anonymous-access value. Inspect the relevant containers and their access levels. Include the account ID, subscription and resource group in the record so that similarly named resources are not confused. If you use Azure CLI, az storage account show can retrieve account properties, and the command reference describes the available query and output options. ^[8]

Ask the application owner which readers are expected. That list may include a web application, a scheduled export, a partner download or a public documentation site. Identify how each reader authenticates. An application that appears to work without a login might still receive a signed URL from a backend, while another might directly request an anonymous blob. The browser's visible experience does not reliably identify the storage authorization method.

Record a representative known object for each relevant path. The object should be harmless or approved for the test, and its existence should be verified through an authorized read. Testing a random path that does not exist can produce a denial-like result even when another blob remains readable anonymously. A good negative test starts from an object you know is there.

Do not turn an inventory into an uncontrolled data download. Listing container names and reviewing configuration may be sufficient to plan the change. If content classification is uncertain, involve the data owner rather than copying every blob to a workstation. The access review should minimize additional exposure while gathering the information needed to choose a safe account-level policy.

CSD_AZ_GROUP='example-app-rg'
CSD_STORAGE_ACCOUNT='examplestorageaccount'
az storage account show --resource-group "$CSD_AZ_GROUP" --name "$CSD_STORAGE_ACCOUNT" --query '{id:id,allowBlobPublicAccess:allowBlobPublicAccess,publicNetworkAccess:publicNetworkAccess}' --output json

Find applications relying on anonymous requests

Before disabling access on an account that permits it, inspect available storage metrics and logs for anonymous requests. Microsoft's remediation guidance describes filtering Blob Transactions by the Authentication dimension and using storage logs to identify anonymous request paths. Those observations can help identify affected consumers. They are evidence for the selected period and configured telemetry, not a complete census of every possible reader. ^[2]

Choose an observation period that reflects the application's schedule. A daily dashboard and a monthly export have different activity patterns. A quiet hour does not establish that no legitimate consumer exists. Combine telemetry with owner knowledge and configuration review, especially for rarely used downloads, partner integrations and emergency procedures.

Check whether the relevant data logs were actually enabled and retained. A missing log row can mean no request occurred, but it can also mean the service path was not collected or the period has expired. Do not postpone an urgent private-data containment decision indefinitely while waiting for perfect logs; instead, state the uncertainty and coordinate the expected application impact with the owner.

If the team finds a legitimate anonymous reader, decide how it will authenticate or where deliberate public content should live. The change should have an application migration step, not just a storage setting. For a simple internal application, an appropriate Entra identity and data role may fit. A public download site may need a separately reviewed publishing arrangement. Each choice should preserve the intended reader experience without keeping unrelated private data eligible for anonymous access.

Check one known blob without credentials

Use the exact ordinary blob URL for the harmless known object and issue a request without an Authorization header, cookies or a shared access signature. A fresh browser session can be helpful, but a command-line HTTP request makes the absence of credentials easier to inspect. Remove any query string carrying a SAS token before calling the test anonymous. ^[2]

A successful response containing the expected harmless bytes establishes that the tested object is anonymously readable from that test source at that time. A failed response needs more interpretation. Verify that the hostname, container and object path are correct and that the test source can reach the endpoint. A nonexistent object or blocked network path can fail for reasons other than the anonymous-access policy.

Do not require one universal HTTP status for every denied anonymous read. Microsoft's remediation documentation describes response differences associated with service versions and bearer-challenge behavior. Record the status and storage error details, then interpret them alongside the known object's existence and the saved account setting. A 404 alone is not a complete private-access proof. ^[2]

Use an ordinary read for the harmless object when appropriate, or a header-only request as a preliminary check. The Azure CLI's blob commands support explicit authentication modes for authorized operations, but an authenticated CLI success is not the anonymous test. Keep the unauthenticated request and the intended application's authenticated request as two separate observations. ^[9]

If a proxy or content-delivery layer is involved, record that path separately. A cached copy may remain reachable after origin access is changed, and a proxy might add credentials to an origin request. Test the storage origin directly when the question is the account's anonymous policy, then test the user-facing delivery path according to its own configuration. Do not assume the two responses prove the same thing.

Interpret a small set of known-object tests

Use a small worksheet to keep the test inputs stable. For each check, record the ordinary blob URL, whether the object is known to exist, the request's credential type, the network source and the observed result. The worksheet does not need a risk score. Its purpose is to prevent two apparently similar HTTP responses from being treated as evidence for the same access condition when their inputs differ.

In a hypothetical first case, an operator requests a known harmless blob with no credentials and receives its expected contents. That is a positive anonymous-read observation for that object and source. The next step is to inspect the account and container settings and coordinate the intended restriction. It does not establish that every container is public, and it does not justify downloading other objects to estimate the amount of exposed data.

In a second case, the request fails, but an authorized read of the same URL also reports that the object is missing. This is an invalid privacy test because the object was not established as present. Correct the name or choose the approved harmless object, then repeat the unauthenticated check. A nonexistent path can be useful for testing error handling, but it cannot prove that a real blob is protected from anonymous readers.

In a third case, the browser opens the file successfully while an unsigned command-line request is denied. Inspect the browser URL and delivery path before concluding that the controls disagree. The URL may contain a SAS token, a front-end service may authenticate the origin request or a cached public copy may be served. Preserve the actual difference and test each path according to its purpose. The result may be consistent with anonymous origin reads being disabled while an approved delegated read remains available.

In a fourth case, both anonymous and authorized requests fail from the application network, while an authorized operator can read the blob elsewhere. That suggests the test must also examine the network path or selected identity. Do not use the two failures as evidence that the anonymous policy alone is working correctly. The positive application test exists precisely to distinguish a useful restriction from a broadly broken service path.

Compare each diagnostic pattern with the request and response you actually observed. Record the endpoint, object name, presence or absence of credentials and outcome so another operator can distinguish an anonymous test from an authenticated one. If the account's behavior remains inconsistent with its saved configuration, keep the check unresolved and investigate the endpoint, request credentials and applicable service version before declaring success.

The final worksheet can be very short. One valid unsigned denial and one valid authorized success for the agreed object may be enough for this narrow change when combined with the saved account policy. Add more cases only when the account has materially different paths, such as a website endpoint or several application identities. More tests are useful when they answer distinct questions, not simply because a longer evidence table looks more impressive.

Disable anonymous access at account scope

After reviewing impact, open the account's Configuration settings and disable Allow Blob anonymous access. Save the change and read the property back. Microsoft's remediation procedure also supports setting allowBlobPublicAccess to false through supported management interfaces. The acting administrator needs the relevant storage-account management permission; a blob-data reader alone cannot change the account policy. ^[2]

Review the chosen administrative role rather than granting broad access to the application. Some storage management roles can obtain account keys, which has separate data-access implications. The runtime consumer should receive the permissions required for its read path, while the operator changing account configuration uses the organization's authorized administration route.

For infrastructure-managed accounts, update the reviewed source definition as part of the same change. A portal correction can be reversed by the next deployment if the source still allows anonymous access. Retain the previous setting and the reason for the change in the normal change record. Rollback should be deliberate and account for data exposure, not automatically restore a permissive value whenever an application reports an error.

Do not create a temporary public exception for the entire account merely to keep one reader working. Identify that reader's actual requirement and complete the approved migration. If an urgent operational exception is necessary, document its scope, affected data, owner and removal condition. The long-term outcome should be an understandable publication or authentication arrangement rather than a forgotten account-wide allowance.

Verify the legitimate reader still works

After the account setting is saved, repeat the anonymous request to the same known blob and confirm the intended denial. Then have the application retrieve the object through its normal authorized path. These results answer different questions: the first checks the restricted access method; the second checks that the approved consumer remains usable. A negative test without the positive test can hide an application outage.

Microsoft Entra access to blob data uses appropriate data roles at an applicable scope. Storage Blob Data Reader can support a read-only consumer, while management Reader does not by itself grant blob-data access. Choose the identity and scope for the actual task. Do not grant Contributor to resolve a blob-read error simply because it is a familiar role name. ^{[4] [5]}

Test from the real application environment. A developer's portal read can use a different identity or authorization method from a workload. Confirm the identity selected by the client and the endpoint it reaches. If the intended path uses a private endpoint, include that network verification rather than testing only from a workstation that can reach the public endpoint.

If the application fails, preserve the exact request context and inspect its authorization mechanism. It may have been relying on anonymous access despite an assumption that a service principal was configured. Correct that application path through the approved design. Do not immediately re-enable anonymous access and report the remediation complete because the setting was briefly disabled.

Source. Microsoft documentation: Remediate anonymous read access to blob data (Azure Resource Manager deployments) - Azure Storage ^[2]; Authorize Blob Access with Microsoft Entra ID - Azure Storage ^[4]; Assign an Azure Role for Blob Data Access - Azure Storage ^[5]; Static website hosting in Azure Storage ^[6].

Method. Original conceptual synthesis of the cited Microsoft documentation. No deployment measurements or risk scores. Reviewed 2026-09-12.

Accessible table and figure data

Figure 2 accessible table

State	Unsigned known-blob request	Approved application request
Before when public	May return the known object	Existing behavior recorded
After account restriction	Denied under applicable service behavior	Succeeds using approved authorization
Separate publishing paths	Website, SAS and caches reviewed separately	No claim of universal network privacy

Figure 2 accessible table

State	Unsigned known-blob request	Approved application request
Before when public	May return the known object	Existing behavior recorded
After account restriction	Denied under applicable service behavior	Succeeds using approved authorization
Separate publishing paths	Website, SAS and caches reviewed separately	No claim of universal network privacy

Download imageDownload table CSV

Handle deliberate public publishing separately

Some files are intentionally public. The useful question is whether public publishing is clearly separated from private application storage. Microsoft's remediation guidance recommends placing content that genuinely requires anonymous access in a separate account reserved for that purpose. This makes the account-level policy easier to understand and prevents a public-download requirement from applying to unrelated private containers. ^[2]

Define what belongs in the publishing account and who can add or change it. A public container should not become an informal transfer area for files that someone intends to delete later. The review should cover the upload process and content ownership as well as the read setting. Public access can be correct for a documented publishing workflow and incorrect for a staging directory using the same configuration.

A shared access signature is not anonymous access in the sense tested by this guide. It is a signed delegation mechanism carried in the request, even when a person opens the link without separately signing in. Disabling anonymous reads does not by itself revoke every existing signed URL or account-key-based client. Review those authorization methods separately when the goal includes withdrawing delegated access. ^[4]

If the application uses account keys, Microsoft's Shared Key guidance explains the additional account setting and service considerations for disallowing that authorization method. Do not change it as an incidental extension of an anonymous-access task. Inventory the affected clients and test the supported replacement path. Each access-method change should have a clear purpose and its own verification. ^[7]

Check the static website endpoint separately

Azure Storage static website hosting has a separate website endpoint and uses the $web container. Microsoft's static-website documentation explains that changing the container's anonymous-access level does not provide the same access control for the website endpoint. Treat the website as a distinct publishing path and inspect whether it is enabled. A blob-endpoint denial should not be presented as proof that the website no longer serves its files. ^[6]

Record both endpoints when static hosting is used. One may be an ordinary blob URL and the other the website hostname presented to readers. Test the path that the website actually uses, including any front-end service or caching layer. The point is not to make the article's scope unlimited; it is to avoid overlooking an explicitly different service behavior that can invalidate a broad privacy claim.

If the site intentionally publishes content, separate that purpose from private application storage. If the content should no longer be public, plan the website or delivery-service change with its owner. The anonymous blob setting alone is not an adequate retirement procedure for every public website path. Verify the user-facing result after the appropriate change.

A hypothetical team may discover that an old documentation site shares an account with internal uploads. That is a useful architecture finding, but it does not justify abruptly deleting the site or its container. Establish which content remains approved for publication, choose a separate arrangement and migrate the consumers. The access check should lead to a controlled correction rather than an unreviewed data removal.

Stop the configuration from drifting back

Once the policy is correct, decide how future changes will be detected or prevented. Keep the account property explicit in infrastructure definitions and review the identities allowed to modify it. An account can lose the intended restriction if a later deployment uses an old template or an operator re-enables anonymous access to solve an unrelated problem.

Use the organization's Azure Policy and configuration-review processes where appropriate, but verify the exact policy behavior before relying on it. An audit policy, a deny policy and a deployment remediation have different effects. The account's actual saved value and a direct test remain useful evidence even when a compliance dashboard reports the resource as compliant.

Review new containers and new applications according to the account's purpose. With account-level anonymous access disabled, a container-level public choice cannot override that restriction. Still, identify why a deployment attempts to create such a setting. It may reveal that a publishing workflow was placed in the wrong account or that an old application template needs correction. ^[2]

Keep telemetry useful without turning it into a collection of unnecessary content. Request paths and authorization categories can support troubleshooting, but log retention and access should follow the application's data-handling requirements. The desired result is an observable policy, not unlimited storage of every file path or request detail merely because it might someday be useful.

Keep the chosen test source stable during the before-and-after check. A VPN change, different proxy or different browser account can alter the path independently of the storage setting. If the source must change, record that fact and repeat the authorized existence check from the new context. The aim is to attribute the observed denial to the reviewed access policy, not to an unrelated connectivity change that happened during the test.

Record the outcome and clean up the test

Keep a concise record of the account ID, relevant container state, anonymous-access property, ordinary blob endpoint and test time. Include the known harmless object's existence, unauthenticated result and intended application's authorized result. If a website endpoint, SAS client or private endpoint was outside the completed scope, state that explicitly.

Remove the harmless test object when it is no longer needed, following the account's retention and recovery settings. Do not remove production containers, disable soft delete or purge retained data to make the account look clean after the review. Cleanup should match the disposable artifact created for the test and preserve unrelated application data.

Use the before-and-after visual to compare the intended access design with the account's saved configuration and observed test results. Record whether the setting changed or already matched the policy. If the account already denied anonymous access, the useful outcome is confirmed behavior and a record that explains why the result is trustworthy. A configuration comparison alone does not establish the account's incident history.

The task is complete when ordinary anonymous blob reads are restricted as intended and the approved consumer still works through a documented authorization path. Keep the wording that precise. It gives an operator a reliable starting point for the next question, whether that concerns signed links, private networking, public website retirement or the permissions of the application itself.