Security Review Checklist
Apply these security checks when reviewing or writing code that handles sensitive operations.
Instructions
Step 1: Identify Security-Sensitive Areas
Scan the changed files for:
- Authentication / authorization logic
- User input handling
- Database queries
- API endpoints
- File operations
- Cryptographic operations
- Secrets / credentials
Step 2: Check Security Controls
Review authentication, authorization, and input validation controls.
For the detailed checklist, consult references/checklist.md.
Step 3: Scan for Dangerous Patterns
Use Grep to search for these red-flag patterns in the codebase:
eval(user_input) # Code injection
exec(user_input) # Code injection
os.system(user_input) # Command injection
f"SELECT * FROM {table}" # SQL injection
innerHTML = userData # XSS
password = "hardcoded" # Hardcoded secret
verify=False # SSL verification disabled
shell=True # Shell injection risk
pickle.loads( # Unsafe deserialization
yaml.load( # Unsafe YAML loading
For complete vulnerability patterns and secure alternatives, consult references/vulnerabilities.md.
Step 4: Verify Data Protection
- Sensitive data encrypted at rest and in transit (TLS)
- No secrets in source code (use environment variables or vault)
- No sensitive data in logs
- PII handled according to regulations
- API keys rotatable, different per environment
Step 5: Validate Findings
For each flagged issue:
- Use Grep to check if the pattern is mitigated elsewhere (middleware, wrappers, framework protections)
- Check framework-level protections before reporting (e.g., Django ORM, React JSX auto-escaping)
- Verify the input source — internal/trusted sources may not need the same controls
- Classify severity:
- Critical: Remote code execution, authentication bypass, data breach
- High: SQL injection, XSS, privilege escalation
- Medium: Missing rate limiting, verbose error messages, weak encryption
- Low: Informational findings, minor configuration issues
Step 6: Final Security Checklist
- [ ] No injection vulnerabilities (SQL, XSS, Command)
- [ ] Authentication and authorization properly implemented
- [ ] All user input validated
- [ ] Secrets not hardcoded
- [ ] Sensitive data encrypted
- [ ] Security events logged (without sensitive data)
- [ ] Rate limiting on public endpoints
- [ ] CORS configured correctly
- [ ] Dependencies free of known vulnerabilities
Report Format
For each finding:
- Severity: Critical / High / Medium / Low
- Location: file:line
- Issue: Brief description
- Suggestion: Specific fix or secure alternative
Examples
Example 1: SQL Injection Prevention
# INSECURE - SQL injection
query = f"SELECT * FROM users WHERE name = '{user_input}'"
# SECURE - Parameterized query
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (user_input,))
Example 2: XSS Prevention
// INSECURE - XSS via innerHTML
element.innerHTML = userComment;
// SECURE - Use textContent or sanitization
element.textContent = userComment;
// or use DOMPurify for HTML content
element.innerHTML = DOMPurify.sanitize(userComment);
Example 3: Secret Management
# INSECURE - Hardcoded secret
API_KEY = "sk-abc123..."
# SECURE - Environment variable
API_KEY = os.environ["API_KEY"]
Common Issues
If security review seems incomplete:
- Use Grep to find all usages of the flagged pattern across the codebase
- Check framework-level middleware (auth, CSRF, etc.)
- Consult
references/vulnerabilities.mdfor the full OWASP Top 10 mapping