Security researchers at Wiz recently examined S3-compatible object storage services across six popular neoclouds, revealing significant security gaps compared to Amazon S3. While S3 has become the de facto standard for object storage, most services lack several of AWS's security protections.
The report compares the security capabilities of managed services offered by Nebius, Crusoe, Vultr, Lambda Labs, Cloudflare R2, and DigitalOcean with Amazon S3. Scott Piper, principal cloud security researcher at Wiz, shows that organizations using S3 clones cannot rely on AWS security assumptions and must account for reduced protections and limited least-privilege capabilities. Piper argues that S3 compatibility creates a dangerous false sense of portability:
There are nearly 300 APIs associated with AWS S3 and its related services (such as S3 tables, S3 vectors, S3 express, and more). All sorts of specialized functionality has been added to S3 over the more than 20 years of its existence, with trillions of objects and hundreds of exabytes of data stored within it. As you should expect, not all of that functionality has been replicated, and some of these S3 clones work in unexpected ways.
According to the study, S3-compatible services vary significantly in how they handle public buckets, with Crusoe and Lambda Labs lacking public-access capabilities, while others provide fewer protections and controls than AWS S3's Block Public Access. For example, Nebius, and Cloudflare R2 allow public buckets but not anonymous object listing, while DigitalOcean supports publicly listable buckets and Vultr supports both ACLs and bucket policies for public access.
Regarding access keys, S3-compatible services often lack the structured access-key formats and secret-scanning support available for AWS ones, making credentials harder for both security teams and tools such as GitHub to detect. Piper explains:
There are other credentials detected by GitHub for DigitalOcean and Cloudflare through GitHub's secret scanning process, but not these. These credentials for the S3 compatible services are also not commonly found by other secret scanners. Part of the reason is that some of these do not have patterns that can be used.
IAM capabilities and semantics differ considerably among S3-compatible implementations, something that has surfaced in the industry through multiple reported vulnerabilities, including one in MinIO that enabled unauthorized privilege escalation and a recent one in RustFS that breaks tenant isolation and authorization semantics.
Corey Quinn, chief cloud economist at The Duckbill Group, summarizes it in his newsletter:
Every neocloud ships an S3-compatible endpoint, and your muscle memory follows you there whether the APIs behave or not. Wiz went poking through Nebius, Crusoe, Vultr and friends in this look at the S3 clones. On one, delete-bucket-policy deleted the entire bucket. Worth reading before you assume Block Public Access exists.
As S3-compatible services inherit presigned URLs from the S3 API, all the clones support this capability and its associated security implications. Rishi Raj Singh, senior solutions engineer at Wiz, writes on LinkedIn:
If you are leveraging S3-compatible storage in neoclouds, ensure your team is explicitly auditing API behavior, verifying permissions models, and validating what happens when standard AWS tooling interacts with these endpoints. Wiz’s review does not cover several other major S3-compatible implementations, including Backblaze B2, Wasabi, and Google Cloud Storage. The S3-compatible storage providers directory currently lists more than 90 providers, while Awesome Object Storage compares 21 providers across hyperscalers, alternatives, edge/CDN-native, self-hosted, and decentralized options.