0
Security-focused code review against a specific threat model
💀failed our automated checkAauraNovice
The prompt
Review this code for security issues, but scope it to the threat model I give you, don't produce a generic OWASP checklist dump. Threat model: {{threat_model, e.g. 'attacker controls request body and headers but has no valid auth token'}}.
For each finding:
1. State the exact attacker action that would trigger it, concretely, as if writing a proof-of-concept step.
2. State what the code currently assumes that isn't actually guaranteed (e.g. 'assumes Content-Type header matches actual body format').
3. Severity based on real exploitability given the threat model, not textbook severity (a SQL injection with no path for attacker-controlled input to the query isn't a blocker here).
4. Fix, minimal and specific to the code, not a rewrite.
5. Explicitly list what you checked and found NOT to be an issue given the threat model (e.g. 'CSRF not applicable, this is a server-to-server API with mTLS'), so I know the review was thorough rather than just silent on those.
Code: code
Auth/deployment context: context
Where it has been run
| Model | Version | People | Broke | Auto | Last |
|---|---|---|---|---|---|
| Claude | Haiku 4.5 | 0 | 0 | 0/1 | 4 days ago |
Example output
Finding: `parseInt(req.query.page, 10)` feeds directly into `LIMIT ${page * 20}` via string interpolation in the SQL. Attacker action: send `?page=1;DROP TABLE users;--` as the query param since parseInt on that string yields NaN, and the NaN check is missing before interpolation, so the raw string still reaches the query in some code paths. Severity: high, directly exploitable by an unauthenticated caller per your threat model. Fix: use a parameterized query placeholder for the LIMIT value, and add `Number.isInteger` validation before use.
Checked and not an issue: the CORS config allows only same-origin per `Access-Control-Allow-Origin`, so reflected-XSS-via-fetch isn't a realistic vector here given the threat model excludes a logged-in victim browser. Also checked for path traversal in the file-serving endpoint, the path is resolved against an allowlist before use, not exploitable as written.
0 comments
Sign in to comment or report what this prompt did for you.
Sign inNo comments yet. Run the prompt and report what you got.