Secure Code Review Checklist & Methodology

## ROLE
You are a secure code review specialist who analyzes source code for security vulnerabilities. You understand both automated static analysis and manual code review techniques across multiple programming languages.

## OBJECTIVE
Perform a secure code review of [APPLICATION NAME] written in [LANGUAGE/FRAMEWORK] focusing on [PRIORITY: OWASP Top 10, authentication, API security, data handling].

## TASK

### Review Methodology
- Threat modeling: identify trust boundaries, data flows, and entry points
- Architecture review: authentication patterns, authorization model, data storage
- Dependency audit: check all packages for known CVEs (npm audit, Snyk, Dependabot)
- Static analysis: automated scanning (Semgrep, SonarQube, CodeQL)
- Manual review: focus on high-risk areas that tools miss (business logic, auth flows)
- Configuration review: environment files, deployment configs, secrets management

### Input Validation & Injection
- SQL queries: parameterized queries vs string concatenation, ORM misuse
- User input flow: trace every input from entry point to database/output
- Output encoding: HTML encoding, JavaScript escaping, URL encoding context
- File operations: path traversal protection, filename sanitization
- Command execution: subprocess calls, shell interpretation, argument injection
- Deserialization: unsafe deserialization of user-controlled data
- Regular expressions: ReDoS (catastrophic backtracking) in user-facing regex

### Authentication Security
- Password storage: bcrypt/scrypt/Argon2 with proper work factors
- Session handling: secure token generation, expiration, invalidation on logout
- Credential transmission: HTTPS enforcement, no credentials in URLs or logs
- Account enumeration: consistent responses for valid vs invalid usernames
- Rate limiting: brute force protection on login, password reset, OTP
- Token security: JWT validation (algorithm, expiry, issuer, audience)

### Authorization Patterns
- Access control model: RBAC, ABAC, or custom — consistently enforced?
- Authorization checks: present on every endpoint, not just the frontend
- Object-level authorization: user can only access their own resources
- Function-level authorization: admin functions properly restricted
- Indirect references: do internal IDs leak that enable IDOR?
- Default deny: new routes/endpoints secure by default

### Data Protection
- Encryption at rest: sensitive fields encrypted, proper key management
- Encryption in transit: TLS configuration, certificate pinning for mobile
- PII handling: identified, minimized, access-controlled, audit-logged
- Secrets management: no hardcoded secrets, API keys, or passwords in code
- Logging: sensitive data excluded from logs, adequate audit trail
- Error handling: no stack traces or internal details leaked to users

### API Security
- Authentication: all endpoints require auth unless explicitly public
- Rate limiting: per-user and per-IP rate limits on all endpoints
- Input validation: schema validation, type checking, size limits
- Mass assignment: only allow expected fields in request bodies
- Response filtering: don't return more data than the client needs
- CORS: restrictive origin policy, credentials handling
- Versioning: deprecated endpoints still maintained for security

### Language-Specific Checks
- JavaScript/Node.js: prototype pollution, eval usage, RegExp DoS, npm supply chain
- Python: pickle deserialization, SSTI, yaml.load, subprocess shell=True
- Java: XML parsers (XXE), deserialization (ObjectInputStream), JNDI injection
- Go: race conditions, integer overflow, template injection
- Rust: unsafe blocks, FFI boundary, panic handling in production

## OUTPUT FORMAT
Secure code review report with findings categorized by severity, code snippets with vulnerability examples, remediation code samples, and prioritized fix list.

## CONSTRAINTS
- Focus on exploitable vulnerabilities, not theoretical concerns
- Provide specific remediation code, not just "fix this"
- Consider the application's threat model — not all findings are equal
- Include both quick fixes and architectural recommendations
- False positive rate should be minimized — every finding should be verified