The Most Common AWS Security Misconfigurations (and Fixes)

AWS gives you powerful building blocks and a lot of configuration surface. These are the misconfigurations we find most often in startup and SaaS AWS accounts, and how to fix them.

1. Public or overly permissive S3 buckets

Buckets made public for a quick file share, or with policies granting access to "Principal": "*".

Fix: enable S3 Block Public Access at the account level, serve public assets through CloudFront with origin access control, and review bucket policies for wildcard principals. See our S3 security guide.

2. IMDSv1 enabled on EC2

The original instance metadata service answers simple GET requests, making SSRF-to-credentials attacks easy.

Fix: require IMDSv2 on all instances and in launch templates, and set the hop limit appropriately for containers.

3. Overly broad IAM policies

Policies with "Action": "*" and "Resource": "*", or broad managed policies attached to application roles.

Fix: grant least privilege, use IAM Access Analyzer to generate policies from actual usage, and review roles with admin access.

4. Long-lived access keys

IAM users with access keys created years ago, sometimes for people who have left.

Fix: use IAM Identity Center for humans and IAM roles for workloads. Remove unused keys, and rotate any that must exist.

5. Root account without MFA

The root user can do anything, including closing the account.

Fix: enable MFA on root, delete root access keys and use root only for tasks that require it.

6. Security groups open to the world

Inbound rules allowing 0.0.0.0/0 on SSH, RDP, database ports or admin interfaces.

Fix: restrict sources, use Systems Manager Session Manager instead of SSH, and keep databases in private subnets.

7. Public RDS snapshots and AMIs

Snapshots or images shared publicly, sometimes containing full database copies.

Fix: audit snapshot and AMI sharing settings regularly.

8. Secrets in plaintext

Credentials in EC2 user data, Lambda environment variables, CloudFormation parameters or code.

Fix: use Secrets Manager or Parameter Store with encryption, and restrict who can read them.

9. CloudTrail and GuardDuty disabled

Without logging, you cannot investigate incidents. Without detection, you may not notice them.

Fix: enable organisation-wide CloudTrail in all regions with log file validation, and enable GuardDuty.

10. Lambda function URLs and API Gateway without auth

Functions or APIs exposed publicly with AuthType: NONE for testing and never locked down.

Fix: require IAM or a custom authoriser, and inventory all public endpoints.

Quick audit checklist

Testing your AWS exposure from outside

Internal configuration tools tell you what is set. External testing shows what an attacker can reach. SecurityInfinity tests your internet-facing AWS resources, including exposed services, storage and metadata access through application flaws, and verifies each finding. Start free.

Frequently asked questions

What is the most common AWS breach cause?

Misconfiguration and leaked credentials are consistently among the leading causes, rather than flaws in AWS itself.

Is AWS Security Hub enough?

Security Hub aggregates configuration findings and is very useful, but it does not test application-layer paths like SSRF that lead into AWS.

How do I find who created a public resource?

CloudTrail records the API calls that created or modified resources, including the identity that made them.