subject: OWASP Top 10 Checklist for Security Code Review [print this page]
An OWASP Top 10 checklist for code review turns each risk category into questions a reviewer can answer by reading code: Does every endpoint check ownership? Is every query parameterized? Is output encoded for its context? Do error paths fail closed? Work through the ten categories on each security relevant pull request, focus on data flowing from untrusted sources to sensitive sinks and record findings using the category names so trends become visible.Most OWASP material explains what each risk is. That is useful for awareness, but a reviewer staring at a diff at four in the afternoon needs something different: concrete things to look for. This article is a reviewer's first OWASP Top 10 guide. It assumes you can already read the language and framework in front of you and want a repeatable way to catch security problems before they merge.For the broader category reference, our OWASP Top 10 web application security guide explains each risk in depth. Here we stay at code level.
How to Use This Checklist
A checklist works only if it fits into the review you already do. Treat the following threepass method as a default and adapt it to your team.Pass one: find the entry points. Identify every place the changed code accepts input: HTTP parameters, headers, cookies, uploaded files, message queue payloads, webhooks and values read from a database that originated with a user. Anything that crosses a trust boundary deserves attention. Pass two: trace the data. Follow each input to where it ends up. The interesting destinations, usually called sinks, include database queries, shell commands, file paths, template renderers, redirects, outbound HTTP requests, deserializers and log statements.Pass three: check the controls. For each path from entry point to sink, confirm that validation, encoding, authorization and error handling are present and correct. The checklist sections below are essentially prompts for this third pass.If your team has not formalized this workflow, our secure code review guide describes a full process, including how to prioritize files and how to write findings that developers act on.
Scope the Review Before Reading Code
Security review time is limited, so spend it where risk concentrates. Ask these questions about the pull request first: Does it touch authentication, sessions, permissions or user roles? Does it add or change an endpoint, API route or background job? Does it handle money, personal data, credentials or tokens? Does it add a dependency, a build step or a deployment setting? Does it parse, render or forward user controlled content? A no to all five usually means a lighter review is acceptable. A yes to any of them means the matching checklist items below are mandatory.
The OWASP Top 10 Checklist, Category by Category
The list below follows the current OWASP Top 10:2025 structure. Each category includes what to look for and a few review prompts.
A01 Broken Access Control (Including CSRF and SSRF)
This is the category where scanners help least and reviewers help most, because correct behavior depends on the application's permission model.
Checklist prompts
Is authorization enforced on the server for every route, including ones the interface never links to? When code loads a record by identifier, does it verify the record belongs to the current user or tenant? Are administrative functions protected by a role check, not just hidden in the interface? Do state changing requests carry anti forgery protection and does it apply to every method that changes data? CrossSite Request Forgery weaknesses are tracked under this category in recent editions. If the code makes outbound requests from usersupplied URLs, is the destination restricted to an allow list? ServerSide Request Forgery now sits here too.
A pattern worth flagging
python # Loads any invoice by ID no ownership check invoice = Invoice.query.get(request.args[id]) return jsonify(invoice.to_dict()) The safer version scopes the query to the authenticated user, for example by filtering on both the invoice ID and the current user's ID and returns a generic notfound response when nothing matches.
A02 Security Misconfiguration
Configuration lives in code reviews more often than people notice: framework settings, Dockerfiles, infrastructure templates and environment defaults.
Checklist prompts
Are debug modes, verbose errors and stack traces disabled outside development? Do new storage buckets, queues or databases default to private? Are default credentials, sample accounts and test routes removed? Are security headers set intentionally rather than left to defaults? Is crossorigin resource sharing restricted to named origins instead of a wildcard? Many of these hardening items are collected in our web security best practices article, which makes a good companion reference for this category.
A03 Software Supply Chain Failures
Checklist prompts
Is each new dependency necessary, actively maintained and obtained from the expected registry? Are versions pinned and lock files committed? Does the build download and execute anything without verifying it? Do pipeline changes expand who or what can publish artifacts? Are secrets kept out of build logs and repository history?
A04 Cryptographic Failures
Checklist prompts
Are passwords hashed with a slow, salted algorithm designed for that purpose, rather than a fast general purpose hash? Is sensitive data encrypted in transit and, where appropriate, at rest? Are keys, tokens and passwords absent from source code and configuration committed to version control? Are random values for tokens produced by a cryptographically secure generator? Does the code avoid inventing its own encryption scheme?
A05 Injection
Injection attacks happen when untrusted input is interpreted as part of a command or query. Review every sink where strings are assembled. SQL injection prevention. The core rule is that data never becomes part of query structure. Look for string concatenation or formatting inside query text. java // Risky: user input becomes part of the SQL text String q = SELECT * FROM users WHERE name = ' + name + '; javahttps://www.appsecmaster.net/en/labs/sql-injection // Safer: placeholders keep data separate from the query PreparedStatement ps = conn.prepareStatement( SELECT * FROM users WHERE name = ?); ps.setString(1, name); Stored procedures and ORMs do not automatically protect you. Raw query helpers and dynamically built sort or filter clauses are common weak spots. If your reviewers need practice recognizing these patterns, the SQL injection lab offers realistic targets. CrossSite Scripting (XSS). Check that output is encoded for the context where it appears: HTML body, attribute, script block, URL or style. Flag any use of rawHTML rendering functions, direct assignment to inner HTML properties and template features that disable automatic escaping. Handson exercises in the crosssite scripting XSS lab help reviewers learn which contexts need which encoding.Other interpreters. Command execution, file path construction, template engines, LDAP filters and XML parsers all deserve the same question: could input change the meaning of the command?
A06 Insecure Design
Design flaws are visible in code only if you know the intended behavior, so ask about intent.
Checklist prompts
Is there a limit on how often sensitive operations such as login, password reset or code verification can be attempted? Can business rules be bypassed by calling steps out of order? Are quantities, prices and discounts validated on the server? Was a threat model or design discussion recorded for this feature?
A07 Authentication Failures
Checklist prompts
Are session identifiers regenerated after login and invalidated on logout? Are cookies marked secure, HTTPonly and with an appropriate same site policy? Does the password reset flow avoid revealing whether an account exists and use singleuse, expiring tokens? Is multifactor authentication enforceable for privileged accounts? Are token signatures actually verified rather than merely decoded? A08 Software or Data Integrity Failures
Checklist prompts
Is data from untrusted sources deserialized with unsafe, general purpose object deserializers? Are updates, plugins and scripts loaded only after an integrity check? Can a client alter values the server later trusts, such as roles or prices stored in a cookie or hidden field?
A09 Security Logging and Alerting Failures
Checklist prompts Are logins, failures, permission denials and high value actions logged with enough context to investigate? Is sensitive data such as passwords and tokens excluded from logs? Is usercontrolled text sanitized before logging to prevent forged log lines? Does something alert a human when suspicious patterns appear?
A10 Mishandling of Exceptional Conditions Checklist prompts
When a check throws or times out, does the code deny access instead of continuing? Do error responses avoid exposing internal paths, queries or library versions? Are resources released and transactions rolled back when failures occur? Are empty values, oversized input and unexpected types handled deliberately?
A pattern worth flagging
javascript try { allowed = await policy.check(user, resource); } catch (e) { // swallowed: allowed keeps its default value } if (allowed !== false) { serve(resource); } If a failure leaves the variable undefined and the condition tests for not false, the resource is served when the policy engine is down. Defaultdeny is the safer design.
Secure Coding Practices That Make Reviews Easier
Good reviews are partly a function of how code is written. Teams that adopt a few shared secure coding practices find that checklists catch fewer problems because there are fewer to catch. Centralize security decisions. One authorization helper, one encoding library and one query layer beat dozens of ad hoc versions. Prefer safe defaults. Frameworks with automatic escaping, parameterized data access and built-in anti forgery support turn the secure path into the easy path. Validate at the boundary. Reject malformed input early with explicit allow lists for formats, lengths and types. Keep secrets out of code. Use a secrets manager and rotate credentials on a schedule. Write security tests. A unit test asserting that user A cannot read user B's record is a permanent regression guard. Make findings teachable. Link each review comment to a short explanation so the same issue is not repeated.
Where Tools Fit Into the Checklist
Automated scanners are valuable for catching known patterns at scale, such as risky function calls, vulnerable dependencies and missing headers. They are weak where the checklist is strongest: ownership checks, workflow abuse and failopen logic. A reasonable division of labor is to let tools handle breadth and let reviewers handle meaning. The tradeoffs are covered in detail in our comparison of manual code review vs automated code review.To turn this material into a team standard, combine it with a broader process document such as our code review checklist and best practices, which covers reviewer etiquette, pull request size limits and ownership of followups.
Building Reviewer Skill With Practice
Checklists tell you what to look for; practice teaches you what it looks like. Reviewers who have exploited a flaw themselves recognize it faster in unfamiliar code. Attackside exercises such as the web application hacking labs build that intuition and timed web security CTF challenges turn it into a skill you can test. A monthly session where reviewers swap a vulnerable snippet and race to find the flaw is a cheap, effective habit.
Conclusion
A practical OWASP Top 10 checklist for code review does not try to teach every vulnerability. It gives reviewers a short list of questions per category, a method for tracing untrusted data and a quick reference table for the moment a diff looks suspicious. Start with the categories most relevant to your product, pilot the checklist on a handful of pull requests and adjust it based on what reviewers actually find.Pair the checklist with shared secure coding practices, regular handson exercises and the right balance of automated and manual review and security stops being a latestage gate and becomes part of everyday engineering. To build that skill across your team, explore the realistic labs and challenges at AppSecMaster and practice finding these flaws before attackers do.
Frequently Asked Questions (FAQs)
What should an OWASP Top 10 checklist include?
It should include one or more review questions for each of the ten categories, a way to trace untrusted input to sensitive sinks, guidance on severity and a place to record the category name on each finding so reviewers and managers can spot patterns over time.
How long does a security focused code review take?
It depends on size and risk. For a small change touching authentication or data access, thirty to sixty focused minutes is common. Keeping pull requests small and scoping by risk, rather than reading every file equally, keeps the effort manageable.
Can a scanner replace a manual security code review?
No. Scanners find known patterns quickly but struggle with business logic, ownership checks and design flaws. The strongest approach combines automated scanning for breadth with manual review for context dependent categories such as access control and insecure design.
How do I prevent SQL injection during code review?
Look for string concatenation or formatting inside query text and require parameterized queries or safe ORM methods instead. Also inspect dynamic sort and filter clauses, which often bypass parameter binding and confirm that database accounts have the minimum privileges they need.
Where do XSS and CSRF fit in the OWASP Top 10?
CrossSite Scripting is part of the Injection category, because untrusted input ends up interpreted by the browser. CrossSite Request Forgery weaknesses are tracked under Broken Access Control in recent editions. Both still deserve explicit checklist items.
welcome to Insurances.net (https://www.insurances.net)
