Secrets Exposure

Hardcoded credentials, API keys, tokens, and other secrets in web applications represent one of the most common and impactful vulnerabilities. Secrets can be found in JavaScript source, HTML comments, exposed configuration files, git repositories, and API responses.

Frameworks: WSTG-CONF-04, WSTG-INFO-05 · ASVS 5.0 V13.3.1, V14.1.1 · CWE-798, CWE-312 · T1552.001

What Makes a Secret a Finding

A secret is a finding when three things line up: it is a credential rather than an identifier, it is reachable by the audience you are testing as, and it still works. Most of the work is the second and third. A key in a bundle every visitor downloads is reachable; the same string in a server-side log is not, unless the log is exposed. A key that has been rotated is evidence of exposure, not of access.

Where Secrets Actually Leak

Four artefacts account for most real leaks. Build output: framework-prefixed variables (NEXT_PUBLIC_, VITE_, PUBLIC_ in Astro) are inlined at build time by design, so anything named that way ships to the browser. Source maps: a .map with sourcesContent reconstructs the modules, comments and hard-coded fallbacks included. CI logs: a masked variable leaks through set -x, an env dump, or a tool that prints its configuration in an error. Git history: a key deleted in the next commit is still in the object store, and so is every fork.

Name the retrieval step, because each needs a different one: a bundle is a request, a map needs the sourceMappingURL, CI logs need pipeline access the client must grant, and history needs the repository or a dumpable .git.

Client-Side Secret Discovery

# Search JavaScript files for secrets:
curl -s https://target.com/js/app.js | grep -iE \
  'api[_-]?key|apikey|secret|token|password|passwd|auth|credential|private[_-]?key'

# Search all JS files:
curl -s https://target.com/sitemap.xml | grep -oP 'https?://[^<]+\.js' | while read url; do
  echo "--- $url ---"
  curl -s "$url" | grep -inE 'api[_-]?key|secret|token|password|aws|firebase'
done

# Check HTML source for comments with secrets:
curl -s https://target.com | grep -iE '<!--.*(?:password|secret|key|token|TODO|FIXME|HACK)'

# Check for hardcoded Firebase config:
curl -s https://target.com | grep -oE 'AIza[0-9A-Za-z_-]{35}'

# LinkFinder - extract hidden URLs and parameters from JS:
python3 linkfinder.py -i https://target.com/js/app.js -o cli

Source maps are another client-side artefact that can reveal original code; recognising and fetching them is covered on the Information Disclosure guide. → Source-code exposure (canonical guide)

Server-Side Secret Discovery

Server-side secrets most often leak through exposed environment and configuration files — .env, appsettings.json, application.properties, docker-compose.yml. The enumeration mechanics for reaching them (probing .env, backup files, debug panels, and framework endpoints such as Spring Actuator) are documented once on the Information Disclosure guide; this page keeps its focus on triaging what those files expose.

→ Debug endpoints & hidden files (canonical guide)

Git Repository Mining

An exposed .git/ directory lets you reconstruct the full source tree, and — more relevant here — secrets that were committed and later deleted still live in history. Detecting and dumping the repository (/.git/HEAD, git-dumper) is covered on the Information Disclosure guide; the secret-specific step is scanning the recovered history with trufflehog or gitleaks, then reading deleted files with git show <commit>:.env.

→ Source-code exposure (canonical guide)

Common Secret Patterns (Regex)

Triaging a Candidate Without Exfiltrating It

Identify the type from the prefix — AWS AKIA, GitHub ghp_ or github_pat_, Stripe sk_live_, Slack xoxb- — because the prefix tells you what a harmless verification looks like and whether it is a credential at all. Then confirm liveness with the least invasive call the provider offers: an identity endpoint or a token-info call, never a list or a write. Record the status and the account it belongs to, redact the value, and stop.

Some candidates are not secrets. A Firebase API key identifies a project and is constrained by security rules; a Stripe publishable key is designed to ship; a Supabase anon key is public and protected by row-level security. Report those as a configuration question — are the rules restrictive? — not as a credential leak.

# Record a fingerprint, never the value
key="$(cat candidate.txt)"
printf 'prefix=%s length=%s tail=%s\n' "${key:0:4}" "${#key}" "${key: -4}"
printf '%s' "$key" | sha256sum | cut -c1-12

# Least-invasive liveness check: identity only, no data access
curl -s -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer $key" https://api.github.com/user
# 200 = live, 401 = revoked. Do not enumerate repositories with it.

Testing Checklist

Evidence Collection

Remediation

False Positive Identification