Finding Secrets in Code Cheat Sheet

Hunt hardcoded credentials in source code and git history: detection regexes, gitleaks/trufflehog/noseyparker commands, Shannon entropy, cloud-key signatures, and the files where secrets actually leak. (47 payloads)

Try it interactively with the Secret Scanner

Cloud & Service Key Signatures

(8)

AKIA[0-9A-Z]{16}

AWS Access Key ID. Long-lived IAM key prefix; ASIA = temporary STS key, AGPA = group, AIDA = user. Pair with the 40-char secret (see below) and validate via 'aws sts get-caller-identity'.AWS — high signal, almost never a false positive

(?i)aws_secret_access_key\s*[=:]\s*["']?([A-Za-z0-9/+=]{40})

AWS Secret Access Key — 40 base64-ish chars. Has no fixed prefix, so anchor on the assignment keyword or proximity to an AKIA ID to avoid drowning in entropy noise.AWS — confirm by pairing with the AKIA ID

ghp_[0-9A-Za-z]{36}

GitHub personal access token (classic). Other prefixes: gho_ (OAuth), ghu_ (user-to-server), ghs_ (server-to-server), ghr_ (refresh), github_pat_ (fine-grained). Test with 'curl -H "Authorization: token <t>" https://api.github.com/user'.GitHub — prefixes added in 2021, easy to grep

(sk|rk)_(live|test)_[0-9a-zA-Z]{24,99}

Stripe secret/restricted API key. sk_live_ is production money-moving; rk_ is restricted scope. Publishable pk_ keys are non-secret. Validate read-only with GET https://api.stripe.com/v1/account.Stripe — sk_live_ is critical severity

AIza[0-9A-Za-z\-_]{35}

Google API key (Maps, Firebase, GCP services). Often client-side and intentionally public — verify scope/restrictions before reporting. GCP service-account JSON ('"type": "service_account"') is the far more dangerous find.Google/GCP — check key restrictions before triaging

xox[baprs]-[0-9A-Za-z-]{10,72}

Slack token. xoxb (bot), xoxp (user), xoxa/xoxr (app/refresh). Slack webhooks are https://hooks.slack.com/services/T.../B.../... — grep those separately. Verify via auth.test API.Slack — bot tokens grant broad workspace access

eyJ[A-Za-z0-9_-]{10,}\.eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}

JWT (three base64url segments split by dots). Decode the middle segment for exp/scope/role; an unexpired service JWT or one with a leaked HS256 signing key is directly exploitable.JWT — decode header+payload to assess impact

-----BEGIN (RSA |EC |OPENSSH |DSA |PGP )?PRIVATE KEY-----

Private key material (SSH, TLS, PGP). One of the highest-impact leaks — a committed id_rsa or server.key is instant access. Strip passphrase status with 'ssh-keygen -y -f key' (errors if encrypted).Crypto material — always critical, never client-safe

Generic & High-Entropy Regexes

(7)

(?i)(api[_-]?key|secret|token|passwd|password|pwd|auth)\s*[=:]\s*["']([^"'\s]{8,})["']

Keyword-anchored assignment. The bread-and-butter generic rule — catches 'apiKey = "..."', 'secret: "..."', etc. Noisy on its own; combine with entropy or a stoplist of placeholder words.Anchor on the variable name to cut false positives

(?i)(?:bearer)\s+[a-z0-9._\-]{20,}

Hardcoded Bearer token in an Authorization header literal, common in test fixtures, README curl examples, and HAR/Postman exports committed by mistake.Check fixtures, docs, and exported HTTP captures

Database/connection URI with inline credentials (user:pass@host). DSNs in .env, docker-compose, or settings files routinely leak production DB passwords.Connection strings = credentials + host in one line

(?i)-p\s*['\"]?[^\s'\"]{6,}|--password[= ]['\"]?[^\s'\"]{6,}

Plaintext password passed on a command line inside shell scripts, Dockerfiles, or CI YAML (mysql -p, curl --password). Often missed because it isn't a quoted assignment.Scan build scripts and Dockerfiles, not just app code

[A-Za-z0-9+/]{40,}={0,2}

Long base64 blob — candidate for a key/cert encoded into a config or env value. Always decode and inspect; many are legitimate (images, hashes), so gate this rule behind entropy or context.Decode before reporting — most are not secrets

(?i)(slack|discord|telegram)\.com/(api/webhooks|services)/[A-Za-z0-9_/-]+

Inbound webhook URLs that act as bearer secrets — anyone holding the URL can post messages. Frequently hardcoded in alerting/notification scripts.Webhook URLs are credentials, treat as secrets

Vendor-prefixed key names. Provider-specific rules (SendGrid SG.xxx, Twilio SK/AC, npm npm_, DigitalOcean dop_v1_) outperform generic entropy — build a per-vendor ruleset.Per-provider prefixes beat generic detection

Shannon Entropy

(6)

H = -Σ p(x) · log2 p(x) (bits/char)

Shannon entropy measures per-character randomness. Real secrets (random tokens) sit high; English words and code identifiers sit low. The core idea behind trufflehog's original entropy mode and gitleaks' optional entropy gating.Higher entropy ≈ more random ≈ more likely a key

base64 threshold ≈ 4.5 bits/char · hex ≈ 3.0 bits/char

TruffleHog's classic defaults: flag base64-charset strings above ~4.5 and hex strings above ~3.0. Lower thresholds catch more but flood you with noise; tune per codebase.Different charsets need different thresholds

python3 -c "import math,sys;s=sys.argv[1];print(round(-sum((s.count(c)/len(s))*math.log2(s.count(c)/len(s)) for c in set(s)),2))" "AKIAIOSFODNN7EXAMPLE"

One-liner to compute Shannon entropy of any string from the shell. Useful for sanity-checking whether a candidate hit is random enough to be a real key.Quick manual entropy check on a suspect string

trufflehog filesystem . --no-verification --results=verified,unknown

Modern TruffleHog (v3) leads with verified detectors over raw entropy, but still surfaces 'unknown' high-entropy hits. Entropy is now the fallback, not the primary signal — fewer false positives than the v2 entropy era.v3 prefers verified detectors; entropy is secondary

Why entropy alone fails: minified JS, UUIDs, hashes, git SHAs, and base64 assets all score high.

Pure entropy produces enormous false-positive volume. Production scanners combine entropy with regex anchors, charset checks, length bounds, and allowlists for known-noisy paths.Entropy is a filter, not a verdict

Combine entropy + keyword proximity: a high-entropy value within ~20 chars of 'key/token/secret' is a strong hit.

The most reliable cheap heuristic: require BOTH a suspicious assignment keyword AND a high-entropy right-hand side. Cuts noise dramatically versus either signal alone.AND the two signals together for precision

gitleaks

(6)

gitleaks detect --source . --redact -v

Scan the full git history of the current repo with the built-in ruleset. --redact hides the secret value in output; -v prints findings as it goes. This is the default 'is anything committed?' command.Scans all commits, not just the working tree

gitleaks detect --source . --log-opts="--all --since=2024-01-01"

Pass through git log options to scope the scan — e.g. all branches/tags (--all) since a date. Essential for large repos where a full-history scan is slow.--log-opts forwards any git log filter

gitleaks dir . --report-format json --report-path leaks.json

Scan files on disk (working tree, no git required) and emit a JSON report. Use 'dir' (formerly 'detect --no-git') for vendored code, build artifacts, or extracted archives.No-git mode for filesystem / non-repo scanning

gitleaks git --log-opts="-p" --baseline-path baseline.json

Use a baseline of previously-triaged findings so only NEW secrets are reported. Generate the baseline once, commit it, and fail CI only on net-new leaks.Baseline suppresses known/accepted findings

gitleaks protect --staged -v

Pre-commit guard: scan only staged changes and block the commit if a secret is found. Wire into a Husky/pre-commit hook so secrets never reach history in the first place.Run as a pre-commit hook to prevent leaks

# .gitleaks.toml → [[rules]] id, regex, keywords + [allowlist] paths/regexes

Custom config: add org-specific detectors and allowlist known test fixtures / example keys. Extend the default rules with 'useDefault = true' rather than replacing them.Tune rules and allowlist false positives in TOML

trufflehog & noseyparker

(6)

trufflehog git https://github.com/org/repo --only-verified

Clone and scan a remote repo's full history, then live-validate each candidate against its provider API. --only-verified means every result is a confirmed-active credential — near-zero false positives.Verification = the key actually works right now

trufflehog github --org=acme --only-verified --include-members

Scan every repo in a GitHub org (and optionally org members' personal repos) with a token. The fastest way to sweep an entire organisation for live secrets.Org-wide sweep — needs a GITHUB_TOKEN env var

trufflehog filesystem /path/to/code --json | jq '.SourceMetadata'

Scan a local directory and pipe NDJSON into jq. Each line carries the detector name, raw/redacted secret, verification status, and file:line — easy to post-process into a report.NDJSON output integrates cleanly with jq/CI

trufflehog docker --image=org/app:latest --only-verified

Pull a container image and scan its layers for baked-in secrets — a hugely common leak vector (build-time ARGs, copied .env files, cached creds in intermediate layers).Container images leak more than you'd expect

noseyparker scan --git-history full ./repo && noseyparker report

Noseyparker (Praetorian) is built for speed on massive codebases/history — it deduplicates matches across commits and reports unique secrets, ideal for red-team sweeps of huge repos.Fastest option for very large repos / bulk history

noseyparker scan --enumerator git-history=full --rules-path custom.yaml ./targets

Bulk-scan a directory of cloned targets with custom YAML rules and full history enumeration. Pairs well with a 'git clone' loop over an org's repo list for offline analysis.Custom rules + bulk directory scanning

Mining Git History

(6)

git log -p -S 'AKIA' --all

Pickaxe search across ALL branches/history for commits that added or removed a string. -S finds the literal; -G takes a regex. The fastest manual way to find when/where a key entered the repo.git pickaxe — searches added/removed lines

git log --all --full-history -- '*.env' '*.pem' '*id_rsa*'

List every commit that ever touched secret-prone files — even ones later deleted. A file removed in HEAD still lives in history and is recoverable.Deleted ≠ gone — history retains the blob

git show <commit>:path/to/.env

Dump the exact contents of a file at a specific historical commit. After the pickaxe/log step pins the commit, this extracts the leaked value verbatim.Read a secret straight out of an old commit

git rev-list --all | xargs -I{} git grep -I -i -e 'password' -e 'secret' {} 2>/dev/null

Brute-force grep every blob across all commits. Slow but thorough when you don't know which file holds the secret. Cap with --max-count or restrict to a path for speed.Exhaustive history grep when scanners miss it

git fsck --lost-found && git cat-file -p <sha>

Recover secrets from dangling/unreferenced objects — commits orphaned by rebase, amend, or force-push still exist until garbage-collected. Inspect found blobs with cat-file.Unreachable objects survive history rewrites

Remediation: rotate the secret FIRST, then rewrite history (git-filter-repo / BFG).

Removing a secret from git history does NOT invalidate it — anyone who cloned still has it, and forks/caches persist. Always rotate the credential immediately; history rewriting is secondary cleanup.Rotate the key — a deleted commit doesn't revoke it

Where Secrets Actually Leak

(8)

.env .env.local .env.production .envrc

The #1 leak location. Frequently committed despite .gitignore (added too late, or a force-add). Also check for .env.example accidentally filled with real values.Check history even if it's gitignored now

Frontend bundles: main.*.js, chunk-*.js, source maps (.map)

Secrets compiled into client-side JS are shipped to every visitor. Source maps (.js.map) reconstruct original code with comments. Grep built assets and any deployed *.map files.Client bundles are public — scan them post-build

CI/CD: .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, circle config

Pipelines echo secrets into logs, hardcode them as fallbacks, or expose them in pull_request_target workflows. Build logs themselves often contain printed env vars.Scan pipeline files AND their build logs

Containers: Dockerfile (ARG/ENV), docker-compose.yml, image layers

Build-time ARGs persist in image history; ENV and COPY .env bake creds into layers. 'docker history --no-trunc' and layer inspection reveal them even when the final stage looks clean.Multi-stage builds don't always strip earlier layers

Configs & infra: settings.py, application.properties, *.tfstate, *.tfvars, k8s manifests

Terraform state (.tfstate) stores provisioned secrets in plaintext. Kubernetes Secret manifests are only base64 — not encrypted — so a committed manifest is a committed credential.tfstate and k8s Secrets = plaintext/base64, not encrypted

Mobile: APK/IPA — strings, res/values/strings.xml, BuildConfig, decompiled smali

Decompile (apktool/jadx) and grep resources and BuildConfig — API keys are routinely embedded in mobile binaries and recoverable by anyone who downloads the app.Mobile apps ship secrets to the device

Logs, notebooks & exports: *.log, *.ipynb outputs, *.har, Postman/Insomnia collections

Jupyter notebook cell outputs cache tokens; HAR files and API-client exports capture full Authorization headers. These get committed to repos and shared far more than people realise.Captured HTTP traffic carries live auth headers

GitHub side-channels: gists, issues/PR comments, wiki, Actions logs, commit messages

Secrets hide outside the main tree — pasted in an issue, a gist, a wiki page, or a verbose commit message. Org-wide scanners (trufflehog github) and code-search dorks cover these.The whole org surface leaks, not just the default branch

ShareX LinkedIn Reddit

Level up your security testing

Install the CLI

npx payload-playground

Explore All Tools

Encoding, hashing, JWT & more

Browse Cheat Sheets

Quick-reference payload guides

Related Cheat Sheets

API Security Cheat Sheet Google Dorking Cheat Sheet OSINT & Reconnaissance Cheat Sheet

Frequently asked questions

What is the Finding Secrets in Code Cheat Sheet?+

It's a quick-reference collection of 47 Secrets in Code payloads for testing Finding Secrets in Code vulnerabilities during authorized penetration testing, bug bounties, and CTFs. Every payload is copy-ready and grouped by attack context.

How do I use these Secrets in Code payloads?+

Copy any payload straight into your authorized test, or use the Secret Scanner to apply them interactively. Only test systems you have explicit permission to assess.

Are these Secrets in Code payloads free to use?+

Yes — this cheat sheet and all Secrets in Code payloads are completely free, with no account required. Everything runs in your browser.

$loading...

Frequently asked questions

What is the Finding Secrets in Code Cheat Sheet?+

How do I use these Secrets in Code payloads?+

Copy any payload straight into your authorized test, or use the Secret Scanner to apply them interactively. Only test systems you have explicit permission to assess.

Are these Secrets in Code payloads free to use?+

Yes — this cheat sheet and all Secrets in Code payloads are completely free, with no account required. Everything runs in your browser.

Finding Secrets in Code Cheat Sheet

Cloud & Service Key Signatures

Generic & High-Entropy Regexes

Shannon Entropy

gitleaks

trufflehog & noseyparker

Mining Git History

Where Secrets Actually Leak

Related Tools

Related Cheat Sheets

Frequently asked questions

Finding Secrets in Code Cheat Sheet

Cloud & Service Key Signatures

Generic & High-Entropy Regexes

Shannon Entropy

gitleaks

trufflehog & noseyparker

Mining Git History

Where Secrets Actually Leak

Related Tools

Related Cheat Sheets

Frequently asked questions