Cloud Storage Bucket Detection Scanner

Web applications frequently integrate cloud object storage services to host static assets, media files, documents, and user-generated content. Providers such as AWS S3, Google Cloud Storage, Azure Blob Storage, and Cloudflare R2 are widely adopted by organizations of all sizes due to their scalability, availability, and low operational overhead. References to these storage buckets are commonly embedded in HTML attributes, JavaScript bundles, and structured data blocks within the application's front end. Development teams often link directly to bucket URLs for images, stylesheets, downloadable files, and API responses. The breadth of providers in use has grown significantly, with specialized services like Backblaze B2, Wasabi, Oracle OCI, and Yandex Object Storage appearing alongside hyperscaler offerings. Tracking which storage buckets are referenced from a web application is an essential step in mapping the external attack surface of an organization.

Cloud bucket detection refers to the automated identification of object storage URLs that are embedded or referenced within a web application's publicly accessible pages. These references may appear in HTML tag attributes such as href, src, action, data-src, and content, as well as inside inline script blocks and JSON-LD structured data. Each reference potentially exposes the bucket name, cloud provider, and in some cases the storage region, enabling an observer to interact directly with the bucket outside of the web application. Misconfigured buckets that allow public read or write access represent a significant data leakage risk when their names become known through page source analysis. Even buckets that are not publicly accessible by policy can be targeted for enumeration, credential stuffing, or presigned URL abuse once their identifiers are known. Organizations may be unaware that third-party scripts, CDN integrations, or legacy assets are surfacing bucket references to anyone who inspects their page source.

The scanner fetches the target asset's root page via a headless browser with a fallback to plain HTTP, then crawls up to three additional same-domain pages identified through keyword-matched anchor tags including contact, assets, media, files, and uploads. On each collected HTML document, two extraction passes are performed: the first targets attribute values in href, src, action, data-src, data-lazy-src, data-url, content, and value fields; the second targets plain URLs in script blocks and JSON-LD text. Each extracted candidate string is tested against a set of compiled regular expressions covering fourteen cloud providers. Providers matched include AWS S3 in both virtual-hosted and path-style forms, GCS, Azure Blob, Cloudflare R2, DigitalOcean Spaces, Linode Object Storage, Wasabi, Backblaze B2, Oracle OCI, Scaleway, Alibaba OSS, IBM COS, and Yandex Object Storage. For each match, the scanner records the provider label, the extracted bucket name, and the full matched URL. Results are reported as provider, bucket name, and URL triples, with source page annotations in the detailed output.

Discovery of cloud bucket names from page source can enable an attacker to probe the bucket directly for public read access, potentially exposing files, database exports, backups, or confidential documents. Buckets with public write permissions allow an attacker to upload malicious content, overwrite existing files, or conduct storage-based phishing by hosting spoofed pages under a trusted domain. Knowledge of a bucket name and provider may facilitate presigned URL forgery attacks or enumeration of object keys through tools designed to brute-force common file names. Third-party analytics or advertising scripts that reference storage buckets may inadvertently leak sensitive internal asset paths to any party inspecting network traffic or page source. In multi-tenant environments, exposed bucket identifiers can assist in cross-account enumeration if the naming convention reveals account or environment patterns. Regulatory exposure is also possible when personally identifiable or financially sensitive data is stored in a bucket that is reachable from a publicly known URL.