Application security review checklist

Audit code or a feature design for vulnerabilities, mapped to realistic attack scenarios and fixes.

Change note: Initial version

Prompt

Act as an application security engineer reviewing a {{language}} {{app_type}}.

What it does and what is sensitive (data, money, privileges): {{context}}
Threat concerns: {{concerns}}

Code, configuration or design to review:
{{code}}

Review for these classes of problems, skipping any that do not apply: injection (SQL, command, template), authentication and session handling, authorization and object-level access checks, input validation and output encoding, secrets and key handling, unsafe deserialization and file handling, SSRF and open redirects, cryptography misuse, logging of sensitive data, dependency and configuration risks, and denial-of-service vectors.

For every finding give:
- Severity (critical, high, medium, low) and the matching weakness category (CWE or OWASP name if you know it with confidence).
- Location in the code.
- A realistic attack in two or three sentences: who, what they send, what they gain.
- A fix with a short secure code example.

Rules: report only issues supported by the code shown and say "needs verification" where it depends on code you cannot see. Do not pad with generic advice. End with a short list of things that look correct and a prioritized fix order. If you notice nothing wrong in an area, say so briefly.

Variables

• {{language}}Languageselect

  Options: TypeScript, JavaScript, Python, Go, Java, C#, Rust, Ruby, PHP, Kotlin, Swift, C++

  Default: Python

• {{app_type}}Application typeselect

  Options: Web API, Web app, Mobile backend, CLI tool, Serverless function, Library

  Default: Web API

• {{context}}What it doeslong

  Default: Invoice API where users download PDFs of their own invoices; stores customer addresses.

• {{concerns}}Main concernstext

  Default: Access control and file handling

• {{code}}Code or designlongrequired

  Paste the handlers, config or design notes.

Example output

**1. Broken object-level authorization: High (CWE-639)**
`download_invoice` (api/invoices.py:31) looks up the invoice by `invoice_id` only. Any logged-in user can request `/invoices/1042/pdf`, then 1043, and read other customers' addresses. Fix:
```python
invoice = Invoice.query.filter_by(id=invoice_id, account_id=current_user.account_id).first_or_404()
```

**2. Path traversal: High (CWE-22)**
The PDF is read from `os.path.join(PDF_DIR, request.args["name"])`. A request with `name=../../etc/passwd` escapes the directory. Fix: ignore the client value; build the path from the stored invoice id, or check the resolved path stays under `PDF_DIR`.

**3. Verbose errors: Low**
Unhandled exceptions return a stack trace with the database URL. Needs verification that debug mode is off in production.

**Looks correct:** parameterized queries in `list_invoices`; passwords hashed with a modern algorithm.

**Fix order:** 1, 2, then 3.

Notes

Asking for a realistic attack for each finding filters out theoretical noise, and 'needs verification' keeps the model honest about code it cannot see. Review one module at a time for the best depth.