A. Security & Data Safety · Prompt 1

Secrets & Credential Leak Sweep

Why it matters

A private key left in a repo or a shipped app can be copied and abused. Public client keys are a different thing and should not be treated as leaks.

Modeled on

Secret scanners such as Gitleaks and TruffleHog.

How to run this prompt

Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.
Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.
Read the report. Keep the IDs you agree with.
Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.
Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.

Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.
Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.
Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands
that change anything: no installs, migrations, git commits, deploys, or "--fix" flags.
If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt.

Before you start:
- Tell me the stack you detect (framework, language, database, auth, hosting,
  payment provider) and which folders you will review.
- If a check below does not apply to this stack, write "Not applicable" and why.
- If you can run read-only commands, run the ones listed. If you cannot, list them
  so I can run them and paste the output.

Secrets & Credential Leak Sweep: what to check
Look for secrets that can actually be abused. Do not flag values that are public by design: a Firebase web apiKey, a Supabase anon key, or a Stripe publishable key (pk_live_ or pk_test_). Those are meant to ship in client code. The dangerous values are private keys, service-account JSON, a Supabase service_role key, Stripe secret or restricted keys (sk_ or rk_), database passwords, and webhook secrets.
1. Search the whole repo, including config, comments, seed scripts, fixtures, CI files, and exported Postman or Insomnia collections, for hardcoded tokens, passwords, private keys, webhook URLs that embed a secret, and database connection strings.
2. For each hit, name the service, say whether it looks live or like a placeholder (your-api-key, changeme, example), and name the environment variable it should move to. Do not print the full secret. Show at most the first 4 characters.
3. In Next.js, Vite, and Create React App, flag a real secret stored in a client-exposed variable (NEXT_PUBLIC_, VITE_, REACT_APP_). A public Firebase web config in NEXT_PUBLIC_ is fine. A service_role key or an sk_ key there is Critical.
4. On Android, check Kotlin or Java source, git-tracked gradle.properties, and release BuildConfig fields. On iOS, check Info.plist and a committed GoogleService-Info.plist for anything beyond the public client config.
5. Confirm .env, .env.local, *.jks, *.keystore, service-account JSON, and a real google-services.json or GoogleService-Info.plist are gitignored. Then check whether any are already tracked with git ls-files.
6. If a secret was committed and later deleted, say so. Deleting the line does not remove it from history. The credential must be rotated. Name the commit if git log -p -S shows it.
7. Check CI workflow files for secrets printed in a run step, or secrets baked into a client build artifact.
8. Check that .env.example lists every required name with a placeholder, and that the example file itself has no live value.

Evidence rules:
- Every finding cites a file path and line number, or the exact command output used.
- Mark each finding Confirmed (seen in the code) or Needs manual check (depends on
  something outside the repo, such as a dashboard setting or production data).
- Never print a full secret. Show the first 4 characters and the location only.
- If you are not sure, say so. Do not invent files, settings, or results.

Severity: Critical = exploitable now, or leaks real data or money. High = serious
with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene.

Report:
- Summary: count of findings by severity.
- Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort
  (IDs for this prompt use the prefix P01, for example P01-1, P01-2.)
- Checked and fine: what you verified is already OK.
- Could not check: what I need to look at myself, and where.

Then stop. Do not fix anything. Ask me which IDs I want fixed.

Get the free PDF

Related prompts

2. Test Data & Seed Cleanup

Share this prompt

WhatsApp LinkedIn X

How to run this prompt

Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.

Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.

Read the report. Keep the IDs you agree with.

Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.

Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.

Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.

Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.

Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands that change anything: no installs, migrations, git commits, deploys, or "--fix" flags. If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt. Before you start: - Tell me the stack you detect (framework, language, database, auth, hosting, payment provider) and which folders you will review. - If a check below does not apply to this stack, write "Not applicable" and why. - If you can run read-only commands, run the ones listed. If you cannot, list them so I can run them and paste the output. Secrets & Credential Leak Sweep: what to check Look for secrets that can actually be abused. Do not flag values that are public by design: a Firebase web apiKey, a Supabase anon key, or a Stripe publishable key (pk_live_ or pk_test_). Those are meant to ship in client code. The dangerous values are private keys, service-account JSON, a Supabase service_role key, Stripe secret or restricted keys (sk_ or rk_), database passwords, and webhook secrets. 1. Search the whole repo, including config, comments, seed scripts, fixtures, CI files, and exported Postman or Insomnia collections, for hardcoded tokens, passwords, private keys, webhook URLs that embed a secret, and database connection strings. 2. For each hit, name the service, say whether it looks live or like a placeholder (your-api-key, changeme, example), and name the environment variable it should move to. Do not print the full secret. Show at most the first 4 characters. 3. In Next.js, Vite, and Create React App, flag a real secret stored in a client-exposed variable (NEXT_PUBLIC_, VITE_, REACT_APP_). A public Firebase web config in NEXT_PUBLIC_ is fine. A service_role key or an sk_ key there is Critical. 4. On Android, check Kotlin or Java source, git-tracked gradle.properties, and release BuildConfig fields. On iOS, check Info.plist and a committed GoogleService-Info.plist for anything beyond the public client config. 5. Confirm .env, .env.local, *.jks, *.keystore, service-account JSON, and a real google-services.json or GoogleService-Info.plist are gitignored. Then check whether any are already tracked with git ls-files. 6. If a secret was committed and later deleted, say so. Deleting the line does not remove it from history. The credential must be rotated. Name the commit if git log -p -S shows it. 7. Check CI workflow files for secrets printed in a run step, or secrets baked into a client build artifact. 8. Check that .env.example lists every required name with a placeholder, and that the example file itself has no live value. Evidence rules: - Every finding cites a file path and line number, or the exact command output used. - Mark each finding Confirmed (seen in the code) or Needs manual check (depends on something outside the repo, such as a dashboard setting or production data). - Never print a full secret. Show the first 4 characters and the location only. - If you are not sure, say so. Do not invent files, settings, or results. Severity: Critical = exploitable now, or leaks real data or money. High = serious with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene. Report: - Summary: count of findings by severity. - Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort (IDs for this prompt use the prefix P01, for example P01-1, P01-2.) - Checked and fine: what you verified is already OK. - Could not check: what I need to look at myself, and where. Then stop. Do not fix anything. Ask me which IDs I want fixed.