{{ result.summary.heading }}
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
Name the role, managed policy, pull request, or template section under review.
Choose the AWS policy shape before reviewing wildcard Action, Resource, Principal, NotAction, and NotResource surfaces.
Select the environment that best matches the pasted policy before accepting exceptions.
Use only when the review has a known exception class, such as exact actions that require Resource "*".
Use strict for production approvals, balanced for normal review, or advisory for early design feedback.
Paste JSON with Statement entries. The checker flags wildcard Action, Resource, Principal, NotAction, and NotResource surfaces.
{{ sourceMeta }}
Use a compact value for screenshots or a larger value for handoff exports.
rows
Leave on for a full policy handoff; turn off for a shorter release review.
{{ params.include_info_signals ? 'On' : 'Off' }}
{{ header }} Copy
{{ cell }}
No IAM wildcard rows available
Paste a valid IAM policy document before exporting this table.
Tags: Devops, Security
Vulnerability Remediation SLA Calculator Calculate vulnerability remediation due dates from CSV findings, apply severity SLAs and exploited caps, and surface overdue or due-soon queues.
IAM Policy Permissions Analyzer Analyze IAM policy JSON for wildcard actions, broad resources, sensitive services, and least-privilege findings before approval.
Kubernetes Resource Requests Checker Check Kubernetes manifests for missing CPU, memory, and ephemeral-storage requests, limit mismatches, QoS clues, and scheduler footprint gaps.
RPO/RTO Gap Calculator Compare RPO/RTO targets with measured recovery evidence, flag data-loss or restore-time gaps, and estimate added change or downtime exposure.
Customize
Advanced
:

IAM policies often become risky through a small shortcut rather than a long obvious grant. In AWS Identity and Access Management, the asterisk can mean every action, every resource, every matching name prefix, or every principal. A wildcard that looks harmless in a draft can later include new service actions, newly created resources, or callers the reviewer never meant to approve.

The impact depends on the policy shape. A wildcard in an identity policy usually changes what a user, role, group, or session can do. A wildcard Principal in a resource policy or role trust policy changes who may use the resource or attempt to assume the role. Permission boundaries, service control policies, resource control policies, and session policies often act as ceilings, but a broad ceiling still deserves review because it defines the maximum permission space other grants can occupy.

Wildcard Surface What It Can Expand Evidence Needed Before Approval
Action All AWS APIs, every API in one service, or any operation that matches a prefix. Observed workload actions, service authorization checks, and explicit treatment of write or permission-management verbs.
Resource Every resource, broad ARN segments, accounts, Regions, resource names, or path prefixes. Service resource-level support, scoped ARN patterns, naming boundaries, and conditions where the service supports them.
Principal Public callers, external accounts, services, roles, or identities that can reach a resource or trust policy. Named accounts or roles, organization or source constraints, external ID where needed, and a clear public-access decision if public access is intended.
NotAction or NotResource Everything except the listed exclusions, which can be much wider than a positive allowlist. A reason the negated form is safer than explicit Action and Resource pairs, plus tests against the actual workload.
IAM wildcard review path from policy statement to wildcard surfaces, condition narrowing, and remediation priority

Wildcards are not always wrong. Some AWS actions do not support resource-level permissions and therefore require Resource "*". Prefix wildcards can be useful for log groups, object paths, or named environments when the prefix is deliberate. The review problem is proof: every wildcard should be tied to a real service limit, a narrow naming pattern, a condition, or a documented guardrail.

A wildcard check should sit beside, not replace, normal IAM validation. Least privilege still requires service authorization references, IAM Access Analyzer policy validation, observed workload activity, and tests in a non-production account or environment before a changed policy is attached.

How to Use This Tool:

Review one policy source at a time so the label, findings, inventory, chart, exception decisions, and remediation rows describe the same approval item. The checker reads the supplied JSON in the browser session and does not ask AWS to validate the policy for you.

  1. Add a Policy label that matches the role, managed policy, pull request, template section, or review ticket.
  2. Set AWS policy type. Identity policies focus on granted permissions. Resource-based and trust policies make wildcard Principal values important. Boundaries, SCPs, RCPs, and session policies are treated as maximum permission scopes.
  3. Choose the closest Workload profile. Production, CI/CD, data, read-only, and sandbox profiles change which services receive extra pressure.
  4. Leave Allowed wildcard exception model at No wildcard exceptions allowed unless the change record already explains the exception class.
  5. Use Severity policy to match the review stage. Strict blocking is for production approval, Balanced review is the normal setting, and Advisory triage is useful while a policy is still being drafted.
  6. Paste IAM policy JSON, drag in a JSON or TXT file, or select Browse JSON. The checker can read a policy document, a managed-policy wrapper, or template content with embedded policy documents.
  7. If a parse error appears, fix the JSON before reading the tables. If the warning says no Statement was found, paste the full policy object or the template section that contains the policy document.
  8. Start with Wildcard Findings, then confirm the same statements in Statement Inventory. Use Service Exposure Map, Wildcard Exception Ledger, and Remediation Checklist when the review needs a handoff.

A useful handoff usually has no unresolved Critical or High rows, expected statement counts, written evidence for any exception, and a separate AWS validation result for the edited policy.

Interpreting Results:

Read severity before totals. One Critical iam:PassRole row or one wildcard trust-policy principal can be more important than several lower-scored prefix findings. The risk score helps sort a review queue, but the first high-impact statement is what should pause an approval.

Result Cue Likely Meaning Best Follow-Up
Action and Resource are both star The statement can allow every action on every resource that the policy can affect. Replace it with explicit service actions and resource ARNs before attachment.
Allow with NotAction The allow may cover every applicable action except the named exclusions. Rewrite the statement as a positive Action list based on workload use.
Allow with NotResource The allow may cover every applicable resource except the named exclusions. Use normal Resource values and split services or resource types into separate statements.
Wildcard Principal A resource policy or trust policy may be reachable by unintended accounts, identities, or public callers. Name accounts, roles, services, organization IDs, source resources, or external ID conditions where they apply.
No wildcard findings The supplied JSON did not match the wildcard rules checked here. Still verify action necessity, resource-level support, condition strength, and Access Analyzer output.

False confidence is the main mistake to avoid. A low result does not prove that every action is necessary, every ARN is correct, every condition is strong, or every trust relationship is intended. It only means the supplied policy text did not trigger the checked wildcard patterns.

Technical Details:

An IAM statement is evaluated from a small set of policy elements. Effect says whether the statement allows or denies. Action or NotAction defines operations. Resource or NotResource defines affected objects. Principal identifies who can use a resource or trust policy. Condition narrows when the statement matches.

Wildcards change meaning by position. In Action, * can represent all services, every operation in one service, or every operation that matches a prefix. In a resource ARN, wildcard characters can widen names, paths, regions, accounts, or resource segments. In Principal, the same character can mean a broad caller set unless a condition proves the intended accounts or identities. Negated elements deserve special care because they define access by what is left out.

A broad allow is most serious when several surfaces combine. Action "*" plus Resource "*" creates an obvious all-purpose grant, but a narrower-looking statement can still be risky when iam:PassRole, write-like action prefixes, missing conditions, or a wildcard trust principal are present. Deny statements are different because they often serve as guardrails, so they are shown separately instead of being treated like broad allows.

Rule Core

Rule Group Checked Pattern Why It Changes Priority
Action scope Action "*", service wildcards such as s3:*, prefix patterns such as iam:Delete*, and allow statements with NotAction. Future or unreviewed operations can enter the permission set, especially for IAM, STS, KMS, Organizations, and deployment services.
Resource scope Resource "*", wildcard ARN segments, missing resource values, and allow statements with NotResource. The same action can expand across names, accounts, regions, resource types, or every supported resource.
Principal scope Principal "*" or wildcard principal values when the selected policy type uses principals. Resource and trust policies can expose access to public or unintended callers without account, service, organization, source, or external ID constraints.
Condition gap Broad allows with no condition keys, and broad iam:PassRole without iam:PassedToService. Conditions often provide the evidence that a wildcard is bounded by caller, source, tag, region, network, or receiving service.
Deny guardrail Deny statements that use wildcard actions, resources, or negated scope. Deny guardrails can be intentional controls, so they are shown separately from broad allow findings.

Formula Core

The risk score is a capped sum of severity weights. Each finding starts with a base severity, policy context may raise or lower it, and the selected severity policy changes the numeric weight.

wi = round ( basei × severity multiplier ) risk score = min ( 100 , ∑ wi )
Item Value How It Is Used
Critical 34 Used for all-action grants, broad negated allows, sensitive wildcard actions, broad iam:PassRole, and wildcard assume-role principals.
High 18 Used for write-like wildcard actions, broad resources around risky actions, and public principals outside the highest-risk trust cases.
Medium 8 Used for broad allows without conditions, wildcard ARN segments, missing resources, and resource stars that do not meet a higher rule.
Low or Info 3 or 1 Used for minor signals, policy-type mismatches, and deny guardrail evidence.
Severity policy 1.25, 1, or 0.75 Strict, balanced, and advisory settings multiply the final severity weights after context changes.
Risk band 75+, 45+, 20+, or below 20 The summary reads Critical, High, Review, or Low. Any Critical, High, or Medium finding can also lift the summary to that review priority.

For example, one Critical finding under the balanced setting starts at 34. Two Medium findings add 8 + 8, so the risk score becomes 50 and the summary reaches the High band. A documented exception may lower a finding's severity, but the exception ledger should still explain the evidence that makes the wildcard acceptable.

Privacy Notes:

Policy JSON is parsed in the browser session. File selection reads JSON or TXT into the page for review, and the checker does not submit pasted policy text to AWS or a remote policy analyzer.

Treat every copied row, chart image, and JSON result as security evidence. Policy text can reveal account IDs, role names, trust relationships, object prefixes, tags, service choices, and deployment habits.

Worked Examples:

CI/CD role with deployment reach

A deployment role allows s3:*, lambda:AddPermission, and iam:PassRole on Resource "*". Under a CI/CD workload profile, broad action scope, resource star, and missing iam:PassedToService can combine into a Critical review. The immediate fix is to name required actions, scope PassRole to the deployment role ARN, and add the receiving service condition.

Prefix wildcard with a condition

A read policy allows s3:GetObject on arn:aws:s3:::example-artifacts/releases/* and includes a principal tag condition. The wildcard resource row may remain review-worthy, but it has a clearer boundary than Resource "*". Verify that the prefix covers only release objects and that the tag condition matches the deployment process.

Trust policy with public principal

A role trust policy contains Principal "*" with sts:AssumeRole. Review it as a role trust policy, not as a normal identity policy. Unless conditions narrow the caller set, the wildcard principal can become a Critical finding because unintended accounts may be able to attempt role assumption.

JSON that parses but has no policy

A template fragment without a Statement, PolicyDocument, or AssumeRolePolicyDocument can parse successfully while producing no policy review. Paste the full policy document or the resource section containing the policy, then rerun the check before relying on any low result.

FAQ:

Does a Low result prove least privilege?

No. Low means the supplied policy did not trigger the checked wildcard rules. Confirm action necessity, resource support, condition strength, Access Analyzer findings, and workload tests separately.

Why can Resource star be required?

Some AWS actions do not support resource-level ARNs, so those exact actions must use Resource "*". Keep those exceptions isolated, documented, and paired with conditions when conditions can narrow use.

Which policy type should I choose?

Choose an identity option for permissions attached to identities, resource-based or trust policy when Principal should be reviewed, and boundary, SCP, RCP, or session policy when the document limits maximum permissions.

What should I fix first?

Start with Critical and High findings that involve Action "*", Resource "*", NotAction, NotResource, wildcard principals, or broad iam:PassRole. Then handle Medium prefix and condition rows.

Are wildcard deny statements failures?

Not automatically. Deny guardrails often need broad scope. Keep them separate from allow statements and test that the guardrail does not hide missing least-privilege grants.

Glossary:

Action
The AWS operation or operation pattern allowed or denied by a statement.
Resource
The ARN, ARN pattern, or star value that names what 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 the statement applies, such as source, organization, tag, region, network, or PassRole service constraints.
NotAction
A negated action element that matches applicable actions except the actions listed.
NotResource
A negated resource element that matches applicable resources except the resources listed.
iam:PassedToService
An IAM condition key that limits which AWS service can receive a role through iam:PassRole.

References: