domains / families / security / hunt-source-leak

hunt-source-leak

combined

Hunt source code and build artifact leakage Hunt source code and build artifact leakage — JavaScript source maps (.js.map) reconstructing TypeScript/ES6 source, Swagger/OpenAPI JSON endpoint discovery, .env/.git exposure, webpack chunks with hardcoded secrets, robots.txt/security.txt recon, build-info files, asset-manifest.json API route discovery, .DS_Store file listing. Use at the START of every recon session — these findings often unlock the entire attack surface.

When to use

• You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
• You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.

When not to use

• Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
• Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
• Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.

Skill page

Conflict

Both copies describe the same hunt-source-leak procedure (quick-win path probes, source map discovery, Swagger/OpenAPI discovery, secret grep), but each contains material steps the other lacks. The uphiago copy adds a Pitfalls section (fake source maps served as HTML, BusyBox/Alpine grep -P fallback, crt.sh rate limiting) and a reference to a React extraction pipeline. The sickn33 copy adds a mandatory authorization confirmation gate and a critical operational rule to re-derive content-hashed bundle names live because a 404 on an old .map URL does not mean remediation. Crowning one copy would hide either the environment pitfalls or the authorization/build-rotation constraints.