Home / Core Health / Check for publicly exposed cloud storage buckets
Exposed Files · Scan Check Guide

Check for publicly exposed cloud storage buckets

20 min Impact: high Effort: medium ✓ Scan-verified — no manual checkbox

A misconfigured cloud storage bucket (AWS S3, Google Cloud Storage, Azure Blob) set to public when it shouldn't be can expose every file inside it — user uploads, internal documents, backups — to anyone who finds or guesses the bucket name.

An S3, GCS, or Azure Blob storage bucket named after your domain, left with public read access, is a common and often accidental way to expose backups, user uploads, or internal files.

The full picture

Publicly exposed cloud storage buckets represent one of the more consequential, commonly-exploited misconfigurations in modern web infrastructure, since these buckets frequently contain substantial volumes of data — user uploads, backups, internal documents — that were never intended for public access but become directly accessible due to overly permissive access configuration.

This category of vulnerability has been responsible for numerous significant, well-documented data breaches across many organizations, typically arising from cloud storage being configured with public read access, either through initial misconfiguration or through a later configuration change that inadvertently loosened access restrictions that were previously appropriately set.

The genuine severity here depends entirely on what data the exposed bucket actually contains — a bucket storing genuinely public assets like website images poses little risk if exposed, while a bucket containing user data, internal documents, or other sensitive content represents a genuinely severe exposure comparable in impact to the other high-severity exposed-file vulnerabilities discussed throughout this security work.

Identifying and correcting this risk requires genuinely auditing your actual cloud storage configuration against the principle of least privilege — access should be explicitly restricted to only what's genuinely necessary for legitimate application functionality, with any bucket containing sensitive content specifically verified to have no unintended public read or write access.

How to fix it

  1. 1
    Identify every cloud storage bucket your site uses
    Check your codebase and asset URLs for S3, GCS, or Azure Blob references.
  2. 2
    Review each bucket's public access settings
    In your cloud provider's console, check whether the bucket (and its contents) is set to public, and whether that's actually intentional.
  3. 3
    Restrict anything that shouldn't be public
    Set buckets containing user data, internal files, or backups to private, and serve any legitimately public assets (like site images) through a signed-URL or CDN pattern instead.
  4. 4
    Check bucket listing specifically
    Even a bucket with private files can leak a full list of filenames if bucket LISTING itself is left public — restrict this separately from individual file access.

Common mistakes

How you'll know it's done

Every cloud storage bucket's public/private setting matches what it should actually be, and bucket listing is disabled unless deliberately public.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →