Secure Code Review: What Your Audit Should Cover

A secure code review checklist gives your reviewers one consistent way to catch security flaws before code reaches production: injection, broken access control, leaked secrets, weak cryptography and unsafe memory handling. The checklist below is grouped by area, written as short checks a reviewer can tick off, and mapped to OWASP guidance so your findings line up with what auditors and enterprise customers expect.

Use it as a companion to everyday pull-request reviews, and as the structure for deeper pre-release or compliance reviews. If you build CCTV cameras or IoT devices, there is a firmware addendum near the end for C/C++ code that is heading to STQC testing.

What makes a secure code review different

A normal code review asks "does this work and is it maintainable?". A secure code review asks "how could this be abused?". The reviewer follows untrusted data from where it enters (requests, files, device inputs) to where it is used (queries, commands, pages, memory buffers) and checks that the right control sits in between.

Two free OWASP resources are worth keeping open while you review. The OWASP Code Review Guide (version 2.0) explains the methodology and what to look for, vulnerability by vulnerability. The OWASP Application Security Verification Standard (ASVS) is a catalogue of testable security requirements organised into three levels, from Level 1 for most applications to Level 3 for high-assurance systems. Many teams use ASVS requirement IDs as the reference in their code review template, which makes findings easy to trace and audit.

How to run a secure code review in five steps

1. Scope. Agree the repositories, modules and commits in scope and the ASVS level you are reviewing against. Ask for an architecture diagram and a list of entry points such as APIs, admin panels and device interfaces.
2. Run tools first. Let automation clear the obvious issues: SAST (for example Semgrep or SonarQube), secret scanning (Gitleaks), dependency scanning (OWASP Dependency-Check or Grype) and, for C/C++, Cppcheck and Flawfinder.
3. Manual pass. Read the high-risk code by hand: authentication, authorisation, payment and data-export flows, cryptography, file handling and anything that builds queries or commands. This is where logic flaws and IDOR are found.
4. Triage by severity. Remove false positives, then rate each real finding (Critical, High, Medium, Low, or a CVSS score). Record the file, line, impact and a concrete fix for each.
5. Fix and retest. Developers fix the issues, and the reviewer confirms each fix in the new code, catching partial fixes that only cover one code path.

The secure code review checklist, area by area

Treat each item as a question for the code in front of you. Mark items that do not apply as N/A rather than deleting them, so the record shows they were considered.

1. Input validation and output encoding

• Validate all input on the server, not only in the browser or mobile app.
• Prefer allowlists (expected type, length, format, range) over blocklists.
• Use parameterised queries or a safe ORM API for every database call. No string concatenation into SQL.
• Avoid passing user input to shell commands, eval or template engines. Where unavoidable, use safe APIs with fixed arguments.
• Encode output for its context (HTML body, attribute, JavaScript, URL) and rely on the framework's auto-escaping.
• Check that XML parsers disable external entities (XXE).
• Validate URLs the server fetches on a user's behalf against an allowlist to prevent SSRF.

2. Authentication

• Hash passwords with Argon2id, bcrypt, scrypt or PBKDF2. Never MD5, SHA-1 or unsalted hashes.
• Rate-limit or lock out repeated login, OTP and password-reset attempts.
• Make reset tokens random, single-use and short-lived.
• Support multi-factor authentication for admin and high-value accounts.
• Re-authenticate users before sensitive actions such as changing email, password or bank details.

3. Authorisation and access control (IDOR)

• Check authorisation on the server for every request, not by hiding buttons in the UI.
• For every object ID in a URL, body or header, confirm the current user owns or may access that object. This is the classic IDOR (insecure direct object reference) check.
• Deny by default. New endpoints should be closed until a rule explicitly allows access.
• Enforce roles centrally (middleware or policy layer) instead of scattered if checks.
• Confirm users cannot change their own role, tenant ID or price fields through the request.

4. Session management

• Generate session IDs with a secure random source and rotate them after login.
• Set cookies with Secure, HttpOnly and an appropriate SameSite value.
• Apply idle and absolute timeouts, and invalidate sessions on the server at logout.
• For JWTs, verify the signature with a fixed algorithm, reject alg: none, and check expiry, issuer and audience.
• Protect state-changing requests against CSRF where cookies carry the session.

5. Cryptography and secrets

• Search for hard-coded passwords, API keys, private keys and tokens, including in test files, config and git history.
• Load secrets from a secrets manager or environment, never from source control.
• Use vetted libraries and modern algorithms: AES-GCM or ChaCha20-Poly1305, RSA 2048-bit or larger, or elliptic curves.
• Flag DES, 3DES, RC4, ECB mode, MD5 and SHA-1 used for security purposes.
• Use a cryptographically secure random generator for tokens, never Math.random() or rand().
• Enforce TLS 1.2 or higher and never disable certificate validation, even "temporarily".

6. Error handling and logging

• Show users generic error messages. No stack traces, SQL errors or internal paths.
• Fail closed: an exception in an access check must deny, not allow.
• Log security events such as logins, failures, permission denials and admin changes, with time and user ID.
• Never log passwords, OTPs, session tokens, full card numbers or Aadhaar numbers.

7. Data protection and personal data

• Map where personal data is collected, stored, sent and deleted in the code.
• Collect only the fields you need, and mask or truncate them in responses and screens.
• Encrypt sensitive personal data at rest and always in transit.
• Implement retention and deletion logic that actually removes data, including from backups and caches where feasible.

India's Digital Personal Data Protection Act, 2023 (DPDP Act) requires organisations handling personal data to take reasonable security safeguards to prevent personal data breaches. A documented secure code review is one practical way to show those safeguards exist in the software itself.

8. Dependencies and supply chain

• Run software composition analysis (SCA) on every build, for example with OWASP Dependency-Check or Grype.
• Generate an SBOM (software bill of materials), for example with Syft, and keep it with each release.
• Pin dependency versions and commit lock files.
• Remove unused or abandoned packages, and watch for typo-squatted names.
• Protect the CI/CD pipeline: limited tokens, reviewed workflow changes and signed build artefacts.

9. Configuration and security headers

• Turn off debug mode, verbose errors and sample endpoints in production builds.
• Change or remove all default accounts and passwords.
• Set Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff and frame protection (frame-ancestors or X-Frame-Options).
• Restrict CORS to known origins. Never reflect any origin while allowing credentials.

10. API-specific checks

• Apply object-level authorisation on every API route. This is the top risk in the OWASP API Security Top 10 (2023).
• Block mass assignment by binding requests to explicit allowlisted fields.
• Return only the fields the client needs, not whole database objects.
• Apply rate limits, pagination limits and request size limits.
• Authenticate service-to-service calls and keep API keys out of mobile apps and front-end code.

11. File upload and file handling

• Allowlist file types and check the file content (magic bytes), not just the extension.
• Enforce maximum file size and count.
• Rename uploads to random names and store them outside the web root, without execute permissions.
• Block path traversal (../) in any file name or path built from user input.
• Watch archive extraction for path traversal (zip slip) and oversized decompressed content.

Mapping the checklist to the OWASP Top 10 (2021)

Mapping findings to the OWASP Top 10 helps managers and auditors read results quickly. OWASP has since published a newer edition, but the 2021 categories are still widely cited.

API and file upload findings usually map to A01, A03, A05 or A07, depending on the flaw.

Addendum: embedded and IoT firmware checklist

CCTV cameras, routers and other connected devices bring risks that web checklists miss, mostly in C and C++ firmware. Teams preparing for STQC testing in India can use this addendum to clean up code before submitting to the lab.

• Search for unsafe C functions: gets (removed from the C11 standard), strcpy, strcat, sprintf and scanf("%s"). Replace them with bounded versions such as fgets and snprintf.
• Check every buffer copy, array index and length calculation against the real buffer size, including integer overflow in size arithmetic.
• Review format strings: never pass user input as the format argument to printf-style functions.
• Disable or lock UART, JTAG and other debug interfaces, and remove debug shells and telnet from production images.
• Remove default and hard-coded credentials. Force a unique password at first setup.
• Sign firmware updates and verify the signature on the device before installing. Prevent rollback to older vulnerable versions.
• Store keys and certificates in protected storage, not in plain files inside the firmware image.
• Check third-party components such as BusyBox, OpenSSL and vendor SDKs for known vulnerabilities, and keep an SBOM.

Tools such as Cppcheck and Flawfinder help with the source, while Binwalk and Ghidra help inspect the built firmware image. Xtreme InfoSec is not STQC and does not issue STQC certificates, but our source code review for STQC certification helps CCTV and IoT manufacturers find and fix these issues before lab testing.

Turning this into a code review template

A source code review checklist only helps if people use it. Put the five to ten items most relevant to your stack in your pull-request template, keep the full list for release reviews and audits, and add the ASVS requirement ID next to each item.

Frequently asked questions