Engineering Security Review Code Review

Security Code Review Prompt

Twelve security checks — injection, auth, secrets, SSRF, privilege escalation — reviewed the way an attacker would read the code.

Overview

Generic reviews miss security issues because security needs its own questions: not "is this clean?" but "is authorization checked per resource, not just per login? do any outbound requests use user-controlled URLs?". This setup runs the security focus — twelve attacker-minded checks covering injection vectors, XSS encoding, hardcoded secrets, logging leaks, weak crypto, insecure deserialization, path traversal, and SSRF — under Strict style: every finding flagged, no praise padding, APPROVED or CHANGES REQUIRED.

How to use this resource

  1. Run it on the scary paths first

    Auth middleware, payment handlers, file uploads — the places where a missed finding costs the most.

  2. Treat CRITICALs as merge blockers

    The severity rules already say it: vulnerabilities are CRITICAL, and CRITICAL means fixed before merge.

  3. Re-review after the fix

    Same prompt, fixed code — security fixes have a habit of introducing their own findings.

Why This Works

  • Attacker-framing ("review this the way an attacker would read it") changes what the model looks for
  • Named vectors (SSRF, path traversal, deserialization) beat "check for security issues"
  • Strict style suits security: a flattering review of vulnerable code is worse than none

Best for

  • Pre-release reviews of security-sensitive paths
  • Teams without a dedicated security reviewer on every PR
  • Code that touches auth, payments, file handling, or user input

Not for

  • A substitute for a professional penetration test — this raises the floor, not the ceiling
  • Fixing the findings — review judges; the fix is a separate, deliberate step

Use cases

  • Reviewing auth and input-handling code before a release
  • Catching the injection vector a feature-focused review skims past
  • Checking AI-suggested code for the security corners it cut

FAQ

Which security risks does this prompt check, and how are findings reported?

It runs twelve attacker-minded checks: authentication on every entry point, per-resource authorization, injection (SQL, command, template, path), XSS output encoding, hardcoded secrets, log leaks, weak crypto, privilege escalation via user-controlled IDs, insecure deserialization, path traversal, and SSRF. Each failing item is one bullet tagged [CRITICAL], [MAJOR], [MINOR], or [NIT], grouped CRITICAL-first, ending in APPROVED or CHANGES REQUIRED.

Can this replace a professional penetration test before we ship?

Treat it as a floor, not a ceiling. It runs twelve static checks against pasted code wherever you run the prompt and ends in CHANGES REQUIRED or APPROVED, but a live pen test probes a running system, chained exploits, and network paths this file-level read never touches. Run both, and keep the ship decision yours.

Will running this prompt catch every vulnerability in my code?

No — an APPROVED verdict means nothing on the twelve checklist items failed for the file you pasted, not that the code is proven secure. The review reads the way an attacker would but still misses logic flaws, cross-file interactions, and runtime state a real attacker exploits. Its verdict is a structured signal for your own judgment; fixing findings stays a separate step you own.

More resources from Code Review Prompt Generator

Resources that pair well

Related tools

Projects that use this resource

Workflows that use this resource

Guides for this resource

Tip: Save time by exploring related resources and tools that integrate with this resource.