Cloud misconfigurations are the leading cause of data breaches in cloud environments. Not sophisticated zero-days, not advanced persistent threats — simple misconfigurations like public S3 buckets, overly permissive IAM policies, and unencrypted databases.
The problem is scale. A single AWS account can have thousands of resources, each with its own configuration. One mistake in one resource can expose everything.
65%
of Cloud Breaches from Misconfiguration
$4.4M
Average Cost of Cloud Breach
200+
Days Average Detection Time
80%
of Orgs Had Cloud Incident in 2025
The Top Misconfigurations
1. Public Storage Buckets
criticalThe most common and most damaging cloud misconfiguration — public storage buckets exposing sensitive data:
Public Storage by Provider
AWS S3
S3 buckets default to private, but a single misconfigured bucket policy or ACL can make the entire bucket public. Common mistake: using "Principal": "*" in a bucket policy for a specific use case, then forgetting to restrict it.
Google Cloud Storage
GCS buckets with allUsers or allAuthenticatedUsers permissions. The "allAuthenticatedUsers" permission is particularly deceptive — it means any Google account, not just your organization's accounts.
Azure Blob Storage
Storage accounts with "Allow Blob public access" enabled. Container-level public access settings that override private defaults. Anonymous read access to containers and blobs.
🛑It Happens to Everyone
Capital One's 2019 breach exposed 100 million customer records through a misconfigured WAF that allowed SSRF to the EC2 metadata service, accessing IAM credentials that had overly broad S3 permissions. As we covered in SSRF attacks, server-side request forgery and cloud misconfigurations are a devastating combination.
2. Overly Permissive IAM
criticalIdentity and Access Management (IAM) misconfigurations grant excessive permissions:
Wildcard permissions
IAM policies using "Action": "" or "Resource": "" grant far more access than intended. A developer role with s3:* can delete production buckets, not just read from them.
Unused permissions accumulate
Permissions granted for a one-time task are never revoked. Over months, roles accumulate permissions they no longer need. This violates least privilege and increases blast radius.
Cross-account trust
IAM roles that trust external accounts without condition restrictions. An attacker who compromises the trusted account can assume your role and access your resources.
Service account key exposure
Long-lived service account keys (AWS access keys, GCP service account JSON) committed to code repositories, stored in environment variables, or shared in chat. As covered in our CI/CD security post, secrets in pipelines are a major attack vector.
3. Network Exposure
highCommon Network Misconfigs
- •Security groups allowing 0.0.0.0/0 on SSH/RDP
- •Database ports (3306, 5432, 27017) open to internet
- •Default VPC with public subnets used for everything
- •No network segmentation between environments
Secure Configuration
- •SSH/RDP restricted to VPN or bastion host IPs only
- •Databases in private subnets with no public IP
- •Custom VPCs with public/private subnet separation
- •Separate VPCs or accounts for dev/staging/prod
4. Encryption Gaps
highEncryption Misconfigurations
Data at rest
Unencrypted EBS volumes, RDS instances, S3 objects. Default encryption should be enabled at the account level, but many organizations haven't configured this. GCP encrypts by default; AWS and Azure require explicit configuration for some services.
Data in transit
Internal services communicating over HTTP instead of HTTPS. Load balancers terminating TLS but forwarding to backends over HTTP on a shared network. As we covered in Security Headers, TLS configuration itself can have vulnerabilities.
Key management
Encryption keys stored alongside the encrypted data (defeats the purpose). KMS keys with overly permissive policies. No key rotation configured. Using default AWS-managed keys instead of customer-managed keys for sensitive workloads.
5. Logging and Monitoring Blind Spots
highYou can't detect breaches if you're not logging:
CloudTrail / Audit Logs
AWS CloudTrail, GCP Cloud Audit Logs, Azure Activity Log — must be enabled for all regions and all services. Many organizations only enable logging in their primary region, leaving other regions unmonitored.
Log Storage Security
Logs stored in a bucket that can be deleted by the same accounts being monitored. Attackers who gain access will delete logs to cover their tracks. Use a separate logging account with immutable storage.
Alert Configuration
Logs exist but no one is monitoring them. Set up alerts for high-risk events: root account usage, IAM policy changes, security group modifications, unusual API calls.
Retention
Logs with 30-day retention are useless for investigating breaches that went undetected for 200+ days. Retain security logs for at least 1 year.
Provider-Specific Pitfalls
Provider-Specific Gotchas
AWS
EC2 Instance Metadata Service (IMDSv1) allows any process on the instance to retrieve IAM credentials via a simple HTTP call. IMDSv2 requires a session token, mitigating SSRF-based credential theft. EC2 Image Builder and Lambda functions may still default to IMDSv1.
GCP
Default service accounts on Compute Engine instances have Editor-level permissions — far too broad. Custom service accounts with minimal permissions should be used instead. Also: GCP's VPC firewall rules apply to the entire project, not individual VPCs, which causes unexpected exposure.
Azure
Storage account access keys grant full access to all data in the account. If leaked, there's no way to restrict what an attacker can access — you must rotate both keys. Use Azure AD authentication with RBAC instead of access keys wherever possible.
The Cloud Security Checklist
Identity
Enforce MFA on all human accounts. Use short-lived credentials for machines. Implement least privilege. Review IAM policies quarterly. No wildcard permissions.
Network
Default-deny security groups. Private subnets for databases and internal services. VPN or bastion for administrative access. Network segmentation between environments.
Data
Enable default encryption for all storage services. Use customer-managed KMS keys for sensitive data. Audit public access settings on all storage buckets monthly.
Monitoring
Enable all audit logging. Store logs in an immutable, separate account. Alert on high-risk events. Retain for at least 1 year.
💡Infrastructure as Code
Define your infrastructure in code (Terraform, CloudFormation, Pulumi) and scan it before deployment. Tools like tfsec, checkov, and Bridgecrew catch misconfigurations before they reach production. This is part of the shift-left security approach we discuss in our CI/CD security guide.
How Cloud Misconfigs Connect to Application Security
Cloud misconfigurations amplify application-level vulnerabilities. An SSRF vulnerability becomes critical when the server can reach the cloud metadata service. A SQL injection becomes devastating when the database is unencrypted and the compromised credentials have broad IAM permissions.
This is why we test both application and infrastructure layers. Our Web Security Auditor identifies application-level vulnerabilities, while our expert review includes infrastructure configuration assessment for teams running in cloud environments.
Worried about cloud misconfigurations? Our Web Security Auditor tests your application layer, and our expert review includes cloud configuration assessment. Get a comprehensive security review.