Cloud Misconfiguration.

Cloud misconfiguration is the leading root cause of cloud data breaches: it happens when an administrator, an Infrastructure-as-Code template, or a CI/CD pipeline configures a service in a way that violates security best practices. Typical examples include publicly readable object storage, security groups open to 0.0.0.0/0, missing encryption, disabled logging, default credentials, or overly broad IAM trust policies. Because cloud APIs make it trivial to roll out resources at scale, a single bad template can replicate the same flaw across hundreds of accounts and regions.

The 2019 Capital One breach is the canonical case: a misconfigured web application firewall was vulnerable to server-side request forgery, letting the attacker reach the EC2 instance metadata service (IMDS), steal the WAF role's temporary credentials, and use them to list and copy data from over 700 S3 buckets — about 106 million customer records. Capital One later paid an $80 million penalty to the U.S. OCC and settled litigation for $190 million. AWS's IMDSv2 (session-token-based, hop-limited) directly hardens against this SSRF-to-credentials chain.

Detection and prevention rely on CSPM, IaC scanning (Checkov, tfsec), policy-as-code (OPA, AWS Config, Azure Policy), least-privilege IAM, blocking public access at the account level, and continuous compliance checks tied to ticketing and remediation workflows.

flowchart TD
  A[IaC template / manual change] --> B{Insecure setting?}
  B -->|No| OK[Compliant baseline]
  B -->|Yes| C[Public bucket / open SG / broad IAM]
  C --> D[Exposed to Internet or SSRF]
  D --> E[Attacker steals data or credentials]
  C -. detected by .-> F[CSPM / IaC scan / policy-as-code]
  F --> G[Auto-remediate + ticket]
  G --> OK