Cloud Storage CORS Misconfiguration
Your S3 or GCS bucket has CORS configured with origin: '*' or AllowedMethods: ['*'], letting any website read your storage responses and potentially access private data.
How It Works
CORS on cloud storage controls which web origins can make cross-origin requests to your bucket. A wildcard origin (*) means any website can make JavaScript requests to your bucket and read the responses. If combined with any form of credential-based access (signed cookies, etc.), this can let attacker-controlled pages steal data from authenticated users.
// BAD: S3 CORS config allowing all origins and all methods (Terraform)
resource "aws_s3_bucket_cors_configuration" "example" {
bucket = aws_s3_bucket.example.id
cors_rule {
allowed_origins = ["*"] // any origin
allowed_methods = ["GET", "PUT", "POST", "DELETE"] // all methods
allowed_headers = ["*"]
}
}// GOOD: restrict to your specific app domain and needed methods only
resource "aws_s3_bucket_cors_configuration" "example" {
bucket = aws_s3_bucket.example.id
cors_rule {
allowed_origins = ["https://app.example.com"] // only your domain
allowed_methods = ["GET", "PUT"] // only what you need
allowed_headers = ["Content-Type", "Authorization"]
max_age_seconds = 3600
}
}Real-World Example
Several file-sharing SaaS products were found to have S3 buckets with CORS origin: '*' combined with ACLs that allowed authenticated-read. This let any website read files that users had uploaded with the assumption of privacy, by silently making credentialed cross-origin requests from a malicious page.
How to Prevent It
- Always specify explicit origins in your CORS config — never use '*' for storage buckets containing private data
- Restrict AllowedMethods to only what your app actually uses (usually GET, PUT — not DELETE or POST)
- Set a reasonable MaxAgeSeconds to avoid over-caching of preflight responses
- For upload scenarios, use pre-signed URLs with specific conditions rather than open CORS policies
- Audit storage CORS configs as part of your regular security review
Affected Technologies
Data Hogo detects this vulnerability automatically.
Scan Your Repo FreeRelated Vulnerabilities
S3 Bucket Public Access
criticalYour 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.
Cloud Metadata SSRF
criticalYour app fetches user-supplied URLs without blocking cloud metadata endpoints like 169.254.169.254, letting attackers steal your cloud credentials via SSRF.
AWS Credentials Hardcoded
criticalAWS 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.
IAM Overly Permissive Policy
highYour IAM policy uses Action: '*' or Resource: '*', granting far more permissions than needed and turning any credential leak into a full account takeover.