A. Security & Data Safety · Prompt 10

Why it matters

A stack trace or a logged token shown to the wrong person reveals paths, queries, and sometimes keys.

Modeled on

OWASP logging and error-handling guidance.

How to run this prompt

1. Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.
2. Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.
3. Read the report. Keep the IDs you agree with.
4. Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.
5. 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.

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.

Debug Logs & Error Leakage Cleanup: what to check
Find what this app leaks through logs and error responses. Do not print secret values. Cite the file.
1. List console.log, print, and debug calls that would still run in production. Note which ones log objects rather than a short message.
2. Flag any log line that can include a password, token, API key, full payment or personal data, or an entire request or response body.
3. Check error responses sent to the client for stack traces, raw database errors, file paths, framework versions, or internal ids. A generic message plus a correlation id is the safe shape.
4. Confirm the detailed stack is logged only on the server and tied to that correlation id. If there is no correlation id, say so.
5. Find debug switches that default to on: debug=true, verbose error pages, source maps served to browsers, GraphQL introspection, and an open Swagger or playground route.
6. Check client error boundaries. They should show a friendly message, not the raw error object.
7. Say where logs are stored and who can read them, if the code or config shows it. Retention is Needs manual check if it is only a host setting.
8. Separate findings into "shown to users" and "only in server logs". Both matter. Server logs that contain secrets are still a leak.

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 P10, for example P10-1, P10-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.

Related prompts

• 9. Payments & Webhooks Deep Check
• 11. Pre-Deploy Production Readiness Check

Share this prompt