5 Cloud Security Mistakes That Get Companies Breached (And How to Fix Them)

Mistake 1: Misconfigured S3 Buckets

This is the oldest one in the book and it still happens. S3 buckets set to public read, or worse, public write, have leaked everything from health records to government documents. The issue is usually not malice on the developer side. It is that "public" is sometimes the default or was toggled during a debugging session and never reverted.

AWS now blocks public access by default at the account level, which helps. But that setting can be overridden per bucket, and many orgs running older infrastructure have never audited the state of their buckets. The fix is not just enabling the block-public-access flag. You need continuous scanning. Tools like AWS Config rules, Prowler, or a purpose-built CSPM will catch newly created buckets that drift from your baseline. Run a scan today and you will likely find at least one you did not know about.

Mistake 2: Overpermissioned IAM Roles

Back to Capital One: the attacker used a server-side request forgery vulnerability to make the EC2 instance call the AWS metadata endpoint. That metadata endpoint returned temporary credentials for the IAM role attached to the instance. That role had S3 read permissions across the entire account. Game over.

The principle of least privilege sounds obvious, but in practice most teams give roles broad permissions to "get things working" and never tighten them. AWS IAM Access Analyzer and tools like PMapper can map out which roles can escalate their own privileges or reach sensitive resources transitively. The goal is to ensure that a compromised compute instance can only access exactly what it needs, nothing more. Review your IAM policies quarterly. If a role has wildcard actions or resources, that is a finding.

Mistake 3: Exposed Metadata Endpoints

The EC2 Instance Metadata Service (IMDS) has been a persistent attack vector for years. IMDSv1 allows any process on the instance to query credentials without authentication. IMDSv2 requires a session-oriented token, which blocks most SSRF-based attacks. AWS has been pushing IMDSv2 for years, but plenty of organizations are still running IMDSv1 because migrating requires testing your application code and nobody wants to break production.

The fix is straightforward: enforce IMDSv2 via instance metadata options and add an SCP at the organization level that prevents launching new instances with IMDSv1 enabled. On the application side, treat any user-supplied URL that gets fetched server-side as a potential SSRF vector. Block requests to 169.254.169.254 at the WAF layer and validate URL schemes before fetching.

Mistake 4: No Encryption at Rest

Encryption at rest is not a silver bullet. If an attacker has valid credentials to your AWS account, they can decrypt your data just as easily as you can. But encryption at rest is a compliance requirement for PCI DSS, HIPAA, and SOC 2, and it provides real protection against physical media theft and certain insider threats.

The common failure mode here is not skipping encryption entirely. It is using it inconsistently. A team encrypts their RDS database but forgets the EBS volumes, or encrypts S3 buckets but stores the KMS key policy with overly broad access. Map every data store in your environment and verify encryption is on. Use AWS Config managed rules like "encrypted-volumes" and "rds-storage-encrypted" to flag violations automatically. For key management, keep your KMS keys in a separate account from your data and rotate them annually at minimum.

Mistake 5: Inadequate Logging and No Alerting

The average time between a breach occurring and detection is still measured in weeks or months across the industry. That gap exists because most teams either do not have logging turned on for critical resources, or they have logging but nobody is watching it. CloudTrail should be enabled in every region, in every account, with log file integrity validation on. S3 server access logging should be on for sensitive buckets. VPC flow logs should be on for any VPC that touches the internet.

But logging without alerting is just expensive storage. You need to define what "suspicious" looks like for your environment. A root account login at 3 AM is suspicious. A single IAM role making hundreds of S3 ListBucket calls across accounts in five minutes is suspicious. GuardDuty covers many of these patterns automatically. For custom detections, pipe CloudTrail to a SIEM and build rules around your specific threat model. If you do not have a SIEM, even a Lambda function that watches for root logins and pages your on-call is better than nothing.

The Common Thread

None of these mistakes require a sophisticated attacker to exploit. Public buckets are found by automated scanners running 24/7. Overpermissioned roles get abused by attackers who are already in via a phishing email. Unencrypted data shows up in breach disclosures that damage customer trust for years. The fix for all five is the same: continuous, automated verification. Manual audits done once a quarter catch things as they were, not as they are.

A CSPM running continuously is not a luxury for large enterprises. It is the baseline. If you are building in the cloud and you do not have automated posture management in place, you are essentially trusting every developer, every deployment, and every configuration change to be correct the first time. That is not a reasonable assumption.