A security code review examines source code to identify vulnerabilities, logic flaws, and insecure patterns before they reach production. It complements automated scanning tools (SAST) by catching issues that require human judgment: business logic flaws, subtle race conditions, incorrect authorization checks, and architectural weaknesses.
Code review is one of the most cost-effective security activities. Finding a vulnerability during review and fixing it in the same pull request is orders of magnitude cheaper than finding it through a penetration test or, worse, a production incident.
Authentication and authorization flaws. Is every endpoint checking that the user is authenticated? Is authorization enforced at the object level, not just the endpoint level? Can a user access or modify another user's resources by changing an ID parameter?
Input handling. Is all external input validated? Are SQL queries parameterized? Is output properly encoded for its context? Are file uploads checked for type, size, and content?
Secrets and credentials. Are there any hardcoded API keys, passwords, or tokens? Are secrets being logged or exposed in error messages? Are environment variables used appropriately?
Cryptography. Are modern algorithms used (AES-256, SHA-256, bcrypt/Argon2 for passwords)? Are there custom crypto implementations (a major red flag)? Is encryption properly implemented with appropriate modes and IVs?
Error handling. Do error messages leak internal details? Are exceptions caught and handled appropriately? Is sensitive data exposed in logs?
Race conditions. Are there time-of-check-to-time-of-use (TOCTOU) issues? Are shared resources properly synchronized? Can concurrent requests create inconsistent states?
Third-party dependencies. Are dependencies up to date? Have new dependencies been evaluated for security? Are there known vulnerabilities in current versions?
Focus on changed code and its context. Read the full function, not just the diff. A change might be safe in isolation but introduce a vulnerability in the context of surrounding code.
Follow the data flow. Trace user input from where it enters the application to where it is processed, stored, and displayed. Every point along this path is a potential vulnerability location.
Check for missing controls. Security bugs are often about what is not there: the missing authorization check, the absent input validation, the unset security header. Reviewing for the absence of controls requires a checklist or mental model of what should be present.
Use automated tools as a starting point. Run SAST tools (Semgrep, CodeQL, SonarQube) before the human review. Let the tool catch the obvious issues (SQL injection via string concatenation, hardcoded credentials) so human reviewers can focus on logic and architecture.
Not every pull request needs a deep security review. Prioritize based on risk: code that handles authentication, processes payments, manages permissions, parses untrusted input, or implements cryptography deserves thorough review. A configuration change to a logging format does not.
Create a security review checklist tailored to your tech stack and common vulnerability patterns. Share it with all developers so security awareness becomes part of every code review, not just dedicated security reviews.
Pair junior developers with senior security-minded engineers during reviews. This builds security knowledge across the team more effectively than training alone.
Treat security findings as learning opportunities, not blame events. Document patterns that recur and create linting rules or SAST custom rules to catch them automatically in the future.