Set Swift containers to private and verify that container ACLs do not allow anonymous reads or writes. Publicly exposed containers can leak stored objects or accept unauthorised uploads, so administrators should review container access controls and remove broad permissions from any container that should remain tenant-only.
How Swift container privacy is enforced in practice
In OpenStack Swift, the control point is the container access policy, not the object names themselves. A private container should deny anonymous listing, reads, and uploads unless an authenticated tenant or service principal has been granted a specific permission. That means the first check is whether the container is marked private and whether any ACL, referrer rule, or policy override has widened access beyond the intended tenant boundary.
For operational review, treat every container as a separate exposure surface. Public access is usually created by drift, a convenience change, or an inherited permission that was never removed. If a container must remain tenant-only, verify the effective policy, not just the intended policy, because a single broad ACL can turn otherwise private objects into openly retrievable data.
Swift also requires you to think about write exposure, not only read exposure. Anonymous or overly broad write permission can let an external party upload content, poison downstream workflows, or use the container as an unauthorised staging location. The safest assumption is that any container exposed beyond the tenant boundary should be treated as a configuration defect unless there is a documented business need and compensating control.
What to check when a container should stay private
Start with the container itself, then trace how access is granted through accounts, tokens, or proxies that sit in front of it. If the container is supposed to be private, confirm that the effective ACL does not include anonymous access and that no inherited setting from a higher-level policy is re-opening the container. This is especially important when containers are created by automation, because default permissions can be copied forward unnoticed.
Review the operational path that leads to public exposure. Common failure points include permissive ACL templates, test containers promoted into production, temporary access that was never revoked, and storage endpoints exposed through broader network access than the data owner expected. A container can be technically private in one layer and still become public if the surrounding access path allows unauthorised retrieval.
For a broader cloud configuration lens, the same mistake pattern is covered in the Cloud Misconfiguration Guide, which is useful when you are checking whether storage exposure is part of a wider control drift problem. If you also want a cloud-control view that connects storage exposure to permission hygiene, the Top 10 Cloud Security Risks resource helps frame why public storage and over-broad access often appear together.
Where container exposure is part of a larger OpenStack or cloud hardening effort, the AWS Security Guide is still useful as a comparative reference for storage access discipline, because the underlying lesson is the same: do not rely on default openness, and continuously verify the effective access state.
Why public containers create both data exposure and abuse risk
Public containers are risky because they remove the need for an attacker to compromise a user account before reaching the data. If the container is readable, the attacker can enumerate and exfiltrate objects directly. If the container is writable, the attacker can upload malicious content, embed poisoned artefacts, or abuse the storage path as a distribution point for other attacks.
The threat is not limited to one-off disclosure. Public object storage often becomes durable exposure because search engines, shared links, scripts, or forgotten integrations can continue to reference the container long after the original owner stopped paying attention to it. That makes it important to treat public access as a standing security condition, not a temporary convenience setting.
For defensive context, NIST’s container security guidance is useful because it reinforces that exposure control must be deliberate across the full deployment path, not assumed from the service name alone. See NIST SP 800-190 Container Security for the broader pattern of controlling access, exposure, and runtime trust boundaries around containerised services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Controls who can read or write Swift containers. |
| AC-6 — Least Privilege | Limits who can grant or inherit broad container permissions. | |
| Recommendation — Enforce container access rules so anonymous users cannot retrieve or upload objects. Restrict storage permissions to the minimum required for each tenant and service. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Covers managing and reviewing account and resource access to storage. |
| Recommendation — Review and remove broad storage access paths that make containers publicly reachable. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Applies because container privacy depends on enforced access control. |
| Recommendation — Verify authentication and access control settings before trusting a Swift container as private. | ||
Practitioner Guidance
What to verify: Confirm the container’s effective ACL in the live control plane, then test it as an unauthenticated user. If the container should be tenant-only, verify both read and write behavior, because blocking reads while leaving uploads open still creates exposure.
Decision rule: If a container must be reachable outside the tenant boundary, treat that as an exception that needs documented ownership, narrow scope, and periodic review. If no such requirement exists, remove public access immediately rather than relying on obscurity or unshared URLs.
What good looks like: Private containers deny anonymous listing and object access, inherited permissions are reviewed before release, and any intentional exposure is explicit, time-bounded, and monitored. The container should not become public simply because a template, proxy rule, or automation job defaulted to permissive settings.
Practitioner takeaway: The real control is not “hide the bucket,” it is “prove the effective policy is private and keep it that way as the environment changes.”
Related resources from NHI Mgmt Group
- How do you prevent anonymous public access to Azure Blob Storage containers?
- How do you prevent Oracle Cloud Object Storage buckets being public?
- How do you enforce public access prevention on Google Cloud Storage buckets?
- How should security teams decide whether JIT access is safe for non-human identities?