Review Checklists

Use these checklists to ensure consistent, thorough code reviews. Not every item applies to every PR—use judgment based on the change.

General Review Checklist

Correctness

• ☐ Code does what it's supposed to do
• ☐ Edge cases are handled
• ☐ Error handling is appropriate
• ☐ No obvious bugs or logic errors
• ☐ Boundary conditions are correct

Design

• ☐ Code is in the right place (right module/class)
• ☐ Appropriate design patterns used
• ☐ No unnecessary complexity
• ☐ Dependencies are appropriate
• ☐ Changes are backward compatible (or breaking changes documented)

Readability

• ☐ Code is easy to understand
• ☐ Variable and function names are clear
• ☐ Complex logic has comments explaining "why"
• ☐ No dead code or commented-out code
• ☐ Consistent formatting

Testing

• ☐ Adequate test coverage
• ☐ Tests cover happy path and edge cases
• ☐ Tests are readable and maintainable
• ☐ No flaky tests introduced
• ☐ Integration tests where appropriate

Performance

• ☐ No obvious performance issues
• ☐ Appropriate data structures used
• ☐ Database queries are efficient
• ☐ No N+1 query problems
• ☐ Resources are properly released

Security

• ☐ No hardcoded secrets
• ☐ Input is validated
• ☐ Output is escaped (XSS prevention)
• ☐ SQL injection prevented (parameterized queries)
• ☐ Authentication/authorization checked

Security-Focused Checklist

Authentication & Authorization

• ☐ Authentication required where needed
• ☐ Authorization checks in place
• ☐ Principle of least privilege followed
• ☐ Session management is secure
• ☐ Password handling follows best practices

Input Validation

• ☐ All user input is validated
• ☐ Validation happens server-side
• ☐ Input length limits enforced
• ☐ Input type checking performed
• ☐ File uploads are restricted and validated

Output Encoding

• ☐ HTML output is escaped
• ☐ JSON responses are properly encoded
• ☐ SQL queries use parameters
• ☐ OS commands avoid user input
• ☐ URLs are properly encoded

Data Protection

• ☐ Sensitive data is encrypted at rest
• ☐ Sensitive data is encrypted in transit
• ☐ PII is handled appropriately
• ☐ Logging doesn't include sensitive data
• ☐ Error messages don't leak information

OWASP Top 10 Check

• ☐ Injection vulnerabilities
• ☐ Broken authentication
• ☐ Sensitive data exposure
• ☐ XML external entities (XXE)
• ☐ Broken access control
• ☐ Security misconfiguration
• ☐ Cross-site scripting (XSS)
• ☐ Insecure deserialization
• ☐ Known vulnerable components
• ☐ Insufficient logging

OWASP Proactive Controls Alignment

When reviewing code, verify these ten security controls are implemented correctly:

Secure Input Validation Checklist

Input validation is a primary defense against injection attacks. Review for:

Validation Strategy

• ☐ Server-side validation implemented (client-side alone is bypassable)
• ☐ Allowlist approach used over denylist filtering
• ☐ Syntactic validation enforces correct format (dates, SSNs, currency)
• ☐ Semantic validation ensures business logic correctness (start date before end date)

Implementation Details

• ☐ Type conversion uses strict exception handling
• ☐ Range checks enforce min/max values for numbers, dates, string lengths
• ☐ Predefined value arrays validate fixed-option inputs (dropdowns, radio buttons)
• ☐ Regular expressions use complete anchors (^...$) and avoid ReDoS patterns
• ☐ Unicode input properly handled with character category allowlisting

File Upload Security

• ☐ File extension validated against allowlist
• ☐ File size limits enforced
• ☐ Content-type verified (not just trusted from header)
• ☐ Files renamed on storage to prevent path traversal
• ☐ Upload directory has no execute permissions

Common Pitfalls to Catch

• Denylist filtering (fails against encoding tricks and evasion)
• Client-side-only validation
• Missing validation on hidden fields or dropdown values
• Regex patterns vulnerable to catastrophic backtracking

Error Handling Security Checklist

Improper error handling assists attackers during reconnaissance. Verify:

Information Disclosure Prevention

• ☐ Stack traces never exposed to end users
• ☐ Framework and version numbers not revealed in responses
• ☐ Database error messages with SQL not shown to clients
• ☐ File system paths never disclosed in errors
• ☐ Error messages are generic: "An error occurred, please retry"

Implementation Patterns

• ☐ Global/centralized exception handler implemented
• ☐ All exceptions caught and handled appropriately
• ☐ Error details logged server-side, not returned to user
• ☐ Custom error pages configured for all HTTP error codes

HTTP Status Codes

• ☐ 4xx codes used for client errors (bad request, unauthorized)
• ☐ 5xx codes used for server failures
• ☐ Response bodies don't leak details regardless of status code
• ☐ 5xx errors monitored as indicators of application failures

Security Logging Checklist

Security logging enables detection, investigation, and compliance. Review for:

Event Coverage

• ☐ Authentication successes and failures logged
• ☐ Authorization failures captured
• ☐ Input validation failures recorded
• ☐ Session management events tracked (creation, timeout, logout)
• ☐ Administrative actions logged
• ☐ Access to sensitive data recorded

Data Protection

• ☐ Passwords never logged (even on failed attempts)
• ☐ API keys, tokens, and secrets excluded
• ☐ PII minimized or masked in logs
• ☐ Database connection strings not logged
• ☐ Encryption keys never appear in logs

Log Injection Prevention

• ☐ User-controlled data sanitized before logging
• ☐ Carriage return (CR) and line feed (LF) stripped or encoded
• ☐ Delimiter characters escaped
• ☐ Log forging attacks prevented

Event Attributes

• ☐ Timestamps use consistent format (UTC preferred)
• ☐ User identity captured (who)
• ☐ Source IP/location recorded (where)
• ☐ Action/event type specified (what)
• ☐ Outcome (success/failure) noted

Storage and Access

• ☐ Logs stored securely with access controls
• ☐ Log access itself is audited
• ☐ Tamper detection implemented
• ☐ Retention policy defined and enforced
• ☐ Secure transmission if logs cross network boundaries

API Review Checklist

Design

• ☐ RESTful conventions followed
• ☐ Appropriate HTTP methods used
• ☐ Consistent URL structure
• ☐ Versioning strategy clear
• ☐ Resource naming is clear

Request/Response

• ☐ Request validation implemented
• ☐ Response format is consistent
• ☐ Error responses are informative
• ☐ Pagination implemented for lists
• ☐ Filtering/sorting where appropriate

Security

• ☐ Authentication required
• ☐ Rate limiting implemented
• ☐ CORS configured correctly
• ☐ Input size limits enforced
• ☐ Sensitive data not in URLs

Documentation

• ☐ OpenAPI/Swagger updated
• ☐ Examples provided
• ☐ Error codes documented
• ☐ Breaking changes noted

Database Review Checklist

Schema

• ☐ Appropriate data types used
• ☐ Indexes on queried columns
• ☐ Foreign keys where appropriate
• ☐ Constraints enforce data integrity
• ☐ Migration is reversible

Queries

• ☐ Queries are optimized
• ☐ No SELECT * in production code
• ☐ JOINs are efficient
• ☐ No N+1 query patterns
• ☐ Large results are paginated

Security

• ☐ Parameterized queries used
• ☐ Sensitive data encrypted
• ☐ Access controls appropriate
• ☐ Audit logging for sensitive operations

Performance

• ☐ Query plans reviewed for complex queries
• ☐ Appropriate use of transactions
• ☐ Connection pooling configured
• ☐ Timeouts configured

Frontend Review Checklist

Functionality

• ☐ Features work as expected
• ☐ Forms validate input
• ☐ Error states are handled
• ☐ Loading states are shown
• ☐ Works across target browsers

Accessibility

• ☐ Semantic HTML used
• ☐ ARIA labels where needed
• ☐ Keyboard navigation works
• ☐ Color contrast is sufficient
• ☐ Screen reader tested

Performance

• ☐ Images are optimized
• ☐ Assets are lazy-loaded
• ☐ Bundle size is reasonable
• ☐ No unnecessary re-renders
• ☐ Network requests are efficient

UX

• ☐ Consistent with design specs
• ☐ Responsive across screen sizes
• ☐ Touch targets are adequate
• ☐ Feedback for user actions
• ☐ Progressive enhancement

Infrastructure/DevOps Checklist

Configuration

• ☐ No hardcoded values
• ☐ Secrets use secret management
• ☐ Environment-specific configs
• ☐ Sensible defaults
• ☐ Documentation updated

Deployment

• ☐ Changes are backward compatible
• ☐ Rollback plan exists
• ☐ Health checks implemented
• ☐ Monitoring in place
• ☐ Alerts configured

Security

• ☐ Least privilege for permissions
• ☐ Network access restricted
• ☐ Encryption in transit
• ☐ Audit logging enabled
• ☐ Vulnerability scanning configured

Reliability

• ☐ Failure scenarios handled
• ☐ Retry logic appropriate
• ☐ Circuit breakers where needed
• ☐ Resource limits configured
• ☐ Auto-scaling configured

Test Review Checklist

Coverage

• ☐ Happy path covered
• ☐ Edge cases covered
• ☐ Error cases covered
• ☐ Boundary conditions tested
• ☐ Integration points tested

Quality

• ☐ Tests are deterministic
• ☐ Tests are independent
• ☐ Tests are fast
• ☐ Tests are readable
• ☐ Test names describe behavior

Maintainability

• ☐ No test code duplication
• ☐ Test fixtures are reusable
• ☐ Mocks are appropriate
• ☐ Tests don't depend on order
• ☐ Cleanup after tests

Documentation Review Checklist

Completeness

• ☐ README updated
• ☐ API docs updated
• ☐ Architecture docs updated
• ☐ Setup instructions accurate
• ☐ Examples provided

Quality

• ☐ Clear and concise
• ☐ Free of typos
• ☐ Code samples work
• ☐ Links are valid
• ☐ Formatting is consistent

Maintenance

• ☐ Version information current
• ☐ Deprecated items noted
• ☐ Changelog updated
• ☐ Migration guides provided

Static Analysis Integration

Manual code review and automated Static Application Security Testing (SAST) are complementary—neither alone is sufficient.

What SAST Does Well

• Scales efficiently across large codebases
• Integrates into CI/CD pipelines for continuous checking
• Detects well-known vulnerability patterns (buffer overflows, SQL injection)
• Provides specific file/line locations for findings
• Runs consistently without reviewer fatigue

Where Manual Review Is Essential

SAST tools struggle with:

• Authentication design flaws
• Access control logic errors
• Insecure cryptography usage
• Business logic vulnerabilities
• Configuration issues not in source code

Integration Approach

Selecting SAST Tools

Evaluate based on:

• ☐ Programming language support
• ☐ OWASP Top 10 detection accuracy
• ☐ False positive rate (high rates cause alert fatigue)
• ☐ IDE integration for developer workflow
• ☐ CI/CD pipeline compatibility
• ☐ Remediation guidance quality

Common Tools by Language

Using Checklists Effectively

Don't Be Mechanical

• Use checklists as a guide, not a script
• Apply judgment about what's relevant
• Focus on high-impact items first

Customize for Your Team

• Add team-specific items
• Remove items that don't apply
• Update based on common issues

Automate What You Can

• Linting for style
• Security scanning for vulnerabilities
• Test coverage for testing
• Reserve human review for judgment calls

Related Resources

• Pull Request Process
• Security
• Microsoft Playbook: Code Reviews
• OWASP Code Review Guide
• OWASP Proactive Controls
• OWASP Cheat Sheet Series

Compliance

This section fulfills ISO 13485 requirements for design verification (7.3.6) and production control (7.5.1), and ISO 27001 requirements for secure development (A.8.25-A.8.29) and security logging (A.8.15-A.8.16). Security checklists align with OWASP Top 10, Proactive Controls, and ASVS Level 2.

View full compliance matrix