IAM Policy Wildcards Checker

IAM policy wildcards are shortcuts that make an AWS permission statement match more actions, resources, or principals than a named list would. They are common during early development, service migration, and emergency access work, but they also make least-privilege review harder because one symbol can stand for a large and changing permission surface.

An asterisk in Action, Resource, or Principal does not carry the same risk in every statement. Resource "*" can be required for some AWS actions that do not support resource-level ARNs. Action "s3:*" can expand as the service adds API actions. Principal "*" in a resource or trust policy can expose access to every principal unless conditions narrow who may use the grant.

Wildcards should be reviewed by effect, service, resource type, principal type, and condition keys. A broad Deny statement can be a guardrail, while a broad Allow statement can grant more authority than a workload needs. The practical question is whether the statement can be replaced with exact actions, named ARNs, intended principals, and compensating conditions before deployment.

A wildcard scan is not a full proof of safety. It helps reviewers find risky permission shapes quickly, then follow up with AWS policy validation, service authorization docs, CloudTrail evidence, and testing in a non-production workflow.

Technical Details:

An IAM policy statement combines an Effect with scope elements. Action names the API operations, Resource names the affected objects, Principal names who can use a resource or trust policy, and Condition narrows when the statement matches. Action and NotAction are mutually exclusive, as are Resource and NotResource.

The most dangerous shapes usually come from broad Allow statements. NotAction with Allow matches every applicable action except the listed actions. NotResource with Allow matches every applicable resource except the listed resources. A wildcard Principal in a resource or trust policy can mean public access unless trusted accounts, roles, services, and condition keys narrow the grant.

The checker uses ordered rule logic rather than AWS-side authorization simulation. It parses IAM policy documents and policy wrappers, normalizes each statement, detects wildcard surfaces, then assigns severity from the combination of effect, action pattern, resource pattern, principal scope, sensitive service, write-like action, iam:PassRole, and condition-key evidence.

The risk score is a capped sum of finding weights. A single Critical finding is enough to place the summary in the Critical band, and a single High or Medium finding is enough to place it in the High or Review band even when the numeric score is lower than the next threshold.

The service exposure chart groups non-informational findings by AWS service and stacks weighted scores for action, resource, principal, negated, and condition-gap surfaces. Only the highest scoring services are shown, so the chart is a triage view. The table rows still carry the exact statement, evidence, and recommendation.

JSON parsing is intentionally strict. If the source cannot be parsed, review pauses. If JSON parses but no object with a Statement field is found, the result reports that no policy document was detected. Multiple policy documents are combined when a wrapper or infrastructure template contains more than one PolicyDocument or trust policy block.

Everyday Use & Decision Guide:

Start by naming the policy in Policy label with the role, managed policy, pull request, or template section under review. Choose Identity policy for user, group, role, and permissions-boundary style documents. Choose Resource or trust policy when Principal matters, especially role trust, bucket, key, queue, or topic policies. Use SCP or permission boundary when broad deny guardrails are part of the expected design.

Paste a JSON policy document into Policy JSON, or use Browse JSON for a JSON or TXT file. The parser accepts a direct policy, a wrapper with PolicyDocument or AssumeRolePolicyDocument, and infrastructure JSON that stores policy documents under resource properties. The file picker reads the file into the browser session, so review samples should still avoid secrets and unrelated account details.

• Use Risky sample to see how s3:*, broad Resource "*", wildcard principals, and broad iam:PassRole appear in the findings.
• Use Scoped sample to compare a named role ARN, iam:PassedToService, resource ARNs, and a tag condition against the broader sample.
• Use Format JSON after pasting a dense policy. If formatting fails, fix the JSON parse error before relying on any finding.
• Set Finding row limit low for screenshots and higher for a handoff where many statements need review.
• Turn Include deny or informational signals off when the immediate review needs only Critical, High, and Medium rows.

Read the summary first, then move to Wildcard Findings. The summary shows the risk band, number of statements, number of policy documents, count of Critical findings, high-risk count, total finding count, and risk score. Statement Inventory helps confirm that the parser found the expected statements, effects, services, wildcard surfaces, condition keys, and per-statement scores.

Do not treat No wildcard findings as proof that the policy is least privilege. It only means this review did not detect the wildcard shapes it checks. Use Remediation Checklist to plan changes, then validate the edited policy with AWS tooling and test the workload that depends on it.

Step-by-Step Guide:

Review one policy source at a time so the summary, statement inventory, chart, and remediation rows describe the same change.

1. Enter Policy label with a traceable name such as ci-deploy role policy. The label appears in the JSON result so a pasted sample can be tied back to the source review.
2. Choose Review profile. Use Resource or trust policy when wildcard Principal should be treated as an exposure surface.
3. Paste the policy into Policy JSON, drag a JSON or TXT file onto the textarea, or choose Browse JSON. The source status line should show the line and character count.
4. If Review policy JSON appears, fix the parse error or paste an object with a Statement field. If the source is a template, confirm the policy document is inside a recognized policy block.
5. Open Advanced only when the default table view is too long or too noisy. Adjust Finding row limit and Include deny or informational signals without changing the underlying JSON result.
6. Check the summary. Fix JSON means review is paused. Critical wildcard review, High wildcard review, and Review wildcard review mean at least one finding needs attention.
7. Open Wildcard Findings and work from Critical to Medium. Use Evidence to confirm the matched statement and Recommendation to draft the change request.
8. Open Statement Inventory to verify that each expected statement appears with the right Effect, service scope, wildcard surface, condition keys, and risk score.
9. Open Service Exposure Map when several services have findings. A large action, resource, principal, negated, or condition-gap bar points to the kind of scope to narrow first.
10. Use Remediation Checklist for the handoff: replace action wildcards, scope resources, harden iam:PassRole, replace public principals, remove negated allow elements, add conditions, and validate before deployment.

A review-ready policy has no Critical or High rows, expected statements in the inventory, documented exceptions for actions that require Resource "*", and a follow-up validation run before production use.

Interpreting Results:

The first actionable Critical or High row matters more than the total score. A policy with iam:PassRole on broad resources and no iam:PassedToService condition should stop a deployment review even when other statements look narrow.

False confidence is the main risk. The checker does not prove that an exact action list is complete, that a named ARN is correct, that a condition key is sufficient, or that a cross-account trust relationship is intended. It flags wildcard shapes and produces review cues for the policy text supplied.

Use the JSON result when you need a machine-readable handoff. It contains the policy label, review profile, document and statement counts, risk score, risk band, severity counts, normalized findings, statement inventory, and chart rows. Treat those outputs as sensitive security evidence.

Worked Examples:

Deployment role with broad permissions

The risky sample labels a policy as ci-deploy role policy and includes Action values s3:*, iam:PassRole, and lambda:AddPermission with Resource "*". With Review profile set to Resource or trust policy, the summary reaches Critical wildcard review, 4 high-risk, 3 statements, 1 document, 3 critical, and a risk score 100. Wildcard Findings includes Wildcard action pattern, Resource is star, PassRole wildcard without service condition, and Broad allow without condition.

Scoped deployment policy with one wildcard ARN

The scoped sample uses s3:GetObject and s3:ListBucket with a named bucket ARN plus arn:aws:s3:::example-artifacts/releases/*. It also scopes iam:PassRole to a named role ARN and adds iam:PassedToService for Lambda. The summary shows Review wildcard review, 0 high-risk, 2 statements, and risk score 8. Wildcard Findings has a Medium Wildcard resource ARN row for the releases prefix, while Statement Inventory gives the PassRole statement a risk score of 0.

Trust policy principal check

A trust policy with Principal "*", Action "sts:AssumeRole", and Resource "*" should be reviewed under Resource or trust policy. The findings include Wildcard Principal as Critical, plus resource and condition findings if the statement lacks a narrowing condition. Switching to Identity policy removes the principal-specific finding because identity policies do not use Principal the same way, but the resource and condition findings still need review.

Broken JSON paste

A pasted fragment that is missing a closing brace makes the summary show Fix JSON and opens Review policy JSON with the parser message. If the JSON is valid but the object has no Statement field, the same error panel reports that no policy document was found. Fix the JSON shape before using Wildcard Findings, because the review cannot score statements it cannot parse.

Responsible Use Note:

IAM policies can expose account IDs, role names, trust relationships, service architecture, deployment habits, and sensitive resource names. Paste the smallest policy sample that answers the review question, and remove unrelated hostnames, account numbers, tags, and internal naming details when they are not needed.

Policy text is parsed in the browser session, and file selection reads JSON or TXT into the page. Copied tables, downloaded JSON, chart images, and URL state can still carry sensitive policy evidence, so handle every output like a security review artifact.

FAQ:

Glossary:

Action

The AWS API operation or operation pattern allowed or denied by a statement.

Resource

The ARN or wildcard resource scope that the statement applies to.

Principal

The account, role, service, federated identity, or wildcard caller named in a resource or trust policy.

Condition

A rule that narrows when a statement matches, such as principal, source, tag, region, network, or PassRole service constraints.

NotAction

A negated action element that matches every applicable action except the actions listed.

NotResource

A negated resource element that matches every applicable resource except the resources listed.

iam:PassedToService

An IAM condition key that restricts which AWS service can receive a role through iam:PassRole.

References:

• Security best practices in IAM, AWS Identity and Access Management.
• IAM JSON policy element reference, AWS Identity and Access Management.
• IAM JSON policy elements: Resource, AWS Identity and Access Management.
• IAM JSON policy elements: NotAction, AWS Identity and Access Management.
• IAM JSON policy elements: NotResource, AWS Identity and Access Management.
• AWS JSON policy elements: Principal, AWS Identity and Access Management.
• IAM and AWS STS condition context keys, AWS Identity and Access Management.
• Validate policies with IAM Access Analyzer, AWS Identity and Access Management.