A normal code review asks one question: does this work? A security review asks a harder one: how could someone abuse this? Same code, very different reading. You do not need to write software to understand what a reviewer looks for — and knowing the shape of it helps you tell a thorough team from one that just ships. Most of it maps to a well-known industry checklist, the OWASP Top 10, but here it is without the jargon.
Does it trust input it shouldn't?
Anything typed into a form, added to a web address, or sent from another system is untrusted until proven otherwise. When code takes that input and drops it straight into a database query or a page, attackers can smuggle in commands (SQL injection) or scripts that run in other users' browsers (cross-site scripting). A reviewer checks that every piece of input is validated and safely handled, everywhere — not just on the obvious fields.
Can a user reach what isn't theirs?
Signing in proves who you are; it does not decide what you are allowed to see. A common, serious flaw is when changing a number in a web address — an invoice ID, an account number — quietly shows you someone else's data. A reviewer tries exactly that, deliberately, on every screen that shows private information.
Are the keys left in the door?
Passwords, API keys, and access tokens should never sit inside the source code, yet they routinely do. A reviewer greps for secrets and checks they live in a proper secrets manager instead, where they can be rotated without a code change.
Is it built on cracked foundations?
Modern software leans on dozens of third-party libraries, and old versions accumulate publicly known holes. Reviewing your own code is not enough if a dependency you pulled in three years ago has a critical flaw. A reviewer checks what you depend on and whether it is current.
Does it leak when it breaks?
When something goes wrong, an error page that dumps technical detail — file paths, database structure, stack traces — hands an attacker a map. A reviewer checks that failures are logged privately and shown to users as plain, uninformative messages.
None of this is exotic. It is disciplined, slightly pessimistic reading of ordinary code — assuming the worst about how it will be used, and closing the gaps before someone else finds them.
It is also a fair thing to ask about before a project even starts — our guide to briefing a developer covers what to nail down up front, and whether a security review is part of the process belongs on that list. A review like this is one of the checks we build into every project we deliver — see our development services for how it fits into the wider build process.
Frequently asked questions
What's the difference between a normal code review and a security code review?
A normal review asks whether the code works; a security review asks how it could be abused. Same code, a different, more pessimistic reading.
What is the OWASP Top 10, and does a review just follow it?
It's a well-known industry checklist of the most common web-application vulnerabilities. Most of what a security reviewer checks maps to it, though a good review is a disciplined reading of the code rather than a box-ticking exercise against the list.
Why is untrusted input such a common problem?
Anything typed into a form, added to a web address, or sent from another system is untrusted until proven otherwise. When that input gets dropped straight into a database query or a page without validation, attackers can smuggle in commands or scripts — a reviewer checks every input is handled safely, not just the obvious fields.
Why do old third-party libraries matter if my own code is secure?
Modern software leans on dozens of third-party libraries, and old versions accumulate publicly known holes. Reviewing only the code you wrote isn't enough if a dependency pulled in years ago has a critical flaw still sitting unpatched.
Why shouldn't an error page show technical detail?
An error page that dumps file paths, database structure, or stack traces hands an attacker a map of your system. A reviewer checks that failures are logged privately and shown to users only as plain, uninformative messages.