Cloud storage misconfiguration rarely becomes dangerous because of one visibly open bucket. The more consequential failures emerge when storage permissions, cloud identities, application credentials, automation, APIs, and configuration changes interact. Together, they create an exploitable path to sensitive data. That distinction matters.
Organizations have spent years improving cloud posture management and applying secure configuration baselines. Yet cloud storage remains embedded across production applications, backups, analytics pipelines, development environments, SaaS integrations, data lakes, and AI workloads. So the question is no longer simply whether a storage resource is public. The more important question is this: who or what can reach the data, and through which trust relationship? What happens if that access is compromised?
Executive TL;DR
- Cloud-storage misconfiguration remains a significant security concern. But current research increasingly places it within a wider problem involving identity, APIs, third-party relationships, and change control.
- Attackers do not need a completely public bucket. Compromised credentials, excessive IAM permissions, and service identities can all provide alternative routes to stored data. So can OAuth tokens, application secrets, and legitimate cloud APIs.
- Configuration posture alone does not reveal the sensitivity of exposed data. Nor does it reveal the effective permissions created by interconnected identities and workloads.
- Continuous monitoring, configuration assessment, logging, data discovery, least privilege, and change control are all necessary. But organizations also need to test whether those controls hold together under realistic attacker behavior.
- Offensive security should validate the complete path to sensitive cloud data, rather than assessing individual settings in isolation.
Why Cloud Storage Misconfiguration Goes Beyond the Open Bucket
Cloud-storage exposure is not a new security problem. What has changed is the environment surrounding it.
The Cloud Security Alliance’s 2026 Top Threats to Cloud Computing report just reshuffled the rankings. Misconfiguration and Inadequate Change Control now sits fifth among the major cloud concerns. That’s down from the top spot in the 2024 survey. Inadequate Identity and Access Management ranks first instead.
Does that mean configuration risk has become unimportant? Not exactly — it means cloud risk is becoming more interconnected. A storage service can be correctly configured against anonymous public access and still be reachable through an overprivileged workload identity. A backup repository can be private while a compromised service principal retains permission to read it. A data lake can enforce authentication while an exposed API key gives an attacker exactly the authentication material required.
What the incident data shows
Google Cloud’s Threat Horizons Report H1 2026 reinforces this shift. For the second half of 2025, the report analyzed a subset of Google Cloud incidents. Misconfiguration accounted for 21% of initial-access activity in that subset, down from 29.4% in the first half. But look at Mandiant’s cloud and SaaS incident-response engagements from H2 2025. Identity-related issues contributed to initial access in 83% of those incidents, and data was targeted in 73% of cloud-related incidents.
These numbers describe different datasets and shouldn’t be treated as universal cloud-breach rates. Together, though, they point to a clear shift: cloud data exposure increasingly sits at the intersection of configuration and identity. This lines up with what we’ve seen across modern credential theft. An attacker doesn’t necessarily need to defeat a security control at all. If they can inherit an identity or access path the environment already trusts, that’s often enough.
How Cloud Storage Misconfiguration Becomes an Attack Path
MITRE ATT&CK maps adversary collection from cloud storage under technique T1530: Data from Cloud Storage. The technique covers data obtained from IaaS, SaaS, and office-suite storage environments. It includes scenarios involving anonymous access, overly broad permissions, leaked credentials, and cloud APIs.
From an offensive-security perspective, the important concept isn’t the individual misconfiguration. It’s the chain.
1. Discovery exposes the opportunity
Publicly reachable storage can be identified through ordinary internet reconnaissance. Think search and indexing services, leaked URLs, source repositories, application code, exposed API endpoints, and cloud-resource enumeration. Attackers don’t need to know in advance that a particular bucket contains valuable information — discovery can increasingly be automated. The initial finding may reveal only a resource name, an endpoint, or a credential. That can be enough to begin mapping the environment.
2. Identity turns exposure into access
The next question is whether the attacker can authenticate as something the storage service trusts. That identity could belong to a user, application, workload, automation pipeline, integration, service account, service principal, or managed identity. This is where storage security becomes inseparable from IAM.
A resource may reject anonymous access while accepting requests from an identity with excessive permissions. If an attacker compromises that identity, the technical result can look completely legitimate from the storage platform’s perspective. The same issue appears in service principals and managed identities. Non-human identities can reduce dependence on human credentials. But poorly scoped permissions can still create indirect access to sensitive cloud resources. So can control over the workload behind an identity.
3. Effective permissions matter more than the visible configuration
Cloud authorization rarely consists of one setting. Access may depend on identity policies, resource policies, inherited roles, group membership, and application permissions. It may also depend on cross-account trust, federation, conditional access, storage access keys, shared links, API permissions, or workload identities. Individually, each control may appear reasonable. Together, they can create an unintended path.
This mirrors the broader problem explored in our analysis of Microsoft Entra ID attack paths. Visible privilege doesn’t always reflect effective privilege. The shortest route to sensitive data may run through several trusted relationships rather than through one obviously privileged account.
So for security teams, this changes the assessment question. It’s no longer “Is this bucket private?” It’s “Which identities can ultimately read, modify, copy, share, or reconfigure this data?”
How Attackers Abuse Cloud Storage Configuration After Initial Compromise
Cloud storage misconfiguration shouldn’t always be treated as a static mistake that exists before an attacker arrives — configuration can also become part of the attack itself. MITRE documents adversary procedures involving cloud-storage enumeration and collection. It also documents activity in which attackers altered Azure Storage configuration to make previously inaccessible storage available for subsequent access.
That distinction is important. An organization might begin with a correctly configured storage resource. Suppose an attacker compromises an identity capable of changing network rules, access policies, sharing settings, or storage permissions. They can potentially create the exposure needed for the next stage of the intrusion. The resulting breach path looks like this: identity compromise → configuration change → storage access → data collection.
This is why configuration-change privileges deserve the same scrutiny as direct read access. An identity that can’t download sensitive objects isn’t automatically safe. If it can modify the policies controlling those objects, it may still represent a path to the same outcome.
The Football Australia Breach Shows How Small Failures Combine
The 2024 Football Australia incident is a useful example, because it wasn’t simply an isolated public-storage mistake. According to a Cloud Security Alliance case study, researchers identified plaintext AWS access keys embedded in website source code. Those credentials provided access to 127 digital storage containers. One accessible S3 bucket contained personal information. Other exposed material reportedly included purchase information, source code, and infrastructure-related data.
CSA identified multiple interacting failures: storage misconfiguration, inadequate IAM, and insecure software development. Also on the list: long-term credentials embedded in code, and unauthenticated resource sharing. That combination is more instructive than the open bucket itself. Consider how each piece played a role. Credential exposure made the storage reachable. The access model determined what those credentials could reach. Storage configuration determined what data became accessible. Weak development and change-control practices let the whole condition exist in the first place.
The breach path was created by relationships between controls, not by a single setting. Isn’t that exactly the kind of risk a point-in-time configuration review tends to miss?
Configuration Drift Makes Yesterday’s Secure State Irrelevant
Cloud environments change continuously. Development teams create resources. Infrastructure-as-code pipelines modify them. Applications generate new datasets. Third-party integrations receive permissions. Temporary exports become permanent. Projects get abandoned. Storage gets replicated between regions and accounts. Permissions accumulate as operational requirements evolve.
NIST’s July 2026 draft revision of SP 800-209 notes that modern storage architecture has increased management complexity. With it comes a higher probability of configuration errors and associated security threats. Its recommendations address access control, authorization, authentication, configuration management, auditing, encryption, and data protection.
The operational implication is straightforward: a secure configuration is a state, not a permanent property. A resource that passed review three months ago can look different today. It may now have a new access policy, identity relationship, data classification, application dependency, or external integration. That’s what makes configuration assurance a continuous process rather than a one-time checkbox.
Why CSPM Alone Cannot Catch Cloud Storage Misconfiguration
Cloud Security Posture Management can identify infrastructure-level weaknesses: public storage, permissive security policies, missing encryption, deviations from configuration standards. That visibility matters. But does a configuration finding actually tell leadership how serious a given cloud storage misconfiguration really is?
Not on its own. Two identically misconfigured storage resources can represent radically different business exposure. One may contain public marketing assets. The other may hold customer records, intellectual property, authentication material, backups, or regulated information.
This is where data-centric approaches such as Data Security Posture Management add another layer of context. Cloudflare’s overview of DSPM draws the distinction clearly: CSPM primarily evaluates the security posture of cloud infrastructure. DSPM focuses on the data itself. That means where it resides, how sensitive it is, who can access it, and whether that access creates exposure.
The practical objective shouldn’t be deploying another dashboard. It should be connecting configuration context, identity context, and data context. Take a public bucket containing non-sensitive assets, and a private bucket reachable by dozens of excessive machine identities. Neither should automatically be prioritized based on the word “public.” Risk should reflect the attacker’s actual path to valuable data instead.
Continuous Monitoring Must Include Evidence, Not Assumptions
The governance problem extends beyond commercial environments. In June 2026, the U.S. Government Accountability Office reviewed eight selected cloud systems across four federal agencies. Only three of the eight fully implemented the continuous-monitoring practices GAO assessed. The remaining five only partially implemented them.
GAO’s criteria included configuration assessments, vulnerability management, and collection and review of audit logs. It also covered continuous-monitoring plans and review of security information supplied by cloud providers. GAO warned that weak continuous monitoring can leave organizations with reduced assurance that security controls are actually operating as intended. The sample is limited and shouldn’t be generalized to enterprise cloud environments broadly. Still, the underlying control deficiencies are instructive.
What cloud storage misconfiguration means for CISOs
Having a policy that requires secure cloud storage isn’t the same as continuously verifying it. Having logging enabled isn’t the same as reviewing the logs. Having a CSPM platform isn’t the same as knowing whether its findings get fixed. Remediation has to happen before an attacker can exploit them. Security governance has to measure the effective state of the environment, not just the existence of controls.
What Security Leaders Should Require to Stop Cloud Storage Misconfiguration
Turning this into practice raises a fair question. What should security leaders actually require from their teams and their testing programs?
Know where sensitive data actually lives
Cloud inventories should extend beyond production resources. Organizations need visibility into backups, archived datasets, replicated environments, developer copies, analytics repositories, abandoned projects, temporary exports, and SaaS-connected storage. Security teams can’t prioritize exposure if they don’t understand the value of the data behind the finding.
Map identities to data, not only identities to roles
Traditional IAM reviews can identify privileged accounts, but cloud-storage testing should go further. Organizations should determine which human and non-human identities can ultimately interact with sensitive data. That includes access through inherited permissions, groups, application credentials, workload identities, cross-account relationships, and APIs. The objective is to understand effective access.
Reduce dependence on long-lived credentials
Static cloud keys, application secrets, embedded credentials, and poorly governed tokens all create durable access paths. Where supported, organizations should favor shorter-lived and context-aware authentication mechanisms. They should also tightly scope what workload identities can access. Credential discovery should extend into source repositories, deployment pipelines, scripts, logs, configuration files, developer environments, and backups.
Treat configuration changes as security events
Changes to storage policies, public-access settings, sharing permissions, and network restrictions can materially alter exposure. So can encryption configuration, logging, and IAM relationships. High-impact changes should generate sufficient telemetry for security teams. They need to know what changed, who changed it, and whether the resulting access was expected.
Test data exfiltration, not just data access
Being able to read one object proves exposure. It doesn’t establish the full business impact. Security validation should also examine whether an attacker could enumerate large datasets, perform bulk downloads, or use legitimate cloud APIs. Could they create copies or generate temporary access mechanisms? Could they move information between accounts, or disable the visibility needed to detect that behavior? This is where red teaming and adversary simulation can add value beyond a configuration audit. The assessment tests whether multiple weaknesses can be chained toward an operational objective.
Validate remediation under realistic conditions
Fixing the finding that initially exposed the data may not remove every path to it. An excessive identity permission, leaked credential, forgotten replica, inherited policy, or alternate API route may still remain. Penetration testing can help organizations validate whether remediation actually changes what an attacker can accomplish. That’s different from merely changing what a configuration scanner reports.
Cloud Storage Misconfiguration Is an Attack-Path Problem
The cloud storage misconfiguration conversation needs to move beyond public buckets. A bucket can be private and still be exposed. An identity can appear low privilege and still provide a route to valuable data. A configuration can be secure today and unsafe after the next deployment. A monitoring platform can identify thousands of findings while still failing to explain which combinations create a practical breach path.
So what’s the real objective here? Not perfect configuration in isolation. It’s continuous assurance that identities, permissions, workloads, configurations, and data relationships don’t combine into attacker-usable paths.
That’s where offensive security becomes particularly valuable. A configuration assessment asks whether a control matches the expected baseline. An attacker asks whether there’s another way to reach the objective. Organizations need to be able to answer both questions.
Frequently Asked Questions (FAQs)
What is a cloud storage misconfiguration?
A cloud storage misconfiguration is a security-relevant setting, or combination of settings. It creates unintended access, or weakens protection around stored data. Examples include public access, excessive permissions, insecure sharing, weak IAM policies, and exposed credentials. Inadequate logging and configuration changes that make previously restricted storage reachable count too.
Are public cloud buckets still a major security concern?
Yes, but public exposure represents only one form of risk. Sensitive data can also become accessible through compromised identities, service accounts, or workload permissions. Shared credentials, application integrations, APIs, and cross-account trust relationships open other doors.
Why are IAM and cloud storage security closely connected?
Cloud storage platforms rely heavily on identity and authorization systems to determine who or what can access data. A storage resource may be configured to reject anonymous users while still granting excessive access to trusted identities. Compromising one of those identities can therefore give an attacker legitimate access to the data.
What is the difference between CSPM and DSPM?
CSPM generally focuses on cloud infrastructure and configuration posture. DSPM focuses on the security context of the data itself. That includes where sensitive information resides, who can access it, and whether those relationships create exposure. The two approaches address different parts of the same problem.
Why should cloud storage be included in offensive-security testing?
Configuration reviews can identify individual weaknesses. But attackers frequently combine identity compromise, excessive permissions, exposed secrets, APIs, and cloud configuration changes. Offensive testing helps determine whether those weaknesses can be chained into meaningful access, collection, or exfiltration of sensitive information.
About wizlynx group
wizlynx group is a CREST-accredited offensive security company headquartered in Switzerland, operating across Europe, North America, Latin America, and Asia. wizlynx group specialises in penetration testing, red teaming, adversary simulation, social engineering, and advanced security assessments for enterprise clients.