⌘K
GitHub
conceptAttack Surface Mapping~4 min readUpdated Apr 29, 2026#cybersecurity#attack-surface-mapping#storage#data-exposure

Exposed Storage

Definition

Exposed storage is any file, object, artifact, backup, log, or document storage surface that is reachable beyond its intended audience through public access, weak policy, predictable paths, inherited trust, or forgotten publishing.

Why it matters

Storage exposure often becomes a quiet data leak rather than a dramatic exploit. Backups, logs, source maps, CI artifacts, upload folders, screenshots, exports, and internal documents are easy to publish and hard to govern.

Keep this distinct from File Upload Abuse: that note is about application logic accepting files; this note is about storage as exposed attack surface.

How it works

Exposed storage has 5 storage surfaces:

  1. Object storage. S3 buckets, Azure Blob, GCS buckets, CDN-backed objects.
  2. Web-served files. Uploads, static directories, backups, logs, source maps, and exports.
  3. Build and release artifacts. CI outputs, packages, container layers, symbols, and bundles.
  4. Documents and reports. PDFs, spreadsheets, screenshots, internal docs, and support attachments.
  5. Indexes and listings. Directory listing, bucket listing, search indexing, and predictable filenames.

The bug is not that files are hosted. It is that the access model does not match the sensitivity and lifecycle of the stored content.

A worked example, public file to exposure decision:

URL:
  https://cdn.example.test/releases/app.js.map

Content:
  source paths, API route constants, comments, no live secrets

Sensitivity:
  implementation and endpoint disclosure

Trust/lifecycle clue:
  artifact generated by production build, not a forgotten backup

Decision:
  medium exposure: remove public source maps or publish intentionally with review;
  follow up on routes discovered from the map

The same public-read fact can be low, medium, or critical depending on content, owner, and downstream trust.

Techniques / patterns

Practitioners look for:

  • public buckets, containers, and CDN paths
  • directory listing and predictable backup names
  • .map, .bak, .old, .zip, .tar.gz, .sql, .env, .log
  • CI/CD artifacts linked from public jobs
  • uploaded files accessible without authorization
  • search-indexed documents and cached files
  • stale storage tied to old environments or vendors

Variants and bypasses

Exposed storage appears in 7 forms.

1. Public object bucket

Bucket policy allows public read or listing unintentionally.

2. Predictable backup path

Backups, dumps, or archives are served from guessable URLs.

3. Source map and bundle exposure

Frontend artifacts reveal routes, secrets, internal names, or source structure.

4. Upload authorization mismatch

Files require auth to upload but not to retrieve.

5. CI/CD artifact exposure

Build logs, packages, screenshots, reports, or test outputs are publicly reachable.

6. Search-indexed private content

Sensitive files become discoverable through search or cached pages.

7. Stale vendor or environment storage

Old storage remains after migration, offboarding, or environment teardown.

Impact

Ordered roughly by severity:

  • Credential or secret leakage. Logs, .env, source maps, or artifacts expose tokens and keys.
  • Sensitive data disclosure. Customer data, documents, reports, and exports leak.
  • Source and route disclosure. Bundles and maps reveal hidden endpoints and implementation details.
  • Supply-chain risk. Public artifacts can expose build process or package metadata.
  • Brand and compliance risk. Public documents and backups create long-lived exposure.

Detection and defense

Ordered by effectiveness:

  1. Classify storage by sensitivity and intended audience. Public content and private artifacts should live under different buckets, policies, and review workflows.

  2. Deny public access by default. Public read should be an explicit exception, not inherited from convenience defaults.

  3. Tie storage lifecycle to application and environment lifecycle. Retiring an app should retire buckets, CDN paths, artifacts, and DNS references.

  4. Scan for risky extensions, source maps, and listings. Automated checks catch common accidental exposures before attackers do.

  5. Authorize file retrieval, not just upload. Private uploads need access checks at download and preview time.

  6. Log and monitor object access. Public object reads and unusual download spikes should be visible.

What does not work as a primary defense

  • Unlinked URLs. Search, logs, referrers, wordlists, and predictable names reveal files.
  • Random filenames alone. Entropy helps but does not replace access control.
  • Bucket names as secrets. Bucket names and CDN paths leak through traffic and docs.
  • One-time cleanup. Storage drift follows every build, export, and environment change.

Practical labs

Use owned assets.

Search for risky static artifacts

rg -n "\\.(map|bak|old|zip|tar\\.gz|sql|env|log)$" public dist docs

Decide whether each file is intentionally public.

Check source map exposure

curl -I https://app.example.test/static/app.js.map

Source maps may reveal source and routes even without secrets.

Test upload retrieval authorization

curl -i -H "Authorization: Bearer $USER_A" https://app.example.test/files/123
curl -i -H "Authorization: Bearer $USER_B" https://app.example.test/files/123

User B should not retrieve User A's private file.

Check bucket listing posture

curl -i https://storage.example.test/

Listings and XML index responses deserve review.

Classify exposed file contents

file | source | public? | data class | secrets? | owner | remove/keep | follow-up

Classification prevents treating a logo, source map, and database dump as the same kind of exposure.

Check indexed documents

site:example.test filetype:pdf internal
site:example.test filetype:xls OR filetype:xlsx
site:example.test inurl:backup OR inurl:export

Use search results as leads; verify access and sensitivity before escalating.

Practical examples

  • A public bucket exposes build artifacts or source maps.
  • Uploaded files are publicly accessible even when they should be private.
  • A backup archive is reachable by predictable URL.
  • CI logs expose environment variables.
  • Old staging storage remains public after the app is deleted.

Suggested future atomic notes

  • source-map-exposure
  • public-bucket-review
  • predictable-backup-files
  • ci-artifact-exposure
  • file-download-authorization

References

  • Foundational: OWASP WSTG latest — https://owasp.org/www-project-web-security-testing-guide/latest/
  • Foundational: CISA Secure by Design — https://www.cisa.gov/resources-tools/resources/secure-by-design
  • Foundational: OWASP ASVS — https://owasp.org/www-project-application-security-verification-standard/

Explore nearby notes

Attack Surface MappingAdmin Interface DiscoveryAdmin interface discovery is the process of identifying management, control-plane, support, diagnostic, or privileged interfaces that should be restricted but may... Attack Surface MappingAttack Surface MappingAttack surface mapping is the practice of identifying which assets, services, routes, interfaces, dependencies, data stores, environments, and trust relationships... Attack Surface MappingDeprecated API VersionsDeprecated API versions are old, superseded, beta, mobile, partner, or legacy endpoints that remain reachable after the organization believes clients have moved on. Attack Surface MappingEndpoint DiscoveryEndpoint discovery is the process of finding reachable routes, APIs, handlers, parameters, methods, and hidden request surfaces beyond what the visible UI or... Attack Surface MappingExposed Service TriageExposed service triage is the process of turning discovered network services into security decisions: expected public surface, undocumented side door, forgotten... Attack Surface MappingExternal Attack SurfaceExternal attack surface is the set of assets, services, interfaces, data stores, and trust paths reachable from outside the organization's internal networks — most...