Code review is a deliberate second look at source code before release. A team reviews one another’s changes to find security problems, defects, exposed secrets, and authorization errors before attackers or users encounter them. Making time for review matters especially when deadlines are tight or legacy code is involved. section 1.8 section 1.9
Make code review part of the development process:
- Require someone other than the author to review and approve changes before merging them into the main branch or deploying them externally. section 5.11
- Use source-control workflows such as pull requests to create a clear review point, and require unit tests to pass before the final merge. section 5.11 section 5.7
- Inspect templates and client-side code for sensitive information such as API keys, internal URLs, and IP addresses; supplement human review with static analysis or TruffleHog. section 13.11
- Review authorization logic critically, compare its behavior with design documents, and use QA or fresh reviewers to expose ambiguous access-control cases. section 10.13
- After an incident, strengthen the process with broader change reviews, vulnerability testing, automated scanning, refactoring, audits, or architectural changes. section 15.4
A safer pull request
A developer opens a pull request for a change to an externally facing application. A teammate reviews and approves it, unit tests pass, and static analysis checks templates and client-side code for API keys or internal URLs. Authorization behavior is checked against the application’s design documents before the change reaches production. section 5.11 section 13.11 section 10.13
