DEV Community

Shieldly
Shieldly

Posted on • Originally published at shieldly.io

The 7 IAM Misconfigurations We See in Almost Every AWS Account

#devops #aws #security #iam

Originally published at shieldly.io/blog.

After analyzing a lot of IAM policies, the same seven patterns show up again and again. Here is each one, why it is dangerous, and the fix.

1. Action: * on Resource: * 

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}
Enter fullscreen mode Exit fullscreen mode

This is administrator access by another name. If you see it outside a dedicated, tightly controlled admin role, treat it as a critical finding. Fix: enumerate the exact actions the workload needs.

2. s3:* on Resource: *

Even scoping to one service is too broad. s3:* includes s3:DeleteObject, s3:DeleteBucket, and s3:PutBucketPolicy. Fix: list only the specific actions (s3:GetObject, s3:PutObject, etc.) on the specific bucket ARN.

3. iam:PassRole on Resource: * 

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*"
}
Enter fullscreen mode Exit fullscreen mode

PassRole is harmless until paired with a service launch. On Resource: * it lets a principal pass any role in the account to any service — including admin roles. Fix: scope to specific role ARNs and add the iam:PassedToService condition key.

4. Trust policy Principal: * 

{
  "Principal": "*"
}
Enter fullscreen mode Exit fullscreen mode

Any AWS identity in the world can attempt to assume the role. Almost always unintentional. Fix: replace with explicit account or role ARNs, and add an ExternalId condition for cross-account access.

5. Missing ExternalId on third-party cross-account roles

Without ExternalId, any customer of the same vendor can assume your role (the confused deputy problem). Fix: require a unique ExternalId condition on every cross-account trust policy.

6. Inline policies on IAM users

Inline policies do not appear in the IAM managed policy list and are easy to miss in audits. They also travel with the user — if the user is deleted and a new one created with the same name, they do not transfer. Fix: move to customer-managed policies attached to roles, not users.

7. sts:AssumeRole on Resource: * 

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "*"
}
Enter fullscreen mode Exit fullscreen mode

A principal with this permission can assume any role in the account whose trust policy allows it. That includes roles with administrator access. Fix: scope to specific role ARNs.

Catch all seven automatically — paste a policy into Shieldly's free AI-Powered analysis. No signup, no credit card.

Launch offer: code 90Off2M — 90% off first 2 months. Builder from $1.90/mo. shieldly.io/pricing

Top comments (0)