Apps using object storage outside AWS and Google Cloud

What this finding means

Not all object storage is on AWS or Google Cloud. DigitalOcean Spaces, Alibaba Cloud OSS, Backblaze B2 and Wasabi all offer buckets, and all four are S3-compatible: they speak enough of the S3 API that standard S3 tooling works against them unchanged.

We have recorded references to these providers in 121 apps.

That compatibility is the point of interest. The exposure modes are identical to S3 — a bucket set to public, an overly broad access policy, a listable root — and so are the tools for finding them. What differs is attention: the large public research sweeps concentrate on AWS and Google, so a misconfigured bucket here has usually been open for longer without anyone mentioning it.

What the severity on these findings actually means

Most of these are recorded at low severity, because a bucket reference on its own establishes nothing. A URL in an APK tells you the app talks to a bucket, not that anyone else can read it.

A finding escalates only when an anonymous request confirmed the bucket answers one. Every critical bucket finding in the corpus carries a stored probe record for that check, which is why the counts are small relative to the references.

There is an honest gap here. Our probe recognises DigitalOcean Spaces, Backblaze B2 and Wasabi, but not Alibaba Cloud OSS, so OSS references are never escalated regardless of their configuration. A low severity on an OSS bucket means we did not check it, not that it is closed.

How to fix it

• DigitalOcean Spaces: set file listing to restricted and check per-object permissions, which are set independently of the Space.
• Alibaba Cloud OSS: set the bucket ACL to private and review bucket policy statements granting the anonymous account.
• Backblaze B2: prefer a private bucket with signed URLs; a public bucket is served from a stable, guessable host.
• Wasabi: the bucket policy follows S3 semantics, so audit it with the same rules you would apply to an S3 bucket policy.
• Across all four: assume any bucket an app references will be found, and make the access decision deliberately rather than inheriting a default.

How we detect it

Provider-specific host patterns are matched against strings in the APK's resources and compiled code. The bucket name and host are recorded; nothing stored in the bucket is ever retrieved or kept.

Where a provider is covered by the probe allow-list, a single unauthenticated request establishes whether the bucket answers anyone. The request uses no credential, follows no redirect, and reads at most a few kilobytes of the response.