Secure Code Review Checklist Generator

What this prompt does

This prompt generates a structured security review checklist tailored to your exact stack — not a generic OWASP summary, but a checklist that knows your language's idioms, your framework's known pitfalls, and your authentication mechanism's specific failure modes. The ten-category structure maps directly to where real vulnerabilities live in production code, and the grep pattern requirement forces the output to be immediately actionable rather than theoretical.

What makes it work is the combination of [language], [framework], and [data_sensitivity] together. A high sensitivity rating on a Laravel app with JWT auth produces different cryptography and logging warnings than the same stack with [data_sensitivity]: internal. The [framework]-Specific category at the end is deliberately open-ended — it catches things like Laravel's mass assignment guard bypasses, Django's CSRF exempt decorator misuse, or Express middleware ordering bugs that no generic list would surface.

The prompt also asks for the secure alternative alongside each vulnerability, so reviewers don't just know what's wrong — they know what right looks like in that language.

When to use it

• Before merging a feature branch that touches auth, file uploads, or external API calls.
• When onboarding a junior developer to security review — gives them a concrete checklist they can follow without deep expertise.
• During a pre-release security pass on an MVP before it handles real user data.
• When your team inherits a legacy codebase and needs to triage where to start.
• After a dependency upgrade touching auth libraries or cryptographic packages.
• When setting up a new repository's pre-commit hooks and security gates from scratch.

Example output

For [language]: PHP, [framework]: Laravel, [app_type]: SaaS API, [auth_type]: JWT + OAuth2, [data_sensitivity]: high:

**Category: Authentication — JWT Issues**
What to look for: Algorithm confusion attacks (HS256 vs RS256), 'none' algorithm
acceptance, missing expiry validation.

Grep pattern:
  grep -rn --include="*.php" --exclude="*.blade.php" \
    "JWT::decode\|'alg'.*'none'\|JWT.*verify.*false" app/

Secure alternative:
  // RS256 is asymmetric — decode with the PUBLIC key, not a shared secret
  Firebase\JWT\JWT::decode($token, new Key($publicKey, 'RS256'));

Severity if exploited: Critical — full authentication bypass.

Recommended tools:
  - enlightn/enlightn (Laravel-specific audit suite, ./vendor/bin/enlightn --ci)
  - enlightn/security-checker (composer.lock advisory check,
    ./vendor/bin/security-checker security:check)
  - spatie/laravel-csp (Content Security Policy headers)

Pre-commit hook:
  ./vendor/bin/enlightn --ci

Pro tips

• Set [data_sensitivity] honestly — the model calibrates severity ratings and logging warnings based on this. high surfaces PII logging in debug output that low skips.
• Before treating generated grep patterns as gospel, run them against your actual codebase and check the match count. Patterns that return hundreds of hits need tightening — add --include="*.php" --exclude="*.blade.php" to scope PHP-only files and eliminate Blade template noise from the start.
• For the [framework]-Specific category, if your framework is niche (e.g., Filament, Livewire), name both the meta-framework and the base: [framework]: Laravel/Livewire 3. You get wire:model mass-assignment and lazy-loading bypass warnings the generic Laravel checklist misses.
• Pair this prompt's output with your CI pipeline — copy the generated pre-commit hook config directly into .githooks/pre-commit and the linting tools into your composer.json dev dependencies as a single pass.
• Re-run with a different [auth_type] if your app supports multiple auth paths (e.g., API key + session). Each auth mechanism has its own failure surface and a single checklist will miss the intersections.