Security-focused code review

--- name: security-focused-code-review description: "A checklist-driven way to review code changes for security flaws and report them with severity and concrete fixes. Use when reviewing a pull request, a code snippet, or new code that handles input, data or access." --- Apply this whenever you are asked to review code, or when code you are shown handles user input, authentication, permissions, secrets, files, databases or network calls. This is a review of the user's own code for defensive purposes. How to review 1. First understand what the code does, where untrusted data enters (requests, files, headers, environment, third-party responses) and where it ends up (queries, commands, templates, logs, storage, responses). 2. Follow each untrusted input to every place it is used. Check for injection (SQL, command, template, path), unsafe deserialization, and output that is not encoded for its context. 3. Check access control on every action: is the caller authenticated, and are they allowed to touch this specific record, not just any record? 4. Check secrets and data: no hard-coded credentials, no sensitive data in logs or error messages, encryption where data is stored or sent, minimal data returned. 5. Check robustness: input size and rate limits, safe defaults, failures that close rather than open, dependency versions with known issues if visible. 6. Only then note code quality issues that affect security. How to report - Start with a one-line verdict: safe to merge, merge after fixes, or do not merge. - Then a list of findings, most severe first. For each: severity (critical, high, medium, low), location, what is wrong, a realistic way it could be abused in one sentence, and a corrected code snippet or a precise fix. - End with what you did not check (for example, code not shown, configuration, infrastructure). Avoid - Reporting theoretical issues as critical without a plausible path to abuse. - Vague advice such as 'validate input'; say which input, which rule, and where. - Writing exploit code; describe the risk, not a weaponized payload. - Assuming the code is safe because it is short or internal.

Verdict: do not merge until finding 1 is fixed. 1. Critical - orders.py, line 42: SQL built with string formatting from the 'status' query parameter. Anyone can alter the query and read other customers' orders. Fix: use a parameterized query: cursor.execute('SELECT * FROM orders WHERE status = %s AND customer_id = %s', (status, user.id)) 2. High - orders.py, get_order(): fetches by order_id without checking ownership. A logged-in user can view any order by changing the id. Fix: add customer_id = current_user.id to the lookup and return 404 otherwise. 3. Low - logger call on line 58 writes the full request body, including addresses. Fix: log the order id only. Not checked: authentication middleware and deployment config (not shown).