Anthony Bordonaro

Security Scan Prompt

Prompt
promptssecuritycode-reviewowasp

Security reviews are usually either superficial ("looks fine") or overwhelming (200-page pentest report with 50 "informational" findings). This prompt targets the middle ground: a focused scan for the vulnerabilities that actually affect web applications, with a specific fix for each finding. Not a replacement for professional pentesting, but good enough to catch the things that most commonly ship to production.

The prompt

Perform a security review of this codebase. Check for the following vulnerability categories and report findings with specific file locations and fix suggestions.

## Categories to check

### 1. Injection
- **SQL injection**: Are queries built with string concatenation instead of parameterized queries?
- **Command injection**: Are user inputs passed to shell commands (exec, spawn) without sanitization?
- **Template injection**: Are user inputs interpolated into templates (server-side or client-side) without escaping?

### 2. Cross-Site Scripting (XSS)
- Is user-generated content rendered with `dangerouslySetInnerHTML`, `v-html`, or equivalent without sanitization?
- Are URL parameters or hash fragments reflected into the page without encoding?
- Is markdown or rich text from users converted to HTML without a sanitization step?

### 3. Authentication & Session Management
- Are passwords hashed with a strong algorithm (bcrypt, argon2) or a weak one (MD5, SHA1, plain text)?
- Are JWTs validated properly (algorithm, expiration, issuer)?
- Are there routes or API endpoints missing authentication checks?
- Is there authorization (can user X access resource Y) or just authentication (is someone logged in)?

### 4. Secrets Exposure
- Are API keys, passwords, tokens, or connection strings hardcoded in source files?
- Is `.env` in `.gitignore`?
- Are secrets logged or included in error messages sent to clients?
- Are client-side bundles including server-only environment variables?

### 5. Insecure Data Handling
- Is sensitive data (passwords, tokens, PII) logged?
- Are cookies set with appropriate flags (HttpOnly, Secure, SameSite)?
- Is sensitive data stored in localStorage (accessible via XSS)?

### 6. Security Headers & CORS
- Is Content-Security-Policy (CSP) configured?
- Are X-Frame-Options, X-Content-Type-Options, Referrer-Policy headers set?
- Is CORS configured restrictively (not `Access-Control-Allow-Origin: *` for authenticated endpoints)?

## Output format

### Critical (exploitable now)
- **[Vulnerability type]** in `[file:line]` — [How it could be exploited]. Fix: [specific code change].

### High (exploitable with effort)
- **[Vulnerability type]** in `[file:line]` — [Description]. Fix: [specific code change].

### Medium (defense-in-depth)
- **[Issue]** — [Description]. Fix: [specific code change].

### Informational
- **[Observation]** — [Not directly exploitable but worth noting].

### Not applicable
[List categories that were checked but don't apply to this project and why — e.g., "No database queries found, SQL injection not applicable"]

## Rules
- Only report real findings with specific file and line references. No theoretical risks.
- Respect framework protections. React auto-escapes JSX output, so don't flag JSX string rendering as XSS. DO flag dangerouslySetInnerHTML, user-controlled href attributes, and markdown-to-HTML conversion.
- Provide the fix, not just the finding. Every finding must include a concrete remediation.
- Be honest about severity. A missing CSP header is defense-in-depth (medium), not critical.
- The "Not applicable" section is required — it confirms you actually checked each category.

When to use it

  • Before launching a new feature that handles user input
  • After adding authentication, payment processing, or any sensitive flow
  • When onboarding to a codebase — understand the security posture early
  • As part of a pre-release checklist, paired with the Code Review prompt

When NOT to use it

  • As a replacement for professional penetration testing — this catches common issues, not sophisticated attack vectors
  • On purely static sites with no user input, no authentication, and no backend — almost every category will be "not applicable"

Tips

  • Start with Critical findings and fix those before moving to lower severity. A codebase with zero critical findings and some medium findings is in good shape.
  • To check for secrets in git history, use a dedicated tool like gitleaks or trufflehog rather than grepping through git log — they understand secret patterns and produce structured output.
  • The "Not applicable" section is one of the most valuable parts of the output — it confirms that each category was actually considered, not just skipped.
Back to AI Toolkit