A single forgotten role can bleed your AWS S3 data dry.

AWS S3 read-only roles sound harmless. They aren’t. A read-only IAM role with the wrong scope can expose customer data, internal documents, or production assets to anyone who finds a way in. The danger hides in plain sight because read-only feels safe. But S3 read access without tight boundaries can be as dangerous as write or delete if the wrong party gets it.

Auditing AWS S3 read-only roles means going beyond the IAM policy name. You have to ask:

• Which buckets can this role read?
• Can it list all buckets?
• Does it expose sensitive prefixes within a bucket?
• Who or what can assume this role?
• Are there trust relationships that connect it to other accounts or services?

The first step is inventory. Pull a complete list of IAM roles with s3:GetObject, s3:ListBucket, or wildcard permissions that include them. Avoid blind spots by scanning inline policies, managed policies, and group attachments.

Next, map trust policies. Even a perfect read-only bucket policy is useless if an external AWS account can assume the role without restriction. Cross-account access to S3 read roles is one of the most common leaks. Watch for Principal: "*" and overly broad AWS account IDs.

Then, audit bucket policies. Sometimes the role’s own permissions are minimal, but the bucket policy grants that role access to extra data. Look for public "Effect": "Allow" statements and s3:* actions that override your intentions.

Finally, tighten scope. Use resource-level permissions for each bucket or prefix. Deny listing of buckets outside the role’s scope. Limit role assumptions to specific services or AWS accounts with explicit conditions like aws:PrincipalArn or aws:SourceIp.

Automation is key here. Manual reviews miss things. Policies change. Services evolve. Attackers move faster than human checklists. A continuous auditing process for AWS S3 read-only roles prevents quiet permission leaks from turning into headline breaches.

If you want to see this level of S3 role auditing working end-to-end without building it yourself, check out hoop.dev. You can watch it uncover excessive S3 read permissions and test fixes live in minutes.