S3 has had sensible secure defaults since 2018. Block Public Access is on by default at the account level. New buckets are private. IAM rejects the common permission errors that produced the 2016–2017 era of catastrophic bucket exposure. And yet, every major cloud breach report published in 2026 still contains S3 findings. The category has shifted — from “bucket is world-readable” to more subtle misconfigurations that pre-date default protections, or that were explicitly opted-in, or that expose data through paths the default controls do not cover.
This is the current state of S3 misconfiguration — the ones still producing breaches, organized by root cause, with detection guidance for each.
1. Legacy buckets predating Block Public Access
Accounts created before S3 Block Public Access became the default still have buckets from that era. Those buckets may carry public ACLs, public bucket policies, or both. The account-level BPA setting blocks new public access but does not retroactively remove existing public grants.
Detection: run aws s3api list-buckets, then for each bucket aws s3api get-public-access-block and aws s3api get-bucket-policy. Any bucket without BPA enabled at the bucket level, or with a bucket policy granting access to "Principal": "*", needs investigation.
Remediation: enable Block Public Access at the bucket level on every non-intentionally-public bucket. For intentionally public (static website, public asset hosting) buckets, audit the policy to verify only the specific objects or prefixes intended to be public are actually public.
2. Signed URLs with long validity windows
S3 presigned URLs are a legitimate mechanism — time-limited access to a private object. The default URL validity in many SDKs is one hour; some applications generate URLs with 7-day validity, or longer. When those URLs leak — chat histories, support tickets, logs, email archives — they provide access to the object for the remainder of the validity window.
Detection is behavioral: audit application code for generate_presigned_url calls with ExpiresIn values greater than 86400 (24 hours). Check logs for URL exposure; unusual user-agent access to specific presigned URLs is a signal.
Remediation: cap validity at the shortest practical duration for the use case. One hour is sufficient for most interactive use cases. For longer-lived access, use IAM-based authentication rather than URL-based.
3. Cross-account access to decommissioned relationships
Vendor integrations, partner data shares, acquired-and-spun-off business units — each might have granted S3 cross-account access at some point. The grants persist after the business relationship ends. An attacker who compromises the partner account, or who purchases the expired domain/account, gains access to your bucket.
Detection: aws iam list-roles in relevant accounts, review each role’s trust policy for principals in external AWS accounts. For S3 specifically, bucket policies with external Principal values.
Remediation: quarterly audit of all cross-account grants. Require documented business justification and review cadence for each.
4. Public read on individual objects within private buckets
Block Public Access at the bucket level does not always retroactively override object-level ACLs that predated it. An object uploaded with x-amz-acl: public-read may still be public even in a bucket now marked private.
Detection: sample objects from suspect buckets, check aws s3api get-object-acl for each. For comprehensive scan, use aws s3api list-objects-v2 and iterate.
Remediation: use s3api put-bucket-ownership-controls to set BucketOwnerEnforced, which disables ACLs entirely. This is the 2026 best practice — all access determined by policy, no ACLs.
5. Overly permissive bucket policies
A bucket policy that allows "Principal": {"AWS": "*"} inside the organization is functionally world-writable from any principal inside the organization. With a large enough organization, this is effectively public. Similarly, policies with IP-restriction ("Condition": {"IpAddress": {...}}) that use a broad CIDR inadvertently include attacker-controllable ranges.
Detection: IAM Access Analyzer flags most of these. For anything missed, regex audit of bucket policies for wildcards and broad conditions.
6. Misconfigured CloudFront distributions
A CloudFront distribution configured to access a private S3 bucket as origin, but with the S3 bucket incorrectly configured to trust any CloudFront distribution (not just the specific one), is bypassable. An attacker creates their own CloudFront distribution pointing at your bucket and fetches your data.
Detection: bucket policies using aws:SourceArn conditions scoped to specific distribution ARNs only, not to arn:aws:cloudfront::*.
7. Exposed data via unintended access paths
S3 is accessed through SDK calls, through the console, through third-party SaaS integrations, and through applications. A bucket that is private to direct API calls might still be exposed through a vulnerable application that fetches arbitrary keys based on user input (classic IDOR on an object-storage path).
Detection: penetration testing. Scanners do not find these.
8. Backups and snapshots leaking sensitive data
AWS Backup, EBS snapshots, and RDS snapshots can be shared cross-account. Sharing with all (public) is a catastrophic misconfiguration and still occurs. Sharing with specific accounts for legitimate purposes can persist beyond the need.
Detection: aws ec2 describe-snapshots --owner-ids self --restorable-by-user-ids all for public EBS snapshots. aws rds describe-db-snapshots --include-public for RDS.
9. Metadata and versioning caveats
S3 versioning-enabled buckets retain all object versions. “Deleting” an object creates a delete marker; previous versions remain retrievable by anyone with s3:GetObjectVersion. A bucket made private after being public may still have the previous-public versions retrievable.
Remediation: when locking down a previously-public bucket, suspend versioning temporarily or explicitly delete old versions of sensitive objects.
10. Replication to unsecured destinations
S3 Cross-Region Replication and Cross-Account Replication configured to copy data to a destination bucket that is less secure than the source. The source bucket may be locked down; the replica in another account or region is exposed.
Detection: aws s3api get-bucket-replication for each bucket; verify destination buckets meet equivalent security standards.
Detection tooling
- AWS IAM Access Analyzer — free, catches most cross-account exposure automatically
- Security Hub — aggregates findings across multiple AWS security services
- CloudMapper, ScoutSuite, Prowler, CloudSploit — open-source multi-cloud configuration scanners
- S3 Inventory — produces a daily manifest of every object and its properties
- S3 Storage Lens — organization-wide view of S3 usage and security metrics
Related reading
- Cloud Security for Indian Businesses: The Complete Guide
- AWS Security Audit: The 47-Point Checklist
- AWS IAM Best Practices for Indian SaaS
For an S3 and cloud storage audit across your AWS accounts, book a scoping call.