IAM policy checker

What the checker looks for

• Wildcard action. "Action": "*" allows every API call. "s3:*" allows every call in one service. NotAction with Allow grants everything except the listed calls.
• Wildcard resource. "Resource": "*" applies the permission to every resource. It is reported as low when every action is a Describe or List call, which often cannot be limited to one resource.
• Public principal. "Principal": "*" and {"AWS": "*"} let anyone use the statement, including anonymous callers.
• No condition. A broad statement (public principal, wildcard action, or wildcard resource on a non-read-only action) with no Condition. Conditions such as aws:SourceIp, aws:SourceVpce, or aws:PrincipalOrgID limit where and by whom it can be used.

Checks run on Allow statements only. They read the policy text, not your account, so they cannot see whether a role is attached to anything or whether another policy narrows the access.

What the severities mean

high

"Action": "*", or "Principal": "*" with no Condition. Anyone, or any call, is allowed. Fix these first.

medium

A service wildcard such as s3:*, NotAction with Allow, Resource "*" on actions that change things, a broad statement with no Condition, or a public principal that only a Condition narrows. These are often too broad, and you decide if they are.

low

Resource "*" where every action is a Describe or List call. Many of these calls cannot be limited to one resource, so this is often correct.

Fixing a finding

Name the calls and the resources, instead of using a wildcard for either.

// Broad
"Action": "s3:*",
"Resource": "*"

// Narrower
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/uploads/*"

For a statement that has to be public-facing, such as a bucket policy, name who may use it, or add a condition:

"Principal": { "AWS": "arn:aws:iam::111122223333:root" }

// or keep "*" and limit it to your AWS Organization
"Principal": "*",
"Condition": {
  "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" }
}

If you are unsure which calls a role needs, the access advisor and CloudTrail show what it has really used. Start narrow and add what is missing.

Identity policies and resource policies

A policy attached to a user, group, or role is an identity-based policy. It has no Principal, because the principal is whoever it is attached to. A policy attached to a resource, such as an S3 bucket, an SQS queue, a KMS key, or the trust policy of a role, is resource-based and must say who it applies to. That is why the public principal check matters most on resource policies: "*" there can mean the whole internet.