These 15 security review prompts help ChatGPT, Claude, Claude Code and Codex find real security problems in your code and designs: threat models, OWASP-style code review, broken access control, injection, secrets, login and session flows, and risky dependencies. Each prompt asks for evidence, severity and a concrete fix, not a generic checklist.
For a quick security pass on a single diff, see the security prompt in the code review prompts. The prompts below go further: one feature, one flow or one risk at a time.
How to use these prompts
Copy a prompt into ChatGPT, Claude, Claude Code or Codex and fill the blanks in double braces. A blank with a colon has a default, so {{framework:Next.js}} means Next.js unless you change it.
Narrow scope finds more. "Review the whole app for security" produces a shallow list. "Check every route in this folder for a missing ownership check" produces findings you can act on. In an agent, name the folder or files and let it search; in chat, paste the code for one feature plus the middleware and helpers it relies on.
Ask for proof. Each prompt asks the model to show the path from attacker input to the problem. A finding without a path is often a false positive. Before you paste anything, remove real secrets and customer data, and never share a live key with any tool.
These prompts lean on OWASP material, the open community that publishes the Top 10, the cheat sheets and the ASVS. AI review is a first pass, not a sign-off: anything that handles money, health data or many users still deserves a human security review.
How do you threat model a feature?
1. Threat model with the four questions
The OWASP Threat Modeling Cheat Sheet builds on four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. Run this before the code exists.
Threat model this feature before we build it.
Feature: {{feature}}
Users and roles: {{roles:anonymous visitors, signed-in users, admins}}
Data it touches: {{data}}
Components: {{components:Next.js frontend, API, Postgres, S3, a payment provider}}
Answer the four threat modeling questions:
1. What are we working on: a short description and the data flows.
2. What can go wrong: go through STRIDE (spoofing, tampering, repudiation,
information disclosure, denial of service, elevation of privilege) for
each component.
3. What are we going to do about it: a mitigation per threat.
4. Did we do a good enough job: what you couldn't assess and what to check.
Rank threats by likelihood and impact. Keep it to threats that apply to
this design.
2. Map trust boundaries and data flows
Most serious bugs sit where data crosses from less trusted to more trusted. Draw those lines first.
Here is how {{system:our app}} works:
{{architecture_or_code_overview}}
Produce a data flow diagram in Mermaid syntax with external entities,
processes, data stores and data flows. Mark every trust boundary. Then list
each flow that crosses a boundary, what validation or authentication happens
at that crossing today, and what's missing.
3. Write abuse cases
Use cases describe what users should do. Abuse cases describe what an attacker or a greedy user will try.
Here is a feature spec: {{spec}}
Write 10 abuse cases for it. For each: who the actor is (outsider, normal
user, other tenant, insider), what they try, what they gain, and the control
that should stop it. Include business logic abuse, like replaying a
discount, skipping a step in a flow or racing two requests, not just
technical attacks. Mark the three we should write tests for first.
How do you review code against the OWASP Top 10?
4. Review a module against the OWASP Top 10:2025
The OWASP Top 10:2025 runs from A01 Broken Access Control to A10 Mishandling of Exceptional Conditions. Use it as a checklist for one module, not the whole app.
Review {{module:the billing module}} against the OWASP Top 10:2025
categories:
A01 Broken Access Control, A02 Security Misconfiguration, A03 Software
Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06
Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity
Failures, A09 Security Logging and Alerting Failures, A10 Mishandling of
Exceptional Conditions.
For each category: "no issue found", "not applicable" or findings. For each
finding give severity, file and line, the input that triggers it, and the
fix. Do not report issues the surrounding code already prevents.
{{code}}
5. Find broken access control
Broken Access Control is A01, the top category, in the 2025 list. Missing ownership checks (often called IDOR) are the classic case, and an agent can check every route in one pass.
List every route or handler in {{path:src/app/api}} that reads or changes
data. For each one, answer:
- Does it require a signed-in user?
- Does it check that the user owns or may access the specific record (by
ID from the URL or body), not just that they're signed in?
- Can a user change fields they shouldn't, like role, ownerId or price, by
adding them to the request body?
Output a table: route, method, auth check, ownership check, mass
assignment risk, verdict. Then show the fix for each failing route using
our existing helpers: {{helpers:requireUser() in src/lib/auth.ts}}.
6. Trace untrusted input to dangerous sinks
Injection happens when input reaches a query, a shell, a template or a file path unchanged.
Find every place in {{path:this repo}} where untrusted input (request
params, body, headers, cookies, uploaded files, webhook payloads, data from
third-party APIs) reaches one of these sinks:
- SQL or NoSQL queries built with string concatenation
- Shell commands or child processes
- HTML rendered without escaping, or dangerouslySetInnerHTML
- File paths, redirects and outgoing URLs (SSRF)
- Deserialization or eval
For each path show the source, every step in between, and the sink. Say
whether it is exploitable today and give the fix, such as a parameterized
query or an allowlist.
7. Review an API against the OWASP API Security Top 10
APIs have their own failure modes. The OWASP API Security Top 10 2023 starts with broken object level authorization and includes unrestricted resource consumption.
Review this API against the OWASP API Security Top 10 2023, from API1
Broken Object Level Authorization to API10 Unsafe Consumption of APIs.
{{openapi_spec_or_route_code}}
Pay extra attention to: object IDs a user can guess or swap, fields returned
that the client doesn't need, endpoints with no rate limit or page size
limit, admin functions reachable by normal users, and calls we make to
third-party APIs whose responses we trust blindly. List findings with
severity, endpoint and fix.
How do you find and handle secrets?
8. Hunt for secrets in the repo
Secrets hide in config files, test fixtures, CI files and old commits.
Search this repository for secrets: API keys, tokens, private keys,
passwords, connection strings and webhook signing secrets. Check source
files, config, .env files that are committed, CI workflows, Dockerfiles,
test fixtures and notebooks.
For each hit: file and line, what kind of secret it looks like, whether it
seems real or a placeholder, and whether it is exposed to the browser (for
example a {{public_prefix:NEXT_PUBLIC_}} variable). Then tell me which
commands to run to scan git history too, and how to add a pre-commit check
so this doesn't happen again.
9. Respond to a leaked secret
When a key has leaked, order matters. The OWASP Secrets Management Cheat Sheet puts revocation first.
A secret leaked: {{secret:a production Stripe secret key}} was {{how:pushed to a public GitHub repo 3 hours ago}}.
Write a step-by-step response plan:
1. Revoke and rotate: exactly what to do in {{provider:Stripe}} and where
the new value must be updated (env vars, CI, servers).
2. Remove it from code, logs and history, and the side effects of
rewriting history.
3. Investigate: which logs show whether it was used, and what to look for.
4. Prevent: the one or two changes that would have stopped this.
Keep it to what I can do in the next hour first, then the follow-ups.
How do you review login, sessions and password reset?
10. Review a login flow
The OWASP Authentication Cheat Sheet covers the details that login code most often gets wrong.
Review our login flow for security problems.
{{login_code}}
Check:
- Do error messages and response codes reveal whether an account exists?
- Does the code take the same time for unknown users and wrong passwords?
- Is there a limit on failed attempts per account, not just per IP, and
can a locked-out user still reset their password?
- How are passwords hashed, and are long passphrases and all characters
allowed?
- Is MFA available, and can it be skipped by calling a later step directly?
For each issue give the risk in one sentence and the fix.
11. Review session cookies and logout
Sessions fail quietly. This prompt checks the attributes and lifecycle the OWASP Session Management Cheat Sheet recommends.
Review how {{app:our app}} manages sessions.
{{session_code_and_cookie_config}}
Check: Secure, HttpOnly and SameSite on the session cookie; whether the
session ID changes after login and after a privilege change; idle and
absolute timeouts enforced on the server; whether logout destroys the
session on the server and not only in the browser; CSRF protection on
state-changing requests; and what happens to other sessions after a
password change. Give findings with fixes in {{framework:Next.js}}.
12. Review a password reset flow
Reset flows are a back door into every account. Review them as carefully as login.
Review our password reset flow end to end.
{{reset_code}}
Check: the response is the same whether or not the email exists; the
token is random, single use, short lived and stored hashed; the reset link
can't be pointed at another host through a Host header; using the token
signs out other sessions; the flow is rate limited; and the user gets an
email when their password changes. List each gap with the fix.
13. Review token and OAuth handling
For apps that accept JWTs or sign users in through an OAuth or OpenID Connect provider.
Review how {{app:our API}} handles tokens from {{provider:our identity provider}}.
{{token_code}}
Check that we: verify the signature with a pinned algorithm list and never
accept "none"; check issuer, audience and expiry; don't put secrets or
personal data in token payloads; use state and PKCE in the OAuth redirect
flow; validate redirect URIs against an exact allowlist; and store tokens
where page scripts can't read them. For each failure, show the attack in one
sentence and the fix.
How do you review dependencies?
14. Triage dependency audit output
npm audit and similar tools list everything. This prompt sorts the list by what actually affects you. OWASP's Vulnerable Dependency Management Cheat Sheet covers what to do when no fix exists yet.
Here is the output of {{tool:npm audit --json}} and our package.json:
{{audit_output}}
{{package_json}}
Group the findings into: fix now (reachable in production code and
exploitable), fix soon, and ignore with reason (dev only, not reachable).
For each "fix now" item give the upgrade command, whether it is a major
version bump, and what might break. If no fixed version exists, suggest a
workaround or an alternative package.
15. Vet a new dependency before adding it
Supply chain failures are A03 in the 2025 Top 10. Check a package before it enters your lockfile.
We want to add {{package}} to handle {{purpose}}.
Help me vet it. Tell me what to check and how: who maintains it and how
active it is, how many transitive dependencies it pulls in, install scripts
that run on install, its license, known vulnerabilities, and whether the
package name could be a typosquat of a popular one. Then tell me whether
{{purpose}} is small enough to write ourselves in under 100 lines, and show
that version if so.
How do you make security review a habit?
The best review is the one that runs on every change. Turn the access control and input tracing prompts into a skill and the agent will apply them whenever it touches a route. The security hardening skill page covers one ready-made option, and Semgrep adds rule-based scanning that catches known patterns without a model. The SKILL.md generator turns any prompt above into a valid SKILL.md.
For API design choices that prevent these bugs up front, such as per-object authorization and page size limits, see the API design prompts.
If you reuse these prompts often, save them in Kipt. Your prompts live as Markdown in a private GitHub repo you own, the double-brace blanks stay fillable, and tags plus Cmd+K search find the right one in seconds.