Rodin
b988751861
Models already know what SQL injection and XSS are. They don't need tutorials - they need a checklist to ensure nothing is missed. Before: 23 individual pattern files (~100KB total) After: 1 focused checklist (~4KB) Same coverage, better signal-to-noise ratio for review context.
98 lines
3.7 KiB
Markdown
98 lines
3.7 KiB
Markdown
# Security Review Checklist
|
|
|
|
Focused prompts for code review. Models know *what* these are - this is a checklist to ensure nothing is missed.
|
|
|
|
## Input & Validation
|
|
|
|
- [ ] All external input validated (allowlist preferred over blocklist)
|
|
- [ ] SQL/NoSQL queries use parameterized statements, never string interpolation
|
|
- [ ] Command execution avoids shell when possible; if required, use allowlist for commands/args
|
|
- [ ] Path traversal prevented (resolve base + canonicalize + verify prefix)
|
|
- [ ] XML parsing disables external entities (XXE)
|
|
- [ ] Deserialization uses safe formats (JSON) or strict type allowlists
|
|
|
|
## Authentication & Sessions
|
|
|
|
- [ ] Passwords hashed with bcrypt/argon2/scrypt (not sha256/md5)
|
|
- [ ] Timing-safe comparison for secrets (`hmac.compare_digest`, `crypto.timingSafeEqual`)
|
|
- [ ] Session tokens cryptographically random, sufficient entropy (≥128 bits)
|
|
- [ ] Session invalidated on logout and password change
|
|
- [ ] JWT: verify signature, check `exp`/`iat`/`nbf`, validate `iss`/`aud`, reject `alg: none`
|
|
- [ ] MFA for sensitive operations
|
|
|
|
## Authorization
|
|
|
|
- [ ] Server-side enforcement (never trust client for authz)
|
|
- [ ] Check ownership on every resource access (IDOR prevention)
|
|
- [ ] Principle of least privilege for service accounts and API keys
|
|
- [ ] Admin functions have explicit role checks
|
|
|
|
## Secrets & Credentials
|
|
|
|
- [ ] No hardcoded secrets in code or config files
|
|
- [ ] Secrets loaded from environment/vault at runtime
|
|
- [ ] API keys have minimal scopes
|
|
- [ ] Credentials never logged (even at debug level)
|
|
|
|
## Request Handling
|
|
|
|
- [ ] SSRF: validate/allowlist URLs before server-side requests; block internal IPs
|
|
- [ ] Open redirect: validate redirect targets against allowlist
|
|
- [ ] CSRF tokens on state-changing operations
|
|
- [ ] Rate limiting on authentication and expensive endpoints
|
|
- [ ] Request size limits enforced
|
|
|
|
## Response & Headers
|
|
|
|
- [ ] CSP header set (script-src, default-src)
|
|
- [ ] CORS: explicit origin allowlist, avoid `*` with credentials
|
|
- [ ] X-Frame-Options or CSP frame-ancestors (clickjacking)
|
|
- [ ] Sensitive data not in URLs (appears in logs/referer)
|
|
- [ ] Error messages don't leak internals (stack traces, SQL, file paths)
|
|
|
|
## Concurrency & State
|
|
|
|
- [ ] Race conditions: use transactions or locks for check-then-act patterns
|
|
- [ ] TOCTOU: verify state at moment of action, not before
|
|
- [ ] Idempotency keys for payment/critical operations
|
|
- [ ] Optimistic locking where appropriate
|
|
|
|
## File Operations
|
|
|
|
- [ ] Upload: validate content type (magic bytes, not just extension)
|
|
- [ ] Upload: store outside webroot or with non-executable permissions
|
|
- [ ] Upload: generate random filenames, don't use user-provided names
|
|
- [ ] Serve user content with `Content-Disposition: attachment` or from separate domain
|
|
|
|
## Logging & Audit
|
|
|
|
- [ ] Security events logged: auth success/failure, privilege changes, sensitive access
|
|
- [ ] Logs don't contain secrets, tokens, or full credentials
|
|
- [ ] Logs are immutable/append-only for forensics
|
|
- [ ] Structured logging with correlation IDs
|
|
|
|
## Dependencies & Supply Chain
|
|
|
|
- [ ] Dependencies pinned to exact versions
|
|
- [ ] Lockfile committed and verified in CI
|
|
- [ ] Dependency audit in CI pipeline
|
|
- [ ] Minimal dependencies (smaller attack surface)
|
|
|
|
## AI/LLM Specific
|
|
|
|
- [ ] User input clearly delimited from system instructions
|
|
- [ ] Output validation before tool execution
|
|
- [ ] Rate limiting on LLM-powered features
|
|
- [ ] No secrets accessible to LLM context
|
|
|
|
---
|
|
|
|
## When to Escalate
|
|
|
|
Flag for human security review if:
|
|
- Crypto implementation (not just usage of established libraries)
|
|
- Authentication/authorization architecture changes
|
|
- New external integrations with sensitive data
|
|
- Payment or financial transaction handling
|
|
- Changes to logging/audit infrastructure
|