Cloud Storage Exposure - Shieldome Docs

What is cloud storage exposure?

Cloud object storage services (S3, GCS, Azure Blob, DigitalOcean Spaces) are frequently misconfigured to allow public access. When a bucket is publicly listable, anyone on the internet can enumerate its contents - exposing source code, user data, private documents, and credentials stored in configuration files.

Shieldome automatically checks for publicly accessible buckets that are likely associated with your target domain.

☁

Passive check. Shieldome only makes HTTP GET requests to known bucket URL patterns. It does not upload, modify, or download content. A 403 response (bucket exists but is private) is reported as INFO - not a vulnerability.

How bucket names are derived

Shieldome generates several candidate bucket names based on your target domain:

example - base domain without TLD
example-com - full domain with dots replaced by dashes
example.com - full domain (used where supported)

These names are checked across all supported providers and regions.

Providers checked

Provider	URL patterns checked
Amazon S3	`https://<bucket>.s3.amazonaws.com/`
Google Cloud Storage	`https://storage.googleapis.com/<bucket>/`
Azure Blob Storage	`https://<account>.blob.core.windows.net/<container>/` - tries containers: `$web`, `public`, `assets`, `static`, `uploads`, `media`
DigitalOcean Spaces	`https://<bucket>.<region>.digitaloceanspaces.com/` - tries regions: `nyc3`, `sfo3`, `ams3`, `sgp1`, `fra1`

Severity levels

Response	Severity	Meaning
200 OK with directory listing XML	CRITICAL	Bucket is publicly listable - all object keys are enumerable by anyone
403 Forbidden	INFO	Bucket exists but is private - this is the correct configuration
No response / 404	Not reported	No bucket found at this name pattern

Detecting exposure: what the check looks for

A public listing is confirmed when the response body contains one of the following XML signatures:

ListBucketResult - S3 and GCS public listing response
EnumerationResults - Azure Blob listing response
<Contents> - S3 object entries within a listing
<Blobs> - Azure Blob entries within a listing

Remediation

If Shieldome reports a CRITICAL cloud exposure finding:

Disable public access immediately - use the provider console or CLI to block all public access at the bucket/account level
Audit the bucket contents - determine what was exposed and whether any sensitive data (PII, credentials, source code) was accessible
Check access logs - most providers offer access logging; review logs to determine whether external parties enumerated or downloaded objects
Rotate any credentials that may have been stored in exposed files (environment files, config files, key pairs)
Enable bucket versioning and object locking as a best practice to prevent accidental deletion

AWS S3 - block public access

bash

aws s3api put-public-access-block \
  --bucket YOUR-BUCKET-NAME \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Google Cloud Storage - remove public access

bash

gsutil iam ch -d allUsers gs://YOUR-BUCKET-NAME

Azure Blob - disable anonymous access

bash

az storage account update \
  --name YOUR-STORAGE-ACCOUNT \
  --allow-blob-public-access false