PS Product SecurityKnowledge Base

✅ Language-Specific Secure Coding Review Checklists

Use this page when: you want short, stack-aware review questions that can be reused in PRs, onboarding, or security champion sessions.

PHP

  • Are request values ever concatenated into SQL, shell commands, or file paths?
  • Are uploads validated by type and stored outside the web root?
  • Is output encoding context-appropriate rather than raw echo of user content?
  • Do object fetches prove owner, tenant, or delegated access scope?
  • Are framework or helper functions used instead of handwritten crypto or auth logic?

Python

  • Is untrusted input reaching subprocess, template rendering, deserialization, or filesystem paths?
  • Are ORM or database calls parameterized instead of string-built?
  • Are FastAPI / Flask / Django routes enforcing both authentication and object scope?
  • Are dangerous parser or serializer choices justified and bounded?
  • Are admin or worker tasks validating input separately from web handlers?

Go

  • Are handlers validating both caller identity and object scope before data access?
  • Is database/sql used with parameters rather than string interpolation?
  • Are SSRF-prone outbound requests bounded by allowlists or routing controls?
  • Are file and archive operations protected against traversal and zip-slip style mistakes?
  • Are errors handled explicitly without leaking sensitive internals to clients?

Java

  • Are deserialization, XML parsing, and templating choices hardened intentionally?
  • Are Spring or servlet controllers relying on framework auth only, or is resource-level auth enforced too?
  • Are dangerous reflection, expression, or script paths constrained?
  • Are secrets, tokens, or credentials ever logged or returned in exceptions?
  • Are security-sensitive defaults overridden explicitly where the framework expects it?

JavaScript (Node + browser-adjacent)

  • Is untrusted input reaching eval, shell helpers, filesystem paths, or server-side fetch logic?
  • Are DOM or HTML rendering paths encoded or sanitized for the actual context?
  • Are redirects, URL fetches, and webhook targets constrained?
  • Are cookies, sessions, and token flows handled with explicit trust assumptions?
  • Are dependencies and middleware choices introducing unsafe defaults?

TypeScript

  • Are types being mistaken for security controls instead of runtime validation?
  • Are route params, body fields, and query values validated at runtime?
  • Are ORM/query-builder abstractions still preserving safe parameter handling?
  • Are DTOs, schemas, and authz checks aligned so typed code does not hide broken access control?
  • Are frontend and backend shared types causing over-trust across boundaries?

SQL

  • Do queries enforce data scope in the query itself, not only in application logic?
  • Are dynamic clauses (sort, filter, table name) safely constrained?
  • Are privileges minimal for the account executing the query or procedure?
  • Do procedures or views accidentally expose broader tenant data than intended?
  • Are writes and reads both covered by authz logic rather than only one side?

Turning checklists into real controls

A checklist becomes much stronger when at least one item is converted into:

  • a reusable review comment;
  • a unit or integration test pattern;
  • a SonarQube / Semgrep / linter rule where precision is acceptable;
  • a release criterion for sensitive services.

Use with

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.