IAM Overly Permissive Policy

Your IAM policy uses Action: '*' or Resource: '*', granting far more permissions than needed and turning any credential leak into a full account takeover.

How It Works

The principle of least privilege means giving each role exactly the permissions it needs — nothing more. Action: '*' with Resource: '*' is essentially admin access. When these credentials are stolen (via SSRF, hardcoded keys, or phishing), the attacker can do anything: delete databases, exfiltrate all S3 data, create new admin users, disable CloudTrail logging. Least privilege limits the blast radius of any credential compromise.

Vulnerable Code

// BAD: wildcard IAM policy (Terraform)
resource "aws_iam_role_policy" "app_policy" {
  role = aws_iam_role.app.id
  policy = jsonencode({
    Statement = [{
      Effect   = "Allow"
      Action   = "*"        // can do ANYTHING
      Resource = "*"        // on ANY resource
    }]
  })
}

Secure Code

// GOOD: minimal permissions scoped to specific resources
resource "aws_iam_role_policy" "app_policy" {
  role = aws_iam_role.app.id
  policy = jsonencode({
    Statement = [{
      Effect   = "Allow"
      Action   = ["s3:GetObject", "s3:PutObject"]  // only what the app needs
      Resource = "arn:aws:s3:::my-app-bucket/*"    // only this bucket
    }]
  })
}

Real-World Example

The 2019 Capital One breach escalated from an SSRF vulnerability to a full data dump because the compromised EC2 instance had an IAM role with s3:GetObject on Resource: '*' — not just the specific buckets the app needed. Proper scoping would have limited the breach to a single bucket.

How to Prevent It

Start with zero permissions and add only what's needed — never start with '*' and restrict later
Use AWS IAM Access Analyzer to identify overly permissive policies in your account
Scope Resource to specific ARNs (arn:aws:s3:::my-bucket/*) rather than '*'
Use AWS managed policies only as a starting point — create custom policies for production workloads
Audit IAM policies quarterly using AWS IAM Credential Report and Access Advisor

Affected Technologies

Node.jsPython

Data Hogo detects this vulnerability automatically.

Scan Your Repo Free

Related Vulnerabilities

S3 Bucket Public Access

critical

Your S3 bucket is publicly readable due to a public ACL, disabled Block Public Access settings, or a wildcard bucket policy — anyone on the internet can list and download your files.

CWE-284OWASP A05:2021

Cloud Metadata SSRF

critical

Your app fetches user-supplied URLs without blocking cloud metadata endpoints like 169.254.169.254, letting attackers steal your cloud credentials via SSRF.

CWE-918OWASP A10:2021

AWS Credentials Hardcoded

critical

AWS access keys (starting with AKIA) or secret access keys are hardcoded in your source code, giving anyone who reads the code full access to your AWS account.

CWE-798OWASP A02:2021

Cloud Storage CORS Misconfiguration

medium

Your S3 or GCS bucket has CORS configured with origin: '*' or AllowedMethods: ['*'], letting any website read your storage responses and potentially access private data.

CWE-942OWASP A05:2021