A. Security & Data Safety · Prompt 12

Try to Break Your App: Attacker's-Eye Review

Why it matters

Many bugs are not obvious when you read code top to bottom. They show up when you follow an attack path or a clumsy user path.

Modeled on

Adversarial reviews that follow attack paths and broken flows, not only style.

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.

Try to Break Your App: Attacker's-Eye Review: what to check
Think like an attacker and like a clumsy user. Review only this repo, or a staging app I own and have told you to test. Do not probe a system you cannot see permission for. Do not exploit a live production host.
1. ID tampering: for handlers that take a user, order, or document id, say whether the code checks ownership. Cite the check or its absence.
2. Auth bypass: which handlers have no auth check, how expired or malformed tokens are rejected, and whether a seeded admin account is still created.
3. Privilege: if roles exist, say whether a normal user can hit an admin path by URL or by editing their role in the client. The check must be on the server.
4. Abuse: signup, messaging, uploads, and promo or referral code reuse. Point at the missing limit or the missing redemption record.
5. Injection: where script or SQL metacharacters would be stored or concatenated. Cite the line. Do not fire those payloads at production.
6. Accidental exposure: an admin page with no auth, an error page that prints env values, a public .env or .git path, or API docs left open.
7. Money or credits: can the client send a negative amount, stack a discount without a cap, or restart a trial by signing up again? Cite the handler.
8. Chaining: name two lower-severity issues that together become serious, if you see a pair. If you do not, say so.
9. Broken flows in the UI code: double submit, refresh during payment, two tabs, session expiry mid-action, and a save that fails offline. Say what the code does, not what you hope it does.
10. Order findings with data theft and account takeover first, then abuse and logic bugs. For each: what the person does, the realistic damage, and the fix. Then stop.

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

11. Pre-Deploy Production Readiness Check

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. Try to Break Your App: Attacker's-Eye Review: what to check Think like an attacker and like a clumsy user. Review only this repo, or a staging app I own and have told you to test. Do not probe a system you cannot see permission for. Do not exploit a live production host. 1. ID tampering: for handlers that take a user, order, or document id, say whether the code checks ownership. Cite the check or its absence. 2. Auth bypass: which handlers have no auth check, how expired or malformed tokens are rejected, and whether a seeded admin account is still created. 3. Privilege: if roles exist, say whether a normal user can hit an admin path by URL or by editing their role in the client. The check must be on the server. 4. Abuse: signup, messaging, uploads, and promo or referral code reuse. Point at the missing limit or the missing redemption record. 5. Injection: where script or SQL metacharacters would be stored or concatenated. Cite the line. Do not fire those payloads at production. 6. Accidental exposure: an admin page with no auth, an error page that prints env values, a public .env or .git path, or API docs left open. 7. Money or credits: can the client send a negative amount, stack a discount without a cap, or restart a trial by signing up again? Cite the handler. 8. Chaining: name two lower-severity issues that together become serious, if you see a pair. If you do not, say so. 9. Broken flows in the UI code: double submit, refresh during payment, two tabs, session expiry mid-action, and a save that fails offline. Say what the code does, not what you hope it does. 10. Order findings with data theft and account takeover first, then abuse and logic bugs. For each: what the person does, the realistic damage, and the fix. Then stop. 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 P12, for example P12-1, P12-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.