Cloud Provider Security

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.

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

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.

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

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

Your Lambda or Cloud Function allows unauthenticated invocation, meaning anyone on the internet can trigger it without credentials.

Your S3 or GCS bucket doesn't have server-side encryption enabled, meaning data is stored in plaintext on AWS/Google's infrastructure.

Your KMS encryption keys don't have automatic rotation enabled, meaning the same key material is used indefinitely — increasing the risk if the key is ever compromised.

Your IAM trust policy uses a wildcard principal or allows unknown AWS accounts to assume your roles, letting external accounts access your resources.

Your app logs PII, tokens, or credentials to CloudWatch, Stackdriver, or other cloud logging services, where they persist indefinitely and are accessible to anyone with log read permissions.

Your cloud resources are deployed without a VPC or with security groups that allow unrestricted inbound traffic (0.0.0.0/0), exposing internal services to the internet.

Your cloud resources lack environment, owner, or cost-center tags, making it impossible to track ownership, allocate costs, or quickly identify resources during an incident.