Object storage leaks — the exposed S3 bucket, the public Azure blob — remain among the most common cloud breaches, and they keep happening for the same reasons. Securing public cloud storage is largely about understanding why it leaks and checking the right things continuously.
Why storage leaks happen
Storage is exposed through a mix of insecure defaults, copy-pasted permissive policies, and simple human error under time pressure. A bucket made public for a quick test, or a policy widened to “make it work,” is easily forgotten, leaving sensitive data readable to anyone who finds the URL.
What to check
Review public-access settings at both the account and bucket level, audit bucket and object policies for overly broad permissions, and confirm that sensitive data is not sitting in storage that is more exposed than it should be. Encryption and access logging matter too, but exposure is the first thing to lock down.
The discovery challenge
You can only secure the buckets you know about, and across many accounts and regions that is harder than it sounds. Forgotten and orphaned storage is exactly where leaks hide, which is why external discovery — finding what is actually reachable — is so valuable.
Continuous assurance
Storage exposure is not a one-time fix; new buckets are created constantly and permissions drift. Continuous external monitoring catches a newly exposed bucket as soon as it appears, rather than at the next quarterly review or, worse, after a researcher or attacker finds it.
Reducing the blast radius
Beyond preventing exposure, limit the damage if it occurs: minimise the sensitive data stored where it need not be, segment access, and ensure logging is on so any access is recorded. Defence in depth turns a potential breach into a contained incident.
How Attack Insights and DarkThreatX help
Attack Insights discovers and assesses internet-reachable cloud storage across providers from the attacker’s perspective, so an exposed bucket is caught fast. DarkThreatX adds context from over 100 billion records, surfacing when exposed data is already circulating.
Common mistakes to avoid
Cloud-storage security fails when teams rely on default settings they never verify, or widen a bucket policy “temporarily” to ship and forget to revert it. A common mistake is checking access settings at only one level — account or bucket — and missing the other. Many never discover all their storage across accounts and regions, so forgotten and orphaned buckets remain exposed. Some store sensitive data in storage that is more open than it should be, with no segmentation or encryption to limit the blast radius. And almost all treat storage security as a one-time fix rather than monitoring continuously as new buckets appear and permissions drift. The dependable approach is continuous external discovery, layered access checks, minimal sensitive data, encryption and logging, so an exposed bucket is caught fast and contained.
Key takeaways
- Storage leaks stem from defaults, broad policies and human error.
- Check public-access settings and policies at every level.
- You can only secure buckets you have discovered.
- Continuous external monitoring catches new exposure fast.
- Limit blast radius with minimal data, segmentation and logging.
Request a demo to see your cloud exposure the way an attacker does.
