MinIO: When Your S3-Compatible Storage Lists Everything

#S3-compatible means different things than "S3-secure"

Every team that self-hosts S3 via MinIO thinks they understand S3 security. The API is identical. SDK calls work the same. Bucket policies read the same.

They aren't the same. MinIO inherits the S3 API but not AWS's hardening posture. AWS S3 blocks public access by default since 2023. MinIO ships with no equivalent default. Buckets are accessible based on whatever policy is configured, and the default is often no policy at all.

MinIO assessments open the same way. Hit the deployment. Run one specific request. Get confirmation of anonymous listing on a production bucket. Then find every other bucket with that same config.

#The enumeration chain

1. GET /. returns an XML listing of all buckets if anonymous access is allowed
2. GET /{bucket}. lists all objects in a bucket
3. GET /{bucket}/{key}. downloads any object directly

No authentication headers, no signed URLs, no access tokens. Just plain HTTP GETs.

#What we find in exposed MinIO instances

MinIO is popular for storing:

• Database backups. full SQL dumps with credentials in connection strings
• Log archives. application logs with tokens and PII
• User uploads. documents, images, and files intended to be private
• Build artifacts. compiled binaries, Docker images, and deployment packages

#How we detect this

Our scanner:

1. Requests / and checks for the S3 ListBuckets XML response
2. Enumerates each discovered bucket
3. Samples object keys to assess data sensitivity
4. Tests anonymous PUT to check for write access

#Defense

• Set bucket policies that deny anonymous access
• Enable MinIO's built-in identity management
• Use mc admin policy to configure granular access
• Never expose MinIO's API port directly to the internet
• Use presigned URLs for temporary access to specific objects