Secure Code Review Checklist for Indian Development Teams

A secure code review catches what SAST tools cannot reason about: whether a handler actually enforces authorization, whether tenant data is scoped correctly, whether a deserialization call trusts attacker-controlled input, and whether crypto is used correctly rather than merely present. Static analysis is necessary but not sufficient — it flags known bad patterns in isolation; it cannot trace whether the object ID in a request maps to the caller's own tenant. Indian engineering teams shipping fast under delivery pressure need a checklist that a human reviewer can run against every pull request without becoming a bottleneck.

Why SAST alone is not enough

Static Application Security Testing (SAST) tools are pattern matchers. They are excellent at catching hardcoded secrets, use of deprecated crypto functions, obvious SQL string concatenation, and known-vulnerable library versions. What they are structurally bad at is business-logic context: a SAST scanner cannot tell you that GET /api/invoices/:id fetches an invoice by primary key without checking whether the invoice belongs to the requesting tenant. That is an authorization bug, not a syntax pattern, and it is invisible to a tool that reads code line by line without understanding your data model.

OWASP's own guidance is explicit about this gap. The OWASP Code Review Guide states that manual review is required to catch business-logic flaws, and the OWASP Top 10 for 2021 elevated "Broken Access Control" to the number one risk category precisely because these flaws are pervasive and hard to detect automatically (owasp.org). Access-control and authorization defects are logic errors specific to your application; no generic scanner ships with knowledge of your tenant model.

What a human reviewer must check that tools miss

1. Authorization on every handler, not just the "protected" ones

The single most common defect a human reviewer finds is a handler that authenticates the caller (confirms who they are) but never checks whether that caller is allowed to perform the requested action on the requested resource. This is broken access control, and it is routinely exploited as an Insecure Direct Object Reference (IDOR) — changing an ID in a URL or payload to access another user's data.

Checklist for every new or modified handler:

1. Does this endpoint check authentication AND authorization separately?
2. Is the authorization check performed on the object the caller is trying to access, using an ID from the request — not just a role check that ignores which record is being touched?
3. Are admin-only or internal endpoints reachable only through the intended route, with no unauthenticated debug/test path left in?
4. Does every new route added in this diff inherit the same authorization middleware as sibling routes, or was it added ad hoc?

2. Tenant scoping in multi-tenant SaaS

For any Indian SaaS product serving multiple customers from shared infrastructure, every database query that reads or writes tenant data must be scoped to the caller's tenant ID. A missing WHERE tenant_id = ? clause, or an ORM query that fetches by primary key alone, is a cross-tenant data leak waiting for a curious or malicious user to change one number in a request.

Checklist:

1. Does every query touching multi-tenant tables filter by tenant/organization ID derived from the authenticated session — never from a client-supplied field?
2. Do background jobs, webhooks, and admin tools apply the same tenant scoping as user-facing endpoints?
3. Are joins across tables tenant-scoped on both sides, not just the outer query?

3. Secrets in code, config, and logs

SAST and secret-scanning tools catch obvious hardcoded API keys reasonably well, but reviewers still need to check for secrets that leak through logging statements, error messages returned to clients, or committed .env.example files that were later filled in and committed for real. A human reviewer should also check whether a secret that was previously exposed has actually been rotated, not just removed from the current diff — removing a key from git history requires more than a new commit.

4. Unsafe deserialization

Deserializing untrusted input into native objects — via libraries like Python's pickle, Java's native serialization, or unsafe YAML loaders — is a well-documented path to remote code execution. This is exactly the class of bug behind the Log4Shell vulnerability (CVE-2021-44228) in Apache Log4j, where a crafted string passed to a logging call triggered JNDI lookups and remote code execution; it remains one of the most cited examples of why input handling in serialization/lookup paths deserves manual scrutiny even in trusted-looking library code (nvd.nist.gov). Reviewers should flag any deserialization of request bodies, cookies, or queue messages using non-safe loaders, and confirm yaml.safe_load (not yaml.load), safe JSON parsing, or an allow-listed deserializer is used.

5. Injection sinks beyond SQL

SAST catches naive string-concatenated SQL well. It is weaker on: NoSQL query injection (MongoDB operator injection via unsanitized JSON), command injection through exec/subprocess calls built from user input, template injection in server-side rendering, and LDAP/XPath injection in enterprise integrations. A reviewer should trace every place user input reaches a sink that interprets it as code or a query, and confirm parameterization or a safe API is used rather than string building.

6. Cryptography misuse

Presence of encryption is not the same as correct encryption. Common defects a scanner misses because the crypto library itself is "approved": ECB mode used for anything beyond a single block, IVs/nonces reused across encryptions, keys derived from low-entropy secrets without a proper KDF, and JWTs verified without checking the algorithm (the classic alg:none bypass). NIST's guidance on cryptographic standards (NIST SP 800-57 and related publications) is the reference point for correct key management and algorithm choice (nist.gov); reviewers should confirm the usage pattern matches guidance, not just that an approved library is imported.

Fitting this into PR review without slowing delivery

The objection every engineering lead raises is fair: a full manual security review of every line in every PR is not sustainable at delivery velocity. The fix is not to review everything deeply — it is to route review depth by risk, automating the parts that automation is good at and reserving human attention for the parts that automation cannot see.

The routing logic in that diagram is the entire discipline: every PR gets automated SAST and dependency/secret scanning by default — cheap, fast, catches known patterns. Only PRs that touch authentication, payments, or data-access layers get pulled into a deeper human review pass focused specifically on the six checklist items above. Everything else proceeds through standard peer review. This keeps average review time low while ensuring the highest-risk diffs — the ones that actually cause breaches — get the scrutiny automation cannot provide.

The split below is qualitative, not a precise statistic — but it reflects the well-documented pattern in secure development literature: automation dominates on syntactic, known-pattern defects, while business-logic flaws like broken access control skew heavily toward findings that only a human reviewer with context on the system catches.

Building secure code review into your workflow

Codify the six checks above as a PR template checklist item, not tribal knowledge held by one senior engineer. Indian teams growing past their first few engineers lose this discipline exactly when it matters most — during rapid hiring, when reviewers with the security context are outnumbered by reviewers without it. A written checklist, enforced as a PR template section that must be explicitly checked off for auth/payment/data-access diffs, survives team turnover in a way that "ask the senior dev to look at it" does not.

Pair this discipline with periodic independent verification. A checklist-driven human review reduces the rate at which access-control and logic flaws reach production, but it does not replace a full penetration test that chains multiple findings the way a real attacker would. Combining continuous automated scanning, checklist-driven human PR review, and periodic professional VAPT — delivered with a CERT-In empanelled partner where a compliance mandate requires it — covers the layers that any single control misses on its own. DSCI's guidance to Indian enterprises on secure development consistently emphasizes this layered approach rather than reliance on any one tool (dsci.in).

For organizations building toward DPDP Act compliance, secure code review is also a documented control that demonstrates "reasonable security safeguards" under the Act — the standard MeitY has signaled will be assessed in the event of a personal-data breach investigation. Read more on the DPDP compliance page.

Bachao.AI runs automated VAPT scanning that complements this human review layer — surfacing the known-pattern vulnerabilities and misconfigurations continuously, so your engineers' limited manual-review time stays focused on the authorization and business-logic defects that only a human can catch. Dhisattva AI Pvt Ltd built the platform specifically for Indian teams that need continuous coverage without a dedicated in-house security function. You can book a free VAPT scan to see where your current pipeline's blind spots are, or browse our security blog for more on secure development practice.