IAM Overly Permissive Policy Checker

A single statement combining "Action": "*" with "Resource": "*" under "Effect": "Allow" is the most dangerous pattern an IAM policy can contain — it grants every action on every resource, unrestricted, with no scoping at all. Overly Permissive Policy Checker paste a policy JSON document and it scans every statement for exactly this combination, listing each match by statement index, Sid, and the reason it was flagged.

The check is intentionally precise rather than broad: a statement is only flagged when it is an Allow statement, its Action (or the array it lives in) includes the literal string "*", AND its Resource includes the literal string "*" — both wildcards together. A statement with a bare "*" Action scoped to one specific bucket ARN is broad but not unrestricted, and is not flagged by this check. Likewise a statement granting "*" Resource but only a narrow, explicit list of actions is not flagged. This is a deliberate, narrow definition matching the single clearest red flag in policy review: no scoping whatsoever, on either side of the grant.

Because this check specifically looks for the bare "*" wildcard on both Action and Resource, it will not flag service-level wildcards like "s3:*" or prefix wildcards like "s3:Get*" — those are real risk patterns too, just a different, more graded category, and the separate Wildcard Usage Analyzer tool in this category covers every wildcard occurrence (Action, NotAction, Resource, NotResource) with a high/medium/low risk grading rather than this tool's single binary check. Only Allow statements are examined — a Deny statement with Action: "*", Resource: "*" is a guardrail that blocks everything, the opposite of a permissiveness problem, so it is correctly excluded.

When statements are flagged, each result shows the statement's index (its position in the Statement array), its Sid if it has one (or a clear indicator that it has none), and a plain-language reason. A summary line at the top states how many of the policy's total statements were flagged, e.g. "1 of 4 statements are overly permissive," so the scale of the issue relative to the whole document is immediately visible. If none of the statements match — which is the common, healthy case for a reasonably scoped policy — the tool shows a clear positive confirmation rather than leaving you looking at an empty table wondering whether the check actually ran.

This tool performs one specific, static check against the JSON you paste; it is not a replacement for AWS IAM Access Analyzer or Access Advisor, which examine real usage history and cross-account exposure using live account data that a local tool cannot see. It does not call any AWS API, does not evaluate the actual blast radius of a flagged statement in your account, and does not rewrite or scope down the policy for you — it points at exactly the statement that needs manual review, by index and reason, so you can decide how to narrow it. Everything runs locally in your browser; nothing you paste is uploaded.

• Flags Allow statements with Action "*" AND Resource "*" together — the single most dangerous IAM pattern.
• Precise, not broad — does not flag either wildcard alone, and does not flag Deny statements.
• Per-statement index, Sid, and reason for every flagged statement.
• Summary line — "N of M statements are overly permissive."
• Clear positive result when zero statements are flagged, not just an empty table.
• Sample policy with a deliberately overly-permissive statement to see a real flagged result immediately.
• Clear JSON parse errors if the pasted text is not valid JSON.
• 100% client-side — nothing is uploaded.

1. Paste your policy JSON, or click "Load sample".
2. Click Check.
3. If statements are flagged, note each statement's index and Sid.
4. Read the summary line for the flagged-vs-total count.
5. Scope down each flagged statement's Action and/or Resource to only what is actually needed.
6. Re-run to confirm the policy is now clean.

Example 1 — the classic admin statement. {"Sid":"AdminAll","Effect":"Allow","Action":"*","Resource":"*"} — flagged, reason: unrestricted access.

Example 2 — broad action, scoped resource, not flagged. {"Effect":"Allow","Action":"*","Resource":"arn:aws:s3:::my-bucket/*"} — Action is a bare wildcard but Resource is scoped, so this specific check does not flag it (though it may still be worth reviewing).

Example 3 — scoped action, broad resource, not flagged. {"Effect":"Allow","Action":["s3:GetObject","s3:ListBucket"],"Resource":"*"} — Resource is unrestricted but Action is a specific list, so this check does not flag it.

Example 4 — Deny with both wildcards, correctly not flagged. {"Effect":"Deny","Action":"*","Resource":"*"} is a common guardrail (e.g. paired with a Condition) and is excluded since only Allow statements are checked.

Example 5 — clean policy. A policy with several narrowly-scoped Allow statements and no bare-wildcard combination reports "0 of N statements are overly permissive," shown as a clear positive result.

• Catches the single most dangerous IAM anti-pattern instantly.
• Precise flagging avoids false positives from either wildcard used alone.
• Clear summary shows scale of the issue at a glance.
• Points to the exact statement by index and Sid for fast remediation.
• Instant, local feedback — no waiting on an API call.
• Private — policy content never leaves your browser.