Home/Blog/Claude Code Prompts for Security: 12 Review Prompts to Copy
Blog

Claude Code Prompts for Security: 12 Review Prompts to Copy

P
promptstudio

12 Claude Code prompts for security: threat models before you code, branch reviews for IDOR and injection, secrets and dependency checks, and fixes with tests.

Claude Code Prompts for Security: 12 Review Prompts to Copy

Claude Code prompts for security turn a coding agent into a careful reviewer: they ask Claude Code to map what a change exposes, write a short threat model, and report findings with a file, a line, an exploit scenario, and a fix, before anything is edited. Run them from the root of your repo on the branch you want reviewed. Below are 12 copy-paste prompts grouped by stage, plus a flagship prompt that runs a full threat model and findings review in one pass. Use them only on code you own or are authorized to review, and test fixes locally, never against systems you do not control.

Claude Code already ships a built-in /security-review command that runs an on-demand security pass over the changes on your current branch, and Anthropic publishes a GitHub Action, anthropics/claude-code-security-review, for pull requests. The prompts below add context those tools cannot guess: your sensitive data, your known risks, and the tests you want. None of this replaces a penetration test or your existing scanners, and you should never paste real secrets or customer data into a prompt.

Prompts before you write code

1. Threat model for a new feature

We are about to build [feature]. Stack: [stack and auth]. Sensitive data: [data]. Before writing code, read [relevant folders] and write a threat model table: asset, entry point, threat, control we need, and how we will test it. Do not edit files.

2. Security rules for CLAUDE.md

Read our codebase and propose a short Security section for CLAUDE.md: how we check auth on routes, how we build SQL, where secrets live, and what Claude must never do (for example print .env values). Base every rule on code you find and cite the file.

3. Secure design check on a plan

Here is my implementation plan: [plan]. List every place it accepts user input, crosses a trust boundary, or stores [sensitive data], and add the control each step needs. Keep it to the plan; no code yet.

Prompts for reviewing a branch

4. Authorization and IDOR check

Review the diff against origin's default branch for [routes]. For each route, show where it gets the user and the record owner, and flag any place where an ID from the request is trusted without checking it against the session. Report file:line and an exploit scenario.

5. Injection check

Find every place in the diff where request data reaches SQL, a shell command, a template, a file path, or a redirect. For each, say whether it is parameterized, allowlisted, or escaped, and quote the line if it is not.

6. Secrets and config scan

Search the diff and [config folders] for hardcoded keys, tokens, passwords, and URLs with credentials. Report the file and variable name only; never print the value. Suggest where each should live instead: [our secrets approach].

7. Dependency change review

Compare the lockfile changes on this branch with origin's default branch. List each new or upgraded package, why the diff needs it, install scripts it runs, and any package that looks unused. Do not install or run anything.

8. Triage /security-review results

Here is the output of /security-review: [output]. For each finding, confirm it in the code with file:line, rate how likely it is to be exploitable in our setup ([deployment notes]), and sort the list into fix now, fix later, and false positive with a reason.

Prompts for fixing

9. Fix plan for approval

For these findings, [findings], write the smallest fix for each as a plan: files, functions, and the change in one or two sentences. Wait for my approval before editing anything.

10. Regression test per finding

For [finding], write one test that fails on the current code and passes after the fix, using our test setup in [test folder]. Run only that test and show me the result.

Prompts for your process

11. A custom security slash command

Turn our review checklist into a Markdown file for .claude/commands/ named [name].md: what to read, which categories to check ([categories]), the output table format, and the rule to report only high-confidence findings with file:line.

12. Pull request security summary

Write a short security section for this pull request: what the change exposes, what was checked, findings fixed with links to the tests, and anything left for a human reviewer. Use only what is in the diff and our review notes: [notes].

Run the full review with the flagship prompt

The Claude Code Security Review Prompt: Threat Model to Findings combines prompts 1, 4, 5, 9, and 10. You give it a change summary, stack and auth, sensitive data, entry points, known risks, and scope. In its example, a new CSV invoice export in an Express and PostgreSQL app returns three findings: an IDOR on the accountId query parameter, SQL injection through an interpolated ORDER BY column, and CSV formula injection, each with a fix plan and a failing test to add.

More Claude Code and security prompts

For correctness reviews, see Claude Code Prompts for Code Review and the Claude Code branch diff review before a PR. To lock down your CI, use the GitHub Actions security hardening reviewer. To package your checklist as a reusable command, read how to write a Claude Code slash command.

Find more in the Coding category, look through Browse, or post your own on Share.