How to Validate AWS IAM Policies: 7 Checks Before You Deploy

IAM policy JSON is deceptively easy to write and deceptively hard to get right. AWS will happily accept a syntactically valid policy that grants far more than intended — the failure mode isn't an error message, it's an overly permissive deployment. Running a checklist of validations before you attach a policy catches both classes of problem.

The 7 Checks

1. JSON syntax. Trailing commas, unquoted keys, and comments (not allowed in policy JSON) are the top causes of policy parse failures.
2. Element names. Action, Resource, Effect, Principal, Condition, Sid — a typo like Actions is silently ignored by some tooling.
3. Action names. Verify every action exists for the service (s3:GetObject real, s3:GetFile not). Typos here create policies that grant nothing.
4. Wildcard scope. Action: "*" or "s3:*" on Resource: "*" is admin-equivalent. Scoped wildcards like s3:Get* still need review.
5. Resource ARN correctness. Every ARN must match the service's resource types — and should exist. Validate ARN structure with the AWS ARN Parser.
6. Condition keys and operators. Keys like aws:SourceIp and aws:MultiFactorAuthPresent must be valid for the service, and operators like StringEquals vs IpAddress must match the value type.
7. Privilege escalation patterns. Permissions like iam:PassRole, lambda:CreateFunction, or iam:CreatePolicyVersion let a principal elevate itself — see our privilege escalation patterns deep dive.

Watch Out: NotAction and NotResource

NotAction and NotResource invert the match — "NotAction": "iam:*" means "everything except IAM actions", not "no IAM actions". Combined with Effect: Allow and a broad Resource, they routinely create accidental admin policies. Any validator should flag their use for manual review.

Where to Validate

AWS offers three built-in routes: IAM Access Analyzer policy checks (in-console, validates against AWS's grammar), iam:SimulatePrincipalPolicy (evaluates what a policy actually permits), and the policy editor warnings. All require the policy to reach AWS infrastructure. For rapid iteration — or policies that contain sensitive account IDs and resource names — a browser-based validator is faster: paste the JSON, get findings, and nothing leaves your machine. Our free IAM Policy Validator runs all seven checks above entirely client-side.

A Validation Workflow That Works

1. Author the policy scoped to specific actions and resource ARNs — never start from "*" and scope down.
2. Lint locally: syntax, element names, wildcard scope, escalation patterns.
3. Simulate in a sandbox account with SimulatePrincipalPolicy or Access Analyzer's unused-access findings.
4. Attach with a narrow scope, then let Access Analyzer's external-access findings run for a cycle before broadening.

Frequently Asked Questions

What does an IAM policy validator check?

At minimum: JSON syntax, allowed policy elements, valid action names, ARN structure, condition key/operator compatibility, and wildcard scope. Good validators also flag security issues like privilege escalation patterns and NotAction/NotResource pitfalls.

Is it safe to paste IAM policies into an online validator?

Only if the validator runs client-side — policies can reveal account IDs, resource names, and internal architecture. Our IAM Policy Validator processes everything in your browser; nothing is sent to a server.

Does AWS have a built-in policy validator?

Yes — IAM Access Analyzer runs policy checks and generates findings in the console, and the policy editor shows warnings inline. They're useful but require AWS access; a browser tool complements them for pre-deployment linting.

What is the most dangerous IAM policy pattern?

"Action": "*", "Resource": "*", "Effect": "Allow" grants full admin. Nearly as dangerous: iam:PassRole to a powerful role combined with compute creation permissions — a classic privilege escalation path covered in our IAM security patterns article.