Security & Performance
7 MIN READ

Written by

Akeem O. Salau (Brainwave)

Published

Jul 3, 2026

Code Crimes: The Book Every Developer Needs Before Their Next Code Review

Code Crimes: The Book Every Developer Needs Before Their Next Code Review

Most developers learn security and performance the hard way. A slow query causes an outage at 2 AM. A forgotten input validation check makes it into production. A password comparison written in five seconds takes three days to investigate after a breach. The mistakes are rarely exotic. They are usually familiar, seemingly harmless patterns that most of us have written at some point in our careers without realising the consequences sitting just underneath the surface.

Code Crimes: Security and Performance Mistakes in Modern Code is a book built around that reality. Not a textbook. Not a certification manual. A direct, practical catalog of the exact mistakes that appear in real codebases, written by developers who know their craft but haven't yet connected the pattern to the consequence. Every chapter shows the mistake, explains why it matters in production, and delivers the fix.

What Is Code Crimes?

Code Crimes is a technical book covering over 100 distinct security and performance mistakes across three of the most widely used programming languages in professional software development: Python, PHP, and JavaScript.

The book is structured in three parts:

Part 1: Python covers memory management mistakes, unsafe deserialization, command injection vulnerabilities, insecure use of built-in functions, and performance anti-patterns that look harmless in development but collapse under production load.

Part 2: PHP covers SQL injection, file upload vulnerabilities, session security mistakes, authentication bypasses, insecure cryptographic comparisons, object injection, and configuration errors that expose entire server environments.

Part 3: JavaScript covers prototype pollution, DOM-based cross-site scripting, unsafe use of eval and dynamic imports, event loop starvation, race conditions, supply chain vulnerabilities in npm dependencies, and client-side security mistakes that invalidate server-side protections.

Each crime follows the same format: the vulnerable code, the explanation of what it enables an attacker or an overloaded server to do, and the corrected implementation with the reasoning behind every change.

Who Is This Book For?

Code Crimes is written for working developers, not students. It assumes you already know how to write code. It is not going to explain what a function is or what SQL stands for. What it does is show you the gap between writing code that works and writing code that holds under pressure from real users, real traffic, and real attackers.

If you fall into any of the following categories, this book belongs on your desk:

Backend developers working in PHP or Python who have shipped production applications and want to understand the security surface of the patterns they already use daily.

JavaScript developers building Node.js APIs, React applications, or browser-side logic who want to understand how common JS patterns, prototype inheritance, dynamic imports, async patterns, localStorage become attack vectors or performance bottlenecks when the wrong assumptions are made.

Full-stack developers who are responsible for their own security decisions without a dedicated security team to catch mistakes before they go live.

Engineering leads and senior developers conducting code reviews who want a structured reference for the categories of mistakes worth flagging, not just stylistic opinions.

Self-taught developers who have strong practical instincts but no formal exposure to security thinking and want to fill that gap systematically without sitting through a certification course.

A Taste of What's Inside

Rather than describing the book in abstract terms, here is a concrete sample of the kind of content inside each of the three parts.

PHP - Crime #122: SQL Injection via String Concatenation

This is one of the oldest vulnerabilities in web development and one of the most persistent. The pattern looks like this:

$query = "SELECT * FROM users WHERE username = '" . $username . "'";

Typing admin' OR '1'='1 into the username field returns every user in the database. Typing admin'; DROP TABLE users; -- does exactly what it looks like. The fix is a single prepared statement that separates the query structure from the data entirely, making injection structurally impossible rather than just unlikely. The chapter covers not just the basic fix but the PDO configuration settings that developers routinely miss, the least-privilege database user setup that bounds the damage if something slips through, and how to log injection probe attempts for threat intelligence without slowing the request.

JavaScript - Crime #208: Prototype Pollution via Recursive Merge

This one surprises developers who consider themselves security-conscious. Sending {"__proto__":{"isAdmin":true}} as a JSON payload to an application using a naive deep merge utility does not just affect the object being merged. It modifies Object.prototype the blueprint every object in the entire running Node.js process inherits from. A brand new, completely unrelated empty object created after the attack has isAdmin: true. The chapter covers why the attack works at the JavaScript engine level, how to write a pollution-safe merge function, how to detect if your application has already been compromised by one, and how the --frozen-intrinsics Node.js flag closes the vector at the runtime level.

PHP - Crime #138: Loose Comparison for Token Validation

PHP's == operator performs type coercion before comparison. Certain MD5 and SHA hashes begin with 0e followed entirely by digits PHP interprets these as floating-point numbers in scientific notation, both equal to zero. If a stored password reset token happens to produce one of these "magic hashes" and an attacker submits the string 0, the comparison $storedToken == $userInput evaluates to true. The attacker resets the password without ever knowing the token. The fix is a single function call: hash_equals(), which performs a constant-time, type-safe comparison. The chapter explains why constant-time comparison matters for timing attacks, not just type juggling, and covers the complete secure token lifecycle from generation to single-use invalidation.

Why Three Languages in One Book?

The decision to cover Python, PHP, and JavaScript together was deliberate. Most security books pick one language or one domain. The reality of modern development is that many developers work across multiple languages in the same week, and the underlying vulnerability categories appear across all three with different syntax but the same root cause.

SQL injection is a PHP problem and a Python problem. Prototype pollution is a JavaScript problem, but insecure deserialization is a PHP and Python problem. Timing attacks affect authentication systems regardless of which language implements them. Understanding the pattern across contexts is what turns isolated fixes into a security mindset that transfers to any new tool or language a developer picks up.

What Makes This Different From Existing Security Books?

There is no shortage of security books. Most of them fall into one of two categories.

The first category is the comprehensive reference: exhaustive, technically thorough, and genuinely useful as a reference shelf item that you consult after a problem has already been identified. These books are valuable. They are not what you hand to a developer who needs to ship in three weeks and wants to make better decisions in the code they're writing right now.

The second category is the certification-oriented guide: structured around exam objectives, broad in coverage, shallow in implementation detail. These produce developers who can pass a test but are not always certain what to actually change in the code.

Code Crimes sits between these. It is implementation-first. Every chapter starts with code that runs, shows exactly what goes wrong with it, and delivers a production-ready replacement. The explanations exist to support the code, not the other way around. You can read a chapter in fifteen minutes and immediately apply it in the codebase you're working in today.

The "Crime" Format

The framing of each mistake as a "crime" is not just a title gimmick. It reflects a specific structure that appears in every chapter of the book:

The Crime - the vulnerable or inefficient pattern, shown as real runnable code with no artificial simplification.

The Impact - what the code enables: data exfiltration, authentication bypass, denial of service, memory exhaustion, or silent data corruption.

The Evidence - a concrete demonstration of the consequence, whether that is a working exploit, a response time measurement showing the performance degradation, or a heap profiling result showing unbounded memory growth.

The Fix - a production-ready implementation with every decision explained, not just the obvious change but the surrounding context that makes the fix robust rather than just technically correct.

This structure means every chapter is complete in itself. You do not need to read chapters sequentially to extract value. You can open the book on a specific crime that matches something you are looking at in a code review and get a complete, self-contained answer.

Get the Book

Code Crimes is available now on Amazon in both Kindle and paperback formats.

Get Code Crimes on Amazon.com

Get Code Crimes on Amazon.co.uk

Get Code Crimes on Amazon.fr

If you are purchasing for a team or engineering organization, the Kindle edition allows for individual purchases at scale. Several chapters also make strong material for internal code review training sessions, particularly the chapters on SQL injection, prototype pollution, and session fixation. These are the mistakes that appear most frequently in real pull requests and are the most understandable to developers who have not previously thought systematically about security.

A Final Word

Security is not a feature you add at the end of a project. Performance is not something you optimize after launch when users are already churning. Both are the product of specific decisions made at the code level, every day, by the developers writing the software. The difference between a vulnerable application and a secure one is almost always not a question of technical knowledge it is a question of whether the developer knew to look for the pattern in the first place.

Code Crimes is the book that teaches you to look.

code crimes bookphp security mistakesjavascript security vulnerabilitiespython security booksql injection phpprototype pollution javascriptweb application security bookdeveloper security trainingsecure coding bookperformance mistakes in code
Share this post:

The Author

Akeem O. Salau (Brainwave)

Akeem O. Salau (Brainwave)

Senior Engineer Software Engineering

Senior Software Engineer, SEO Expert, Entrepreneur & AI Expert building scalable products, optimizing visibility, and leveraging AI to solve real-world problems.

Comments (0)

Leave a Reply