security-checks

name	security-checks
description	Security patterns and detection rules for automated code review. Automatically loaded when performing security reviews, checking for vulnerabilities, or when "security check", "vulnerability", "CVE", "security patterns", or "security audit" are mentioned.

Security Checks

Stable Detection Patterns

These patterns have low false-positive rates and rarely change. Apply consistently across all reviews.

1. Hardcoded Credentials

Detection: API keys, passwords, tokens, secrets embedded in source code.

Search patterns: String literals matching password, secret, api_key, token, apiKey, API_KEY, Bearer, Basic followed by base64-like strings, AWS access key patterns (AKIA...), private key headers (-----BEGIN).

BAD:  const API_KEY = "sk-abc123def456";
BAD:  password: "admin123"
BAD:  Authorization: "Bearer eyJhbGciOiJIUzI1NiIs..."

GOOD: const API_KEY = process.env.API_KEY;
GOOD: password: config.get("db.password")
GOOD: Authorization: `Bearer ${getToken()}`

Severity: Critical (always blocked)

2. SQL Injection

Detection: User input concatenated into SQL queries instead of parameterized queries.

Search patterns: String concatenation or template literals containing SQL keywords (SELECT, INSERT, UPDATE, DELETE, WHERE) with variable interpolation.

BAD:  db.query(`SELECT * FROM users WHERE id = ${userId}`);
BAD:  db.query("SELECT * FROM users WHERE name = '" + name + "'");

GOOD: db.query("SELECT * FROM users WHERE id = $1", [userId]);
GOOD: db.query("SELECT * FROM users WHERE name = ?", [name]);

Severity: Critical

3. Cross-Site Scripting (XSS)

Detection: Unescaped user input rendered in HTML output.

Search patterns: innerHTML, dangerouslySetInnerHTML, document.write, eval() with user-controlled input, template literals in HTML context without sanitization.

BAD:  element.innerHTML = userInput;
BAD:  <div dangerouslySetInnerHTML={{__html: userComment}} />

GOOD: element.textContent = userInput;
GOOD: <div>{DOMPurify.sanitize(userComment)}</div>

Severity: High

4. Path Traversal

Detection: User input used in file system paths without sanitization.

Search patterns: fs.readFile, fs.writeFile, path.join, path.resolve with user-controlled segments, presence of ../ in path inputs without validation.

BAD:  fs.readFile(path.join(uploadsDir, req.params.filename));
BAD:  const file = `./data/${userInput}`;

GOOD: const safeName = path.basename(req.params.filename);
      fs.readFile(path.join(uploadsDir, safeName));
GOOD: if (resolved.startsWith(allowedDir)) { fs.readFile(resolved); }

Severity: High

5. Insecure Deserialization

Detection: Deserializing data from untrusted sources without validation.

Search patterns: JSON.parse on external input without schema validation, eval() for data parsing, unserialize on user data, yaml.load (unsafe) vs yaml.safeLoad.

BAD:  const data = JSON.parse(req.body);
      processOrder(data.orderId, data.amount);

GOOD: const data = orderSchema.parse(JSON.parse(req.body));
      processOrder(data.orderId, data.amount);

Severity: High

6. Weak Cryptography

Detection: Use of deprecated or weak cryptographic algorithms for security purposes.

Search patterns: MD5, SHA1 used for password hashing or security tokens, DES, 3DES, RC4 for encryption, ECB mode, key sizes < 256 bits for symmetric encryption.

BAD:  crypto.createHash("md5").update(password).digest("hex");
BAD:  crypto.createCipheriv("aes-128-ecb", key, null);

GOOD: await bcrypt.hash(password, 12);
GOOD: crypto.createCipheriv("aes-256-gcm", key, iv);

Severity: High (passwords), Medium (other uses)

7. Server-Side Request Forgery (SSRF)

Detection: User-controlled URLs used in server-side HTTP requests.

Search patterns: fetch, axios, http.get, request with user-provided URL or hostname, URL construction from user input without allowlist validation.

BAD:  const response = await fetch(req.query.url);
BAD:  const data = await axios.get(`http://${userHost}/api`);

GOOD: if (ALLOWED_HOSTS.includes(new URL(url).hostname)) {
        const response = await fetch(url);
      }

Severity: High

8. Open Redirects

Detection: User-controlled redirect targets without validation.

Search patterns: res.redirect, window.location, location.href with user input, returnUrl, redirectTo, next parameters used directly.

BAD:  res.redirect(req.query.returnUrl);
BAD:  window.location.href = params.get("next");

GOOD: const url = new URL(req.query.returnUrl, APP_ORIGIN);
      if (url.origin === APP_ORIGIN) res.redirect(url.toString());

Severity: Medium

Trend-Sensitive Patterns

These patterns require awareness of current threats. Use WebSearch to verify latest advisories when reviewing.

9. Dependency Vulnerabilities

Detection: Known CVEs in project dependencies.

Action: Check package.json, requirements.txt, go.mod, or equivalent against recent advisories.

WebSearch queries:

• "[package-name] CVE [current-year]"
• "[package-name] security advisory"
• "npm audit [package-name]"

Severity: Varies by CVE (Critical to Low)

10. API Key Exposure

Detection: API keys, tokens, or secrets accessible in client-side code or git history.

Search patterns:

• Keys in client-side bundles (files under public/, static/, client-side imports)
• Keys committed to git history (git log -p --all -S "API_KEY")
• Keys in .env files committed to repository
• Environment variables prefixed with NEXT_PUBLIC_, VITE_, REACT_APP_ containing secrets

BAD:  // client-side file
      const STRIPE_SECRET = "sk_live_abc123";

GOOD: // server-side only, never exposed to client
      const STRIPE_SECRET = process.env.STRIPE_SECRET_KEY;

Severity: Critical (production keys), High (development keys)

11. JWT Misconfigurations

Detection: Insecure JWT implementation patterns.

Search patterns: algorithm: "none", algorithms: ["HS256", "none"], missing expiresIn, symmetric secrets < 256 bits, verify: false, missing audience/issuer validation.

BAD:  jwt.sign(payload, "secret123");
BAD:  jwt.verify(token, secret, { algorithms: ["HS256", "none"] });

GOOD: jwt.sign(payload, process.env.JWT_SECRET, {
        algorithm: "RS256",
        expiresIn: "1h",
        audience: "api.example.com",
        issuer: "auth.example.com"
      });

Severity: Critical (algorithm none), High (weak secret/no expiry)

Severity Classification Guide

Severity	Impact	Action Required
Critical	Direct exploitation possible, data breach risk	Immediate fix, blocks deployment
High	Exploitable with moderate effort, significant impact	Fix before release
Medium	Limited exploitability or impact	Fix in next sprint
Low	Minimal risk, defense-in-depth improvement	Track as tech debt

Aggregation Rules

• 1+ Critical finding → status: blocked
• 1+ High finding (confirmed_risk) → status: needs_revision
• Only Medium/Low findings → status: approved_with_notes
• No findings → status: approved

Expert References (Reasoning Calibration)

When facing security assessment decisions, calibrate your reasoning against these established principles:

Expert	Key Principle	Apply When
OWASP	"Never trust input"	Reviewing any data from external sources
Saltzer & Schroeder	"Fail-safe defaults — deny by default"	Evaluating access control implementations
Kerckhoffs	"Security must not depend on secrecy of the mechanism"	Reviewing hardcoded secrets or security-through-obscurity
NIST	"Use approved cryptographic algorithms and key lengths"	Evaluating cryptographic implementations