Why Wildcards in AWS IAM Policies Are Dangerous (and How to Fix Them)

The asterisk is the single most overused character in AWS IAM. It is quick to type, it makes errors disappear, and it is the root cause of a huge share of real cloud breaches. There are three wildcards that matter most — in the Action, Resource, and Principal fields — and each one grants far more than most teams realize.

1. Action: * — Every Operation, Including Destructive Ones

"Action": "*" grants every API operation across every service. Even the narrower "s3:*" is dangerous: it bundles read, write, DeleteObject, DeleteBucket, and PutBucketPolicy — meaning a credential intended to upload a file can also wipe the bucket or rewrite its access policy.

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

This is administrator access by another name. If you see it outside a dedicated, tightly controlled admin role, treat it as a critical finding.

2. Resource: * — Across Every Object in the Account

"Resource": "*" applies the granted actions to every resource the service has. s3:GetObject on * can read every object in every bucket — not just the one the workload needs. Scope to explicit ARNs:

"Resource": "arn:aws:s3:::my-app-uploads/*"

A few IAM and account-level actions genuinely require * because they have no resource ARN, but they are the exception. For the vast majority of policies, a real ARN belongs there.

3. Principal: * — Open to the Entire Internet

On resource-based policies (S3 bucket policies, KMS key policies, SQS, SNS, Lambda), "Principal": "*" means anyone — including anonymous, unauthenticated callers — unless a condition narrows it. This is how buckets end up publicly readable. If you must use it, always pair it with a strict condition such as aws:PrincipalOrgID or aws:SourceArn.

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" }
  }
}

How to Scope Wildcards Down

• Enumerate the actions you actually call. Use CloudTrail or IAM Access Analyzer to see which operations the identity uses, then list only those.
• Name your resources. Replace * with specific ARNs; use path prefixes where you need a group of objects.
• Constrain principals with conditions. Never leave Principal: * unconditioned on a resource policy.
• Catch them automatically.Wildcards reappear constantly as policies change. Shieldly's AI-Powered analysis flags every risky wildcard, explains the real-world exposure it creates, and proposes a scoped replacement — across CLI, CI, IDE, and CDK.

Amazon Web Services (AWS) is a trademark of Amazon.com, Inc. Shieldly is not affiliated with, endorsed by, or sponsored by Amazon Web Services.