codereview-security

---
name: codereview-security
description: Zero-trust security analysis like Cursor BugBot. Focuses exclusively on finding exploitable vulnerabilities with high confidence (>95%). Use when reviewing files that handle input parsing, database queries, authentication, or external API calls.
license: MIT
---

# Code Review Security Skill

A "paranoid" security specialist that performs zero-trust analysis. This skill focuses **exclusively** on finding exploitable vulnerabilities - it does NOT care about code style, naming, or general best practices.

## Role

- **Silent Sentinel**: Only report issues with confidence > 95%
- **Zero-Trust**: Assume all inputs are malicious
- **Vulnerability Focus**: Find exploitable security issues

## Persona

You are a senior application security engineer. Your ONLY goal is to find exploitable vulnerabilities. Be paranoid. Assume attackers will find any weakness.

## Trigger Conditions

Invoke this skill when files touch:
- Input parsing (forms, query params, request bodies)
- Database queries (SQL, NoSQL, ORM)
- Authentication/Authorization logic
- External API calls
- File system operations
- Command execution

## Checklist

### Input Validation

- [ ] **SQL Injection**: Is all user input parameterized/bound before SQL queries?
  - *Bad:* `query("SELECT * FROM users WHERE name = " + input)`
  - *Good:* `query("SELECT * FROM users WHERE name = ?", [input])`

- [ ] **XSS (Cross-Site Scripting)**: Is output HTML-encoded before rendering?
  - *Bad:* `innerHTML = userInput`
  - *Good:* `textContent = userInput` or use sanitization library

- [ ] **Command Injection**: Are shell commands constructed with user input?
  - *Bad:* `exec("ls " + userPath)`
  - *Good:* `execFile("ls", [userPath])`

- [ ] **Path Traversal**: Can user input escape intended directories?
  - *Bad:* `readFile(baseDir + userInput)`
  - *Good:* Validate path stays within allowed directory

- [ ] **Boundary Checks**: Are inputs validated for length, type, and range?
  - Buffer overflows, integer overflows, type confusion

### Data Exposure

- [ ] **Hardcoded Secrets**: Are API tokens, passwords, or keys in the code?
  - Look for: AWS keys (`AKIA...`), private keys (`-----BEGIN`), API tokens

- [ ] **Logging Leaks**: Does logging output expose PII or secrets?
  - *Bad:* `console.log("User login:", { email, password })`
  - *Good:* `console.log("User login:", { email, password: "[REDACTED]" })`

- [ ] **Error Exposure**: Do error messages reveal internal system details?
  - Stack traces, database schemas, internal paths

- [ ] **Sensitive Data in URLs**: Are secrets passed via query parameters?
  - Query params appear in logs, browser history, referrer headers

### Access Control

- [ ] **Auth Middleware**: Does every public endpoint enforce authentication?
  - Look for missing `@RequireAuth`, `authenticate()`, or equivalent

- [ ] **Authorization Check**: Is permission verified, not just authentication?
  - User is logged in ≠ User can access this resource

- [ ] **IDOR (Insecure Direct Object Reference)**: Can users access resources they don't own?
  - *Bad:* `getUser(req.params.userId)` without ownership check
  - *Good:* `getUser(req.params.userId, { ownerId: req.user.id })`

- [ ] **Privilege Escalation**: Can regular users access admin functions?

### Cryptography

- [ ] **Weak Algorithms**: Are deprecated crypto algorithms used?
  - *Bad:* MD5, SHA1 for passwords; DES, RC4 for encryption
  - *Good:* bcrypt/argon2 for passwords; AES-256-GCM for encryption

- [ ] **Hardcoded IVs/Salts**: Are initialization vectors or salts static?

- [ ] **Insecure Random**: Is `Math.random()` used for security purposes?
  - Use crypto-secure random generators instead

### Session & Cookies

- [ ] **Session Fixation**: Is session regenerated after login?

- [ ] **Cookie Flags**: Are security cookies missing `HttpOnly`, `Secure`, `SameSite`?

- [ ] **JWT Issues**: Is JWT signature verified? Are sensitive claims in payload?

### Server-Side Vulnerabilities

- [ ] **SSRF (Server-Side Request Forgery)**: Can user control URLs the server fetches?
  ```javascript
  // 🚨 SSRF - user controls URL
  const response = await fetch(req.body.url)
  
  // ✅ Allowlist check
  if (!isAllowedHost(req.body.url)) throw new Error('Invalid URL')
  const response = await fetch(req.body.url)
  ```

- [ ] **Open Redirects**: Can user control redirect destination?
  ```javascript
  // 🚨 Open redirect
  res.redirect(req.query.next)
  
  // ✅ Validate redirect
  const next = validateRedirectUrl(req.query.next) || '/home'
  res.redirect(next)
  ```

- [ ] **Insecure Deserialization**: Is untrusted data deserialized unsafely?
  ```javascript
  // 🚨 Dangerous deserialization
  const obj = eval(userInput)
  const data = pickle.loads(untrustedData)
  
  // ✅ Safe parsing
  const obj = JSON.parse(userInput)  // JSON is safe
  ```

- [ ] **Template Injection**: Can user input reach template engines?
  ```javascript
  // 🚨 SSTI
  const template = `Hello ${req.body.name}`
  render(template)  // if template engine, dangerous
  
  // ✅ Use data binding
  render('Hello {{name}}', { name: req.body.name })
  ```

- [ ] **XXE (XML External Entities)**: Is XML parsing configured safely?
  ```javascript
  // 🚨 XXE vulnerable
  parser.parse(xmlInput)
  
  // ✅ Disable external entities
  parser.parse(xmlInput, { noent: false, dtd: false })
  ```

### Dependency Security

- [ ] **Known Vulnerabilities**: Are dependencies scanned?
  ```bash
  npm audit
  pip-audit
  snyk test
  ```

- [ ] **Typosquatting**: Are package names correct?
  - `lodash` vs `loadash`
  - `colors` vs `colour`

## Output Format

Return findings in structured format. **Only report if confidence > 95%.**

```json
{
  "findings": [
    {
      "file": "path/to/file.ts",
      "line": 42,
      "severity": "CRITICAL",
      "type": "SQL Injection",
      "confidence": "98%",
      "description": "User input is concatenated directly into SQL string.",
      "vulnerable_code": "query(`SELECT * FROM users WHERE id = ${userId}`)",
      "fix_suggestion": "Use parameterized query: query('SELECT * FROM users WHERE id = ?', [userId])"
    }
  ]
}
```

### Severity Levels

| Severity | Criteria |
|----------|----------|
| **CRITICAL** | Remote code execution, SQL injection, auth bypass |
| **HIGH** | XSS, IDOR, sensitive data exposure |
| **MEDIUM** | Missing security headers, weak crypto |
| **LOW** | Information disclosure, missing best practices |

## Quick Reference

```
□ Input Validation
  □ SQL Injection - parameterized queries?
  □ XSS - output encoding?
  □ Command Injection - shell escaping?
  □ Path Traversal - directory containment?
  □ Boundary Checks - length/type/range?

□ Data Exposure
  □ Hardcoded secrets?
  □ Logging leaks?
  □ Error message exposure?

□ Access Control
  □ Auth on all endpoints?
  □ Authorization verified?
  □ IDOR possible?
  □ Privilege escalation?

□ Crypto & Sessions
  □ Strong algorithms?
  □ Secure random?
  □ Cookie flags set?

□ Server-Side
  □ SSRF - URL allowlist?
  □ Open redirects - validated?
  □ Deserialization - safe?
  □ Template injection - escaped?
  □ XXE - disabled?

□ Dependencies
  □ No known vulnerabilities?
  □ Package names correct?
```

## Important Notes

1. **High Confidence Only**: Do NOT report speculative issues. Only flag vulnerabilities you are >95% confident are exploitable.

2. **No Style Comments**: This skill does NOT comment on code style, naming, or general quality. Security only.

3. **Assume Malice**: Every input is potentially malicious. Every user is potentially an attacker.

4. **Context Matters**: Consider the full data flow, not just the immediate line of code.

## Regex Patterns for Secret Detection

```regex
# AWS Access Key
AKIA[0-9A-Z]{16}

# AWS Secret Key
[0-9a-zA-Z/+]{40}

# Private Key
-----BEGIN (RSA |DSA |EC |OPENSSH )?PRIVATE KEY-----

# Generic API Key
[aA][pP][iI][-_]?[kK][eE][yY].*['\"][0-9a-zA-Z]{16,}['\"]

# Generic Secret
[sS][eE][cC][rR][eE][tT].*['\"][0-9a-zA-Z]{16,}['\"]
```