How to Find Exposed API Keys and Secrets in Bug Bounty

Secrets leak everywhere: frontend JavaScript, source maps, git history, mobile app packages, and public repos. A live key can grant access to email providers, cloud services, payment tools, or internal APIs. Finding and safely validating leaked secrets is one of the highest-ROI recon skills.

The rule that keeps you safe: prove a key is valid with the lightest possible read, then stop.

Where secrets hide

JavaScript bundles: hardcoded tokens, third-party keys, internal endpoints
Source maps: .map files that reveal original, commented source
Git history: secrets removed in a later commit but still in history
Mobile apps: keys embedded in APK/IPA resources and strings
Public repos and gists: developer leaks tied to the target
Response bodies and error messages: debug output exposing config

Tie every finding to the in-scope target before acting on it.

Not every key is a vulnerability

Many keys are meant to be public (for example client-side analytics or map keys restricted by referrer). Impact depends on:

What the key can do (read/write, admin, billing)
Whether it is scoped/restricted (referrer, IP, permissions)
Whether it reaches sensitive data or actions

A restricted, public-by-design key is usually informative at best. A live server-side secret is often critical.

Validate safely

Identify the service the key belongs to (prefix, format, surrounding code).
Make the least intrusive authenticated call the API offers — typically a “who am I” or read-only status endpoint.
Confirm it authenticates, capture the minimal proof (for example an account identifier), and stop.

Never send emails, charge cards, modify data, or enumerate other customers. One benign, read-only call is enough for triage.

Impact ladder

Public, restricted client key → usually informative
Read-only secret exposing private data → medium/high
Write or admin secret → high/critical
Cloud or provider master credentials → critical

Report structure

Include where the secret was found (file, commit, bundle), the service it belongs to, the safe validation you performed, and the access it grants. Recommend immediate rotation, moving secrets to server-side config/secret managers, restricting key scopes, and purging git history.

Defensive checklist

Keep secrets out of frontend code and mobile bundles.
Use scoped, least-privilege keys with referrer/IP restrictions.
Store secrets in a secret manager, injected server-side only.
Add pre-commit and CI secret scanning.
Rotate on any suspected exposure and audit git history.

Secret hunting rewards patience and restraint. Read the bundles and history, prove a key is live with one gentle call, and report it before anyone abuses it.

Original Bugflare guide informed by CWE-798 (use of hard-coded credentials) guidance.

How to Find Exposed API Keys and Secrets in Bug Bounty

The rule that keeps you safe: prove a key is valid with the lightest possible read, then stop.

Where secrets hide

JavaScript bundles: hardcoded tokens, third-party keys, internal endpoints

Source maps: .map files that reveal original, commented source

Git history: secrets removed in a later commit but still in history

Mobile apps: keys embedded in APK/IPA resources and strings

Public repos and gists: developer leaks tied to the target

Response bodies and error messages: debug output exposing config

Tie every finding to the in-scope target before acting on it.

Not every key is a vulnerability

Many keys are meant to be public (for example client-side analytics or map keys restricted by referrer). Impact depends on:

What the key can do (read/write, admin, billing)

Whether it is scoped/restricted (referrer, IP, permissions)

Whether it reaches sensitive data or actions

A restricted, public-by-design key is usually informative at best. A live server-side secret is often critical.

Validate safely

Identify the service the key belongs to (prefix, format, surrounding code).

Make the least intrusive authenticated call the API offers — typically a “who am I” or read-only status endpoint.

Confirm it authenticates, capture the minimal proof (for example an account identifier), and stop.

Never send emails, charge cards, modify data, or enumerate other customers. One benign, read-only call is enough for triage.

Defensive checklist

Keep secrets out of frontend code and mobile bundles.

Use scoped, least-privilege keys with referrer/IP restrictions.

Store secrets in a secret manager, injected server-side only.

Add pre-commit and CI secret scanning.

Rotate on any suspected exposure and audit git history.

Secret hunting rewards patience and restraint. Read the bundles and history, prove a key is live with one gentle call, and report it before anyone abuses it.

Original Bugflare guide informed by CWE-798 (use of hard-coded credentials) guidance.

How to Find Exposed API Keys and Secrets in Bug Bounty