When blob containers allow public access, anonymous users can read objects without authentication. That breaks the basic expectation that storage should only be available to approved identities and it can expose data unintentionally. Security teams should require authentication for each container and review any public setting as an exception that needs a clear business justification.
Why public access changes the storage trust model
Azure blob public access does not just widen convenience, it changes the trust model for the container. Once anonymous read is allowed, the container no longer behaves like a resource protected by authenticated access decisions, which means any object placed there must be treated as externally retrievable. That is why public access is usually a deliberate exception, not a default setting.
The practical break is simple: access control is no longer the control that decides who can see the data. If the container is exposed, the only thing protecting the objects is obscurity and the absence of a direct link, which is not a security boundary. For storage that contains anything sensitive, that is a material loss of confidentiality and governance.
What is most likely to fail in practice
Public containers often fail through accidental data exposure, stale objects that were never meant to be shared, and content copied into the wrong environment. They also break the assumption that every read is attributable to an approved identity, which complicates audit trails and incident investigation. In cloud environments, that can quickly turn a small misconfiguration into broad exposure.
One useful comparator is the control emphasis in NIST SP 800-190 Container Security, which treats exposed storage, image content, and runtime access as security-relevant surfaces. For Azure storage, the same principle applies: if a container is public, the content needs to be assumed exposed unless proven otherwise. The broader pattern is reinforced by Docker Hub Auth Secrets in Container Images and Microsoft SAS Key Breach, both of which show how weak storage exposure assumptions can turn into data disclosure at scale.
OWASP Non-Human Identity Top 10 is also relevant when public storage is used alongside automated pipelines, because storage settings, tokens, and service access are often managed together. A public blob container can become part of a wider trust failure if teams confuse convenience access with controlled access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 3 — Data Protection | Public blob access can expose data that should remain restricted. |
| 6 — Access Control Management | Anonymous reads bypass normal access enforcement for the container. | |
| Recommendation — Restrict public storage exposure and classify data before enabling anonymous access. Require authenticated access and review any public container as an exception. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The issue is a loss of access restriction for stored objects. |
| PR.DS — Data Security | Public access directly increases the chance of unintended data exposure. | |
| Recommendation — Enforce access restrictions so only approved identities can read storage objects. Protect stored data by preventing anonymous disclosure paths. | ||
| NIST Zero Trust (SP 800-207) | 4 — Access Enforcement | Public containers bypass policy-based access enforcement for reads. |
| Recommendation — Apply policy enforcement so storage access is evaluated before disclosure. | ||
| NIST SP 800-63 | 3 — Digital Identity Guidelines | Public storage breaks the assumption that reads are tied to authenticated identities. |
| Recommendation — Bind storage access to authenticated identity and avoid anonymous retrieval paths. | ||
| OWASP Non-Human Identity Top 10 | 1 — NHI Discovery and Inventory | Storage access settings often interact with automated identities and tokens. |
| Recommendation — Inventory automated access paths alongside any storage that is meant to be private. | ||
Practitioner Guidance
What to verify: Confirm whether any blob container is intentionally public, and verify the business owner can explain why anonymous read is required. If the answer is vague, temporary, or historical, treat the setting as a control exception that needs removal or formal review.
Decision rule: If a container holds operational data, customer data, credentials, exports, logs, or internal documents, default to private access and require authenticated reads. Reserve public access for assets that are meant to be public by design, such as truly public marketing content.
What good looks like: Teams can inventory public containers, name an owner for each one, and prove that exposure is intentional, reviewed, and limited to the minimum set of objects. Public access should be the exception state, not an inherited default from deployment scripts or legacy storage patterns.
Practitioner takeaway: The key question is not whether Azure supports public containers, it is whether the data remains safe if anyone can read it. If the answer depends on “people will not find it,” the control has already failed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
