A clean Git repository does not prove that your live Amazon S3 buckets are private. Check the permissions and policies in AWS, then separately look for sensitive data stored in objects. IAM Access Analyzer for S3 helps identify public and cross-account sharing; Amazon Macie helps discover sensitive data. Neither finding alone proves that a credential has been exposed or used.
What an S3 security review can—and cannot—find
Repository scanners inspect files in Git. They do not establish whether a live bucket is reachable through an S3 bucket policy, ACL, access-point policy, Multi-Region Access Point policy, or an identity policy attached to a user or role. Those permissions must be reviewed in the AWS environment. AWS describes these access paths in its S3 access-control guidance.
There are two distinct questions: who can reach S3 data, and whether sensitive information is stored there. IAM Access Analyzer for S3 can surface public and cross-account access. Macie can discover sensitive data using machine learning and pattern matching. Finding sensitive data in an object does not by itself show that it was publicly accessible, retrieved, or misused.
How to check whether an S3 bucket is public or shared
- Inventory the relevant buckets. Use your organization’s approved inventory process across the AWS accounts and Regions in scope; a review of one bucket or account does not establish the posture of the rest.
- Review IAM Access Analyzer for S3 findings. For each public or external-access finding, record whether the sharing is expected. AWS explains how to review the reported access source and level in its IAM Access Analyzer for S3 guide.
- Inspect the grant source. Check the specific ACL, bucket policy, access-point policy, or Multi-Region Access Point policy identified by the finding. Also examine identity-based policies for principals that can access the bucket, and relevant AWS KMS key policies and grants if objects use SSE-KMS.
- Compare permissions with the use case. For each grant, assess the principal, allowed action, and resource scope. Remove broad wildcard access that is not required and narrow permissions to the intended readers, writers, and objects.
- Record intentional sharing. If public or cross-account access is necessary, document the purpose, permitted objects or paths, and owner. Access Analyzer lets you archive findings that have been reviewed as intentional; archival records a decision, not a security fix.
Access Analyzer findings and S3’s own public-access evaluation can differ in uncommon policy cases. Investigate the actual policy, especially unsupported actions, rather than treating either view as infallible.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
How to prevent unintended public access
Amazon S3 Block Public Access provides four independent settings that can be applied at organization, account, bucket, and access-point scopes. AWS recommends enabling all four at both account and bucket level, and considering organization-level enforcement when managing multiple accounts. S3 applies the most restrictive applicable settings. See AWS’s Block Public Access documentation for setting behavior and scope.
Before enabling or tightening these controls, verify whether an application intentionally depends on public access—for example, a static website or public downloads. Preserve only documented, necessary exceptions and scope them as narrowly as possible. Block Public Access does not replace reviewing identity-based policies or associated resources such as KMS keys.
Rank #2
Choose policy and ownership controls that fit the workload
For most modern workloads, AWS recommends disabling ACLs and using policy-based access. S3 Object Ownership defaults to Bucket owner enforced, which disables ACLs. Keep ACLs only when a genuine requirement needs object-level ACL behavior.
The policy mechanism should match the scale and shape of access. A bucket policy can work well for one or a small number of buckets with similar requirements; identity-based policies can be easier to manage when a few roles need access across many buckets. Access points and S3 Access Grants offer additional ways to manage scaled or more granular sharing. Whichever mechanism you use, apply least privilege and include it in the review—no single policy view necessarily represents every route to the data.
Encryption protects stored data, not permission boundaries
New S3 objects are encrypted at rest by default with SSE-S3. SSE-KMS is available when customer-managed key controls are needed. Encryption at rest does not prevent an authenticated caller who has the required permissions from retrieving an object. Review S3 permissions alongside KMS key policies and grants; do not use encryption as a substitute for access control.
Require HTTPS for requests in transit. AWS’s S3 security best practices describe using an aws:SecureTransport condition in a bucket policy to deny insecure transport. Ensure the condition fits the workload and does not inadvertently block required service access.
Rank #4
Keep the review continuous with the right AWS signals
These controls answer different questions, so combine them rather than treating one as a complete audit:
| Control | What it helps you determine |
|---|---|
| IAM Access Analyzer for S3 | Whether a bucket has public or cross-account sharing, and the reported policy or ACL source. |
| CloudTrail data events | Which object-level operations—such as GetObject, PutObject, and DeleteObject—occurred, when data-event logging is configured for the relevant resources. |
| AWS Config | Whether tracked resource configuration meets selected rules and whether configuration changes create drift. AWS Config managed rules cited in its security guidance support general purpose buckets, not directory buckets. |
| Amazon Macie | Whether S3 contains potentially sensitive data identified through machine learning and pattern matching. |
CloudTrail data events provide object-level activity visibility when configured; they are not the same as reviewing current permissions. AWS Config checks configuration states, while Access Analyzer focuses on sharing and Macie on sensitive content. Choose coverage based on the questions you need answered, and revisit findings and documented exceptions regularly.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
