Configure buckets so they are not publicly readable or writable, and review any policy or access-control setting that grants broad object access. Public buckets can expose sensitive data or allow unauthorised uploads, so practitioners should routinely check bucket access settings, tenancy policies and object-level permissions for unintended public exposure.
What “public” means in Oracle Cloud Object Storage
A bucket becomes public when Oracle Cloud access controls allow anonymous or broadly shared principals to read objects, and in some cases to write them. In practice, the issue is rarely just the bucket setting itself, but the combination of bucket visibility, IAM policy scope, and any object-level permission that bypasses the intended private default. Treat “public” as an exposure state, not a single checkbox.
For a secure baseline, validate both the bucket and the objects inside it. A bucket can appear private while object access remains too broad through policy inheritance, pre-authenticated access, or an overly permissive tenancy rule. That is why a review has to include the effective access path, not only the console display.
When you map this to cloud misconfiguration, the control objective is to keep storage private by default and remove any path that makes object content reachable outside the intended trust boundary. The Cloud Misconfiguration Guide is useful here because it covers public storage, policy-as-code guardrails, and drift detection for exposed cloud resources.
Which settings usually make a bucket public
The most common failure is an access policy that is broader than intended, such as allowing all users, all authenticated users, or a whole compartment or tenancy to read objects when only a narrow application identity should have access. Public exposure can also come from object ACLs, pre-authenticated requests, or upload permissions that were granted for convenience and never removed.
In Oracle Cloud, review the bucket’s access mode, any IAM policy statements tied to the compartment or tenancy, and object-level permissions separately. The practical question is whether a user with no business need, or an unauthenticated requester, can fetch, list, or upload content. If the answer is yes for any of those paths, the bucket is effectively public.
That is why practitioners should check configuration drift and inherited policy changes over time, not only during the initial build. The Oracle Cloud breach claim 2025 is relevant as a reminder that cloud exposure often travels with broader identity and control-plane issues, while the Codefinger S3 ransomware 2025 shows how exposed object storage can become an extortion target once an attacker has access.
How to keep object storage private by default
The safest pattern is to start private and then grant the minimum access needed for a specific workload or user role. Use narrowly scoped policies, separate public content into a dedicated location if it truly must exist, and review whether object delivery should happen through an application layer rather than direct anonymous access. That keeps the bucket itself off the public internet.
Where possible, prefer short-lived and tightly scoped access mechanisms over standing public exposure. A public bucket is an attractive shortcut, but it creates hard-to-control blast radius because anyone who discovers the path can consume the data, and some misconfigurations also permit tampering. For sensitive data, that becomes both a confidentiality and integrity problem.
Cloud storage security is easier to maintain when guardrails are automated. The AWS Security Guide and the Microsoft Azure Security Guide both reinforce the same operational lesson: private-by-default storage, restrictive policy design, and periodic review of permissions are more reliable than relying on manual exception handling.
Risk and Threat Considerations
Public object storage creates immediate exposure because data can be read, copied, indexed, or redistributed without any authentication event that you would normally log as an access request. If write access is also exposed, an attacker can poison content, plant malicious files, or use the bucket as a staging point for further abuse.
Failure mechanism: A broad policy, inherited permission, or object-level grant turns a private bucket into an anonymously reachable resource, and the exposure persists until the setting is found and reversed.
Impact: Sensitive data can be disclosed, altered, or used as a launch point for extortion, fraud, or follow-on compromise, especially if the bucket stores backups, credentials, logs, or application payloads.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Bucket publicness depends on access policy scope and object authorization. |
| Recommendation — Restrict bucket and object access to least privilege and remove broad read or write grants. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Public buckets fail when access enforcement allows unauthorized object access. |
| Recommendation — Enforce object access rules so only authorized identities can read or write. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Public exposure is an access-control failure in cloud storage permissions. |
| Recommendation — Define and apply access rules that prevent public object storage exposure. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | This is a permission-management problem requiring regular review of access paths. |
| Recommendation — Review and revoke overly broad storage permissions on a recurring basis. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | Public storage often results from unmanaged or overbroad identities and access paths. |
| Recommendation — Audit cloud identities and revoke any access that can make storage public. | ||
Practitioner Guidance
What to verify: Confirm the effective access path, not just the bucket label. If a test request can retrieve an object without the intended identity and role path, treat the bucket as exposed even if the console suggests partial restriction.
Common mistake: Teams often fix the bucket flag but miss the object permissions, tenancy policy, or pre-authenticated access path that still makes content reachable. The control is only effective when every route to the object is aligned with the intended exposure model.
Practitioner takeaway: The decision is not whether a bucket “looks private,” but whether any unauthorised principal can actually read or write its objects; validate that end-to-end, then keep it enforced through review and drift detection.
Related resources from NHI Mgmt Group
- How should security teams prevent public exposure of cloud storage buckets in infrastructure as code workflows?
- How do you enforce public access prevention on Google Cloud Storage buckets?
- How do you prevent Google Cloud Storage buckets from being publicly accessible?
- How do you audit who holds the Google Cloud Storage Object Viewer role?