Ask security researchers what causes the most cloud data breaches, and the answer is rarely a sophisticated zero-day exploit. Far more often, it's something mundane: a storage bucket left open to the public internet, a permission set too broadly, or default credentials that were never changed. Cloud misconfiguration remains one of the most common — and most avoidable — causes of exposed data.

The usual suspects

A handful of mistakes show up again and again in breach post-mortems:

  • Public storage buckets — object storage set to allow public read or write access, sometimes intentionally for a temporary purpose and then never locked back down.
  • Over-permissioned identities — service accounts or user roles granted far broader access than the task actually requires, turning a single compromised credential into a much bigger problem.
  • Exposed management interfaces — databases, dashboards, or APIs reachable from the open internet that should only be accessible from within a private network.
  • Unrotated default credentials — test or setup credentials that were meant to be temporary but were never removed or changed.

Why it keeps happening

Part of the problem is structural. Cloud providers operate on a shared responsibility model: the provider secures the underlying infrastructure, but the customer is responsible for how they configure their own resources on top of it. That division isn't always well understood, especially in organizations moving fast and provisioning new cloud resources frequently without a consistent review process.

Speed is often the other half of the equation. Developers under pressure to ship a feature may open a service more broadly than necessary "for now," intending to tighten it later — and later doesn't always come before an automated scanner run by an attacker finds it first. Automated internet scanning has made the window between a misconfiguration appearing and it being discovered by someone with bad intentions much shorter than it used to be.

What actually reduces the risk

Security teams describe the fix as more about process and defaults than a single tool, including:

  • Cloud security posture management (CSPM) tools that continuously scan for public exposure, risky permissions, and drift from approved configurations.
  • Least-privilege defaults baked into how new resources are provisioned, rather than relying on someone remembering to lock things down after the fact.
  • Infrastructure as code, so configurations are defined, reviewed, and version-controlled rather than changed manually and inconsistently.
  • Regular access reviews to catch permissions that were appropriate when granted but no longer match what an account actually needs.

None of these are exotic defenses. That's largely the point security teams make: closing the gap on cloud misconfiguration is less about buying new technology and more about consistently applying practices that already exist, before a scanner — friendly or otherwise — finds what was left open.