S3 Misconfiguration Hunt

Principal "*" means anonymous internet user. Action "s3:*" includes PutObject, DeleteObject, PutBucketPolicy. Anyone on the internet can read, overwrite, or delete every object — and rewrite the policy itself. The principal should have been scoped (or the bucket fronted by CloudFront with origin access identity); action should have been "s3:GetObject" only.

Public principal but scoped to s3:GetObject only and to objects under the bucket (not the bucket itself, so ListBucket isn't granted). This is the canonical "public website" policy. It's only safe because the bucket is supposed to be public, the content has been classified as public, and account-level Block Public Access has been configured to allow this specific bucket. In modern AWS, use CloudFront + origin access control instead — you keep the bucket private and serve through a managed CDN.

"AWS": "...:root" means any IAM principal in account 111122223333, not the root user. So every user, role, and service account in that whole account just got s3:* on the backups bucket — including DeleteObject and PutBucketPolicy. The fix: scope the principal to a specific role (arn:aws:iam::111122223333:role/BackupVerifier) and the action to s3:GetObject + s3:ListBucket.

Principal scoped to a specific role; actions scoped to read-only. The role can list the bucket (needed to enumerate backup files) and get individual objects (needed to verify them). Nothing else. This is the textbook cross-account read-only pattern.

Principal is "*" — not "anyone in our company," but anyone on the internet. The actions include PutObject, so an attacker can upload malware, host phishing pages, or fill the bucket with arbitrary data for which the company gets billed. The intent ("anyone in our company") should have been expressed via IAM identity policies on the company's user roles, not by a public bucket policy.

Principal scoped to a specific role. Action read-only. The Condition requires the request originate from a specific VPC endpoint — so even a stolen role credential cannot be used from outside that VPC. This is the "defense in depth" pattern that the Capital One breach would have benefited from.

The principal is one shared IAM user (named "security-team") — meaning multiple humans share the same access key. There is no attribution if something goes wrong. Use a group of named users, or a role assumed via SSO, not a shared user. Also, s3:* gives that shared user delete permission on a PII archive — least privilege says read-only by default, with a separate elevated path for the rare admin task.

The first statement is fine. The added s3:ListBucket for "*" lets anyone enumerate every file in the bucket. Even if the files are "just images," an attacker can now discover internal-org-chart-draft.png, q4-board-deck-leaked.pdf, or any file someone "temporarily" uploaded. Never grant public ListBucket.

Principal is the CloudTrail service principal (a system-owned identity, not any human or external account). Action is write-only. Resource is scoped to the AWSLogs/ prefix where CloudTrail actually writes. The condition forces the uploaded objects to be owned by the bucket owner (so other accounts can't smuggle objects in with their own ownership). This is the canonical CloudTrail log destination policy.

The aws:Referer header is set by the client. An attacker can trivially forge it (curl -H "Referer: https://partner.example.com/anything"). Referer-based access control was a 1998 idea; it has never been a real security boundary. Use IAM principal-based scoping (give the partner a role to assume in your account) instead. This pattern reappears in audit findings every year.