secure-coding-review

Secure Coding Review

Apply this checklist when reviewing code for security. It is intentionally framework-agnostic — map each item onto the language and libraries in front of you. Report findings grouped by severity (Critical / High / Medium / Low) with a file:line reference and a concrete fix.

Checklist

Input validation

• All external input (request bodies, query params, headers, file contents, env) is validated against an allowlist of shape, type, and range before use.
• No reliance on client-side validation alone.

Authentication & authorization

• Every privileged action checks both that the caller is authenticated and that they're authorized for the specific resource (no missing object-level authorization / IDOR).
• No auth logic that can be bypassed by missing/empty tokens; deny by default.

Secrets handling

• No credentials, API keys, tokens, or private keys hardcoded in source or committed config.
• Secrets come from a vault or environment, are never logged, and are excluded from error responses.

Injection

• SQL: parameterized queries / prepared statements — never string concatenation.
• Command: avoid shelling out with interpolated input; use argument arrays and avoid shell interpretation.
• Path: canonicalize and confine paths to an intended base directory to prevent traversal (../).
• Output is contextually encoded/escaped to prevent XSS and template injection.

Unsafe deserialization

• No deserialization of untrusted data into arbitrary types (e.g. native pickle/unserialize/Java object streams). Prefer schema-bound formats (JSON with strict parsing).

Dependency risk

• New dependencies are reputable, pinned, and free of known CVEs.
• No unnecessary transitive surface added; lockfile updated.

Output format

For each finding:

[SEVERITY] <short title> — <file>:<line>
  Why it matters: ...
  Fix: ...

If nothing is found, say so explicitly and note what was checked.