Finding Secrets in JavaScript and Source Maps for Bug Bounty
Frontend code is public by design. That does not mean every credential inside it is harmless. The job is to distinguish an identifier intended for browsers—such as a publishable payment key—from a credential that grants authority the browser should never possess.
Collect bundles from an in-scope page with normal browser requests. Preserve the URL, hash, and timestamp. Pretty-printing helps navigation, but keep the original file because minifiers can change names and scanners can report misleading line numbers.
Find the map behind the bundle
Look at the final lines for sourceMappingURL. Test the declared path, the common .map suffix, and build-manifest references. A source map may contain sourcesContent, which reconstructs original TypeScript, comments, filenames, and environment modules. If content is absent, the source paths still reveal architecture.
Do not crawl storage buckets outside scope just because a map names one.
Search bundles and recovered source for credential-shaped strings and context words:
apiKey,secret,token,authorization, andprivateKey- Cloud access-key formats and signed URL parameters
- GraphQL endpoints, internal hosts, and old API versions
- Sentry DSNs, analytics IDs, payment keys, and map-service tokens
- Comments mentioning staging accounts or temporary bypasses
Regex is triage. Context decides impact.
Classify before you test
A Sentry DSN often allows event submission but is not an account password. Firebase configuration identifies a project; security depends on database and storage rules. Stripe publishable keys are built for untrusted clients. Google Maps keys may be safe only when HTTP referrer and API restrictions are correct.
Ask three questions: What service accepts this value? Which action does it authorize? Is that action supposed to be available to any site visitor?
Test with the smallest read-only call permitted by policy. For a suspected backend API token, request a harmless /me, metadata, or permission endpoint. For a cloud key, do not enumerate an account blindly; use the provider's identity call if the program allows it. Never incur charges, send messages, or dump customer data.
Source maps expose more than keys
Original code can reveal hidden admin routes, feature flags, role names, object identifiers, and client-side checks. A route name alone is usually informational. Pair it with a boundary failure: a normal user reaches an owner mutation, an undocumented export leaks another test account, or a disabled feature remains active server-side.
I've seen maps expose comments more useful than any token: “temporary skipAuth for migration” points directly to the assumption worth testing. Treat comments as leads, not proof that deployed code follows them.
Build a defensible report
Include the public asset URL, exact source-map path, file hash, redacted secret, and a minimal capability test. Explain whether authentication was required to download the asset and whether the credential works from an unrelated network or origin. If restrictions stop abuse, say so.
Recommend keeping privileged credentials server-side, rotating confirmed secrets, restricting browser keys by API and origin, removing sourcesContent from production maps, and protecting map delivery when maps are needed for error monitoring. Deleting the map alone does not revoke a leaked key; old bundles and caches may persist.
The OWASP testing guide frames sensitive-data exposure broadly. For hunters, restraint wins: prove one unauthorized capability, redact the value, and give the team enough evidence to rotate it fast.