NEW: The State of AWS Security 2026 - Free WhitepaperFree AWS Security Whitepaper

Amazon Verified Permissions Security

IDENTITY

Amazon Verified Permissions is a fully managed, fine-grained authorization service for custom applications. It uses the Cedar policy language to define permissions and make authorization decisions. Applications call the IsAuthorized or IsAuthorizedWithToken API to evaluate Cedar policies stored in a policy store.

MEDIUM

Risk Level

10+

Attack Vectors

Cedar

Policy Language

RBAC + ABAC

Auth Model

📋Service Overview

Policy Stores & Cedar Policies

Policy stores are central containers for Cedar policies, schemas, and identity sources. Cedar is an open-source policy language with explicit permit and forbid effects. Authorization follows default-deny: if any forbid policy matches, the result is Deny; else if any permit policy matches, the result is Allow; otherwise Deny.

Key components: Static policies, policy templates, template-linked policies, schemas, identity sources, validation settings (STRICT or OFF)

Identity Sources (Cognito and OIDC)

Identity sources connect external identity providers (Amazon Cognito user pools or custom OIDC providers) to a policy store. The IsAuthorizedWithToken API accepts ID or access tokens directly and maps token claims to Cedar entity attributes for policy evaluation.

Key components: Cognito user pool integration, OIDC provider support, token-to-entity mapping, client/audience validation

Security Risk Assessment

LowMediumHighCritical

6.0

Risk Score

Verified Permissions is an application-layer authorization service. It does not directly control AWS resource access (that is IAM's role). However, misconfigurations in Cedar policies, schemas, or identity source mappings can lead to authorization bypass in the applications that rely on it. The primary risks are overly permissive Cedar policies, disabled schema validation, and flawed policy logic.

⚔️Attack Vectors

Cedar Policy Logic Attacks

•Craft requests that exploit gaps between permit policies and missing forbid policies
•Abuse overly broad wildcard scopes (e.g., permit(principal, action, resource) with no conditions)
•Exploit principal identifier reuse when human-readable names are used instead of UUIDs
•Abuse template-linked policies with overly broad templates
•Exploit missing unless conditions on permit policies to bypass intended restrictions

Infrastructure and Integration Attacks

•Enumerate policy stores, policies, and schemas via IAM permissions to map the authorization model
•Tamper with identity source token claims if token validation is weak
•Exploit disabled schema validation (mode=OFF) to inject malformed policies
•Abuse overly permissive IAM policies on verifiedpermissions:CreatePolicy to inject attacker-controlled policies
•Target the application layer to bypass Verified Permissions entirely if the app fails to call IsAuthorized

⚠️Misconfigurations

Cedar Policy Misconfigurations

•Schema validation set to OFF in production, allowing invalid policies
•Overly broad permit policies with no resource or principal constraints
•Using human-readable identifiers (e.g., User::"jane") instead of UUIDs
•Missing forbid policies for sensitive actions, relying solely on absence of permit policies
•Policy templates with unscoped placeholders generating overly permissive policies

Infrastructure Misconfigurations

•IAM policies granting verifiedpermissions:* to application roles
•No separation between IAM permissions for read-only authorization and write operations
•Identity source configured without client ID restrictions
•CloudTrail data events not enabled for IsAuthorized and IsAuthorizedWithToken
•No monitoring or alerting on policy store modifications

🔍Enumeration

List All Policy Stores

aws verifiedpermissions list-policy-stores

Get Policy Store Details

aws verifiedpermissions get-policy-store \
  --policy-store-id PSEXAMPLEabcdefg111111

List All Policies in a Policy Store

aws verifiedpermissions list-policies \
  --policy-store-id PSEXAMPLEabcdefg111111

Retrieve a Specific Policy

aws verifiedpermissions get-policy \
  --policy-store-id PSEXAMPLEabcdefg111111 \
  --policy-id SPEXAMPLEabcdefg111111

Get the Schema

aws verifiedpermissions get-schema \
  --policy-store-id PSEXAMPLEabcdefg111111

List Identity Sources

aws verifiedpermissions list-identity-sources \
  --policy-store-id PSEXAMPLEabcdefg111111

Get Identity Source Details

aws verifiedpermissions get-identity-source \
  --policy-store-id PSEXAMPLEabcdefg111111 \
  --identity-source-id ISEXAMPLEabcdefg111111

List Policy Templates

aws verifiedpermissions list-policy-templates \
  --policy-store-id PSEXAMPLEabcdefg111111

Test an Authorization Decision

aws verifiedpermissions is-authorized \
  --policy-store-id PSEXAMPLEabcdefg111111 \
  --principal entityType=User,entityId=alice \
  --action actionType=Action,actionId=view \
  --resource entityType=Photo,entityId=VacationPhoto94.jpg

📈Privilege Escalation

Cedar Policy Injection

•With verifiedpermissions:CreatePolicy, inject permit(principal, action, resource); granting full access
•With verifiedpermissions:UpdatePolicy, modify existing policies to add attacker principal or widen scope
•With verifiedpermissions:PutSchema, alter schema to add new entity types/actions then create policies for them

Application-Level Escalation

•Exploit principal identifier reuse: register as deleted "admin" user to inherit permissions
•Abuse group membership in Cognito tokens if group assignment is not tightly controlled
•Exploit missing authorization checks in the application to bypass policy evaluation entirely

Key Technique: Enumerate the full policy set with list-policies and get-policy, then analyze Cedar policy logic offline to find gaps -- actions or resources with no corresponding forbid policy and overly broad permit policies.

🔗Lateral Movement & Data Exfiltration

From Verified Permissions

•Map the full authorization model (policies, schema, identity sources) to understand protected vs. unprotected resources
•Use IsAuthorized to probe which principal/action/resource combinations are allowed
•Identify identity sources to pivot to the connected Cognito user pool or OIDC provider
•Analyze policy templates to find broadly scoped reusable permission patterns

Data Exfiltration

•Extract the complete schema to understand all entity types, actions, and relationships
•Dump all policies to reverse-engineer the full authorization model and find gaps
•Retrieve identity source configuration to discover connected Cognito user pool ARNs and OIDC provider URLs

🛡️Detection

CloudTrail Management Events (Default)

•CreatePolicy - new policy added to a policy store
•DeletePolicy - policy removed from a policy store
•UpdatePolicy - existing policy modified
•PutSchema - schema created or updated
•CreatePolicyStore / DeletePolicyStore
•CreateIdentitySource / DeleteIdentitySource
•CreatePolicyTemplate

Indicators of Compromise

•Unexpected CreatePolicy or UpdatePolicy events from unusual IAM principals
•PutSchema events that change the authorization model outside normal deployment pipelines
•Spike in IsAuthorized calls returning DENY (possible authorization probing)
•DeletePolicy events removing forbid policies (weakening security controls)
•New identity sources added pointing to external OIDC providers

📜Policy Examples

✗Bad - Unrestricted Cedar Permit Policy

permit(principal, action, resource);

This policy allows any principal to perform any action on any resource. It is the Cedar equivalent of Effect: Allow, Action: *, Resource: * in IAM and should never be used.

✓Good - Scoped Cedar Permit Policy with Conditions

permit(
  principal in UserGroup::"viewers",
  action in Action::"readOnly",
  resource in Album::"publicPhotos"
)
when { context.mfaAuthenticated == true };

Restricts access to the viewers group, read-only actions, a specific album, and requires MFA authentication in the request context.

✗Bad - IAM Policy Granting Full Verified Permissions Access

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "verifiedpermissions:*",
    "Resource": "*"
  }]
}

Grants the ability to create, modify, and delete policies, schemas, and identity sources -- an attacker with this role can rewrite the entire authorization model.

✓Good - IAM Policy for Read-Only Authorization

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "verifiedpermissions:IsAuthorized",
      "verifiedpermissions:IsAuthorizedWithToken",
      "verifiedpermissions:BatchIsAuthorized"
    ],
    "Resource": "arn:aws:verifiedpermissions::123456789012:policy-store/PSEXAMPLEabcdefg111111"
  }]
}

Application role can only make authorization decisions against a specific policy store. Cannot modify policies, schemas, or identity sources.

✗Bad - Cedar Policy with Human-Readable Identifier

permit(
  principal == User::"jane",
  action,
  resource
);

Uses a human-readable name. If jane leaves and a new person reuses the name, they inherit all permissions. Use UUIDs instead.

✓Good - Cedar Policy with UUID Identifier

permit(
  principal == User::"a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  action in Action::"readOnly",
  resource in Album::"publicPhotos"
);

Uses a UUID for the principal identifier, preventing identifier reuse attacks. Also scopes action and resource.

🛡️Defense Recommendations

🔒

Enable STRICT Schema Validation

Always enable STRICT validation mode in production to ensure all policies are validated against the schema before being accepted.

aws verifiedpermissions update-policy-store \
  --policy-store-id PSEXAMPLEabcdefg111111 \
  --validation-settings "mode=STRICT"

🔐

Separate IAM Permissions for Authorization vs. Administration

Grant application roles only IsAuthorized, IsAuthorizedWithToken, and BatchIsAuthorized. Reserve CreatePolicy, UpdatePolicy, DeletePolicy, PutSchema for deployment pipelines and administrators.

{
  "Sid": "AuthorizationOnly",
  "Effect": "Allow",
  "Action": [
    "verifiedpermissions:IsAuthorized",
    "verifiedpermissions:IsAuthorizedWithToken",
    "verifiedpermissions:BatchIsAuthorized"
  ],
  "Resource": "arn:aws:verifiedpermissions::*:policy-store/*"
}

📝

Enable CloudTrail Data Events

IsAuthorized and IsAuthorizedWithToken are data events not logged by default. Enable data event logging to audit all authorization decisions.

🔑

Use UUIDs for All Entity Identifiers

Use universally unique identifiers (UUIDs) for all principal and resource identifiers in Cedar policies. Never use human-readable names that can be reassigned.

🌐

Restrict Identity Source Client IDs

When configuring a Cognito identity source, specify the exact app client IDs that are permitted. Do not leave client ID restrictions empty, as this accepts tokens from any client in the user pool.

🚫

Implement Forbid Policies for Sensitive Actions

Do not rely solely on the absence of permit policies. Explicitly create forbid policies for sensitive actions to ensure denial even if a broad permit policy is accidentally introduced.

forbid(
  principal,
  action in Action::"deleteAccount",
  resource
)
unless { principal in UserGroup::"superAdmins" };

📊

Manage Policies as Code

Store Cedar policies in version control. Use CI/CD pipelines to deploy policy changes. Require code review for all policy modifications. This prevents ad-hoc policy changes that could introduce authorization gaps.

Amazon Verified Permissions Security Card • Toc Consulting

Always obtain proper authorization before testing