Netspective Logo

Review Checklists

Comprehensive checklists for thorough code reviews

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:

ControlReview Focus
C1: Access ControlAuthorization checks on all protected resources; deny-by-default patterns
C2: CryptographyProper encryption for sensitive data; secure key management practices
C3: Input ValidationAll inputs validated server-side; allowlist approach preferred
C4: Security by DesignSecurity integrated into architecture, not bolted on afterward
C5: Secure DefaultsSystems secure without additional hardening; fail-safe configurations
C6: Component SecurityDependencies current and monitored; vulnerable libraries identified
C7: Digital IdentityAuthentication mechanisms properly implemented; session security
C8: Browser SecuritySecurity headers used; CSP configured; cookie attributes set
C9: Security LoggingSecurity events logged; monitoring in place; no sensitive data in logs
C10: SSRF PreventionServer-side requests validated; URL allowlisting where applicable

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

StageAutomatedManual Review Focus
Pre-commitLinting, formattingN/A
PR/CISAST scan, dependency checkDesign, logic, security architecture
MergeAll checks passFinal approval on flagged items

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

LanguageTools
JavaScript/TypeScriptESLint security plugins, Semgrep, Snyk
PythonBandit, Semgrep, Safety
JavaSpotBugs, Find Security Bugs, Checkmarx
C#Security Code Scan, Roslyn Analyzers
Gogosec, staticcheck
Multi-languageSonarQube, Snyk Code, GitHub CodeQL

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

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

How is this guide?

Last updated on

On this page