Cloud Storage Listings

Nikto Platform detects anonymous object listings on Amazon S3, S3-compatible buckets, and Azure Blob Storage containers — a bucket or container that hands any unauthenticated visitor the names (and sizes) of everything inside it.

What is detected

Provider	Listing document	Covered
Amazon S3	ListBucketResult XML (list-objects v1 and v2)	Yes
S3-compatible services — DigitalOcean Spaces, MinIO, Ceph RGW, Wasabi, Backblaze B2 (S3 API), Cloudflare R2, Linode/Akamai Object Storage, Alibaba Cloud OSS, Google Cloud Storage XML API	Same ListBucketResult XML	Yes
Azure Blob Storage	Container listing (EnumerationResults XML)	Yes

A Nikto scan requests S3 bucket roots and Azure container listings as part of its normal work. A Crawl also detects a listing if it fetches one.

Anything that lists over JSON is not covered — the Google Cloud Storage JSON API and provider-specific JSON listing endpoints are not recognized. The detector keys on the XML listing document itself, not on the hostname, so a bucket served from a custom domain or a reverse proxy is detected the same way.

How it runs

Any successful response from a Nikto or Crawl scan is checked for a listing document.

Bounded walk. The scan then follows the listing's own next-page links for up to 5 pages, to estimate how big the exposure is. Page size is whatever the server returns — typically 1,000 objects for S3 and 5,000 for Azure.

The finding.

Field	Value
Title	S3 Bucket Listing Enabled or Azure Blob Container Listing Enabled
Severity	medium
Description	The bucket/container name and URL, the provider, which listing API was used, how many pages were walked, and the file and byte totals.
References	The first 10 object URLs, so you can spot-check what is exposed.

A trailing + on the file count means the numbers are a floor, not a total. Two different stops both produce that mark:

Why the walk stopped	What the finding says
The listing continued past the 5-page scan cap	The listing continues past the 5-page scan cap; use the recommendation to export the full list.
A listing page exceeded the response size limit and was cut off	A listing page exceeded the response size limit and was truncated, so these counts are a floor and the remaining pages could not be requested.

The size-limit stop is not the 5-page cap.

If the walk stopped early for any other reason — a page returned a non-200, a request got no response, a page was not a listing document, or the server claimed more results without giving a usable continuation token — the description says which page stopped it and why, and the counts are marked as a floor. It never reports a truncated walk as a complete one.

In Nikto Modules, this is Cloud Storage Listing. Leave it enabled (the default) to detect open listings. It does nothing on a host that has none.

Getting the full list

Alongside the finding, a recommendation titled Cloud Storage: Export full file list appears. The action button on that row is Export full file list. Clicking it starts a background export run: the server walks every page of the listing, shows progress on the row (Queued…, Walking page N, Ready), and stores the finished object list — a single HTML file, or a zip of HTML chapters for very large listings — for you to Download later. Nothing downloads at the click. You can Cancel from the row or from Active Jobs. HTML output carries a Nikto Platform banner (inline CSS and text only).

If a listing page is cut off by the response size limit, the export fails with that reason and stores no file. The scan finding already records the counts as a floor.

The export uses the same listing URL the scan found (same folder/prefix, same Azure container listing), starting at page 1. Listings found by a Crawl are exportable the same way.

See Export full file list for the run states, cancel, retention, the caps, and the refusal cases.

Remediation

Amazon S3 and S3-compatible services. Turn on Block Public Access for the bucket (and at the account level), then remove s3:ListBucket from any anonymous or AllUsers/AuthenticatedUsers grant in the bucket policy and ACL. Serving public objects does not require public listing — keep object reads public if you need them, and close the listing. On S3-compatible services the equivalent is the bucket's anonymous/public read-list permission.

Azure Blob Storage. Set the container's public access level to Private (no anonymous access). Blob access still serves objects to anyone with the exact URL but stops container enumeration; Container access is the setting that exposes the listing.

Either way, treat the listed names as disclosed. Review every object the export turned up and rotate or remove anything that should not have been enumerable.