AWS IAM Policy with Wildcard Resources

High Risk Infrastructure Security
awsiamauthorizationwildcardleast-privilegeaccess-controlprivilege-escalationterraformcloudformation

What it is

A critical authorization vulnerability where IAM policies grant permissions using wildcard (*) resources instead of specific ARNs, creating overly broad access that violates the principle of least privilege. This allows principals to perform actions on unintended resources across the entire AWS account, enabling privilege escalation, unauthorized data access, and potential account compromise. Wildcard resources in IAM policies can lead to unintended permissions that allow access to sensitive resources, cross-service privilege escalation, and compliance violations.

# VULNERABLE: IAM policy with wildcard resources
resource "aws_iam_policy" "s3_access" {
  name        = "s3-access-policy"
  description = "Policy for S3 access"
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",
          "s3:PutObject",
          "s3:DeleteObject"
        ]
        # VULNERABLE: Grants access to ALL S3 buckets
        Resource = "*"
      },
      {
        Effect = "Allow"
        Action = [
          "dynamodb:GetItem",
          "dynamodb:PutItem",
          "dynamodb:DeleteItem"
        ]
        # VULNERABLE: Grants access to ALL DynamoDB tables
        Resource = "*"
      },
      {
        Effect = "Allow"
        Action = [
          "secretsmanager:GetSecretValue"
        ]
        # VULNERABLE: Can read ALL secrets
        Resource = "*"
      }
    ]
  })
}
# SECURE: IAM policy with specific resource ARNs
resource "aws_iam_policy" "s3_access" {
  name        = "s3-access-policy"
  description = "Policy for specific S3 bucket access"
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",
          "s3:PutObject",
          "s3:DeleteObject"
        ]
        # SECURE: Specific bucket ARNs only
        Resource = [
          "arn:aws:s3:::my-app-bucket/*",
          "arn:aws:s3:::my-app-uploads/*"
        ]
      },
      {
        Effect = "Allow"
        Action = [
          "dynamodb:GetItem",
          "dynamodb:PutItem",
          "dynamodb:DeleteItem"
        ]
        # SECURE: Specific table ARN
        Resource = "arn:aws:dynamodb:us-east-1:123456789012:table/app-data"
      },
      {
        Effect = "Allow"
        Action = [
          "secretsmanager:GetSecretValue"
        ]
        # SECURE: Specific secret ARN with path pattern
        Resource = "arn:aws:secretsmanager:us-east-1:123456789012:secret:app/database/*"
      }
    ]
  })
}

💡 Why This Fix Works

The vulnerable examples show IAM policies with wildcard resources that grant excessive permissions across all resources. The secure alternatives demonstrate specific resource ARNs, condition statements, and proper access scoping that follows the principle of least privilege while maintaining functionality.

Why it happens

Developers use Resource: '*' in IAM policies to avoid specifying individual resource ARNs, often during rapid development or when unsure of exact resource requirements. This creates overly broad permissions that grant access to all resources of a given type, violating security best practices and potentially exposing sensitive data or allowing unintended operations.

Root causes

IAM Policies with Resource Wildcard for Convenience

Developers use Resource: '*' in IAM policies to avoid specifying individual resource ARNs, often during rapid development or when unsure of exact resource requirements. This creates overly broad permissions that grant access to all resources of a given type, violating security best practices and potentially exposing sensitive data or allowing unintended operations.

Copy-Paste of Overprivileged Policy Examples

Teams copy IAM policy examples from documentation or tutorials that use wildcard resources for simplicity, without adapting them for production use with specific resource restrictions. These examples are often designed for demonstration purposes and lack the precision required for secure production environments.

Fixes

1

Replace Wildcards with Specific Resource ARNs

Identify the exact resources that need access and replace Resource: '*' with specific ARN patterns. Use resource-level permissions that include account ID, region, and resource names. Implement condition keys to further restrict access based on tags, time, IP addresses, or other contextual factors.

2

Implement Least Privilege Access Patterns

Design IAM policies that grant only the minimum permissions necessary for the intended function. Use separate policies for different functional areas, apply condition statements to restrict access scope, and regularly audit permissions to ensure they remain aligned with actual requirements.

3

Use IAM Access Analyzer and Policy Validation

Deploy AWS IAM Access Analyzer to identify overly broad permissions and unused access grants. Use IAM policy simulator to test permissions before deployment, and implement automated policy validation in CI/CD pipelines to prevent wildcard resources from reaching production environments.

Detect This Vulnerability in Your Code

Sourcery automatically identifies aws iam policy with wildcard resources and many other security issues in your codebase.

Scan Your Code for Free Explore More Vulnerabilities