Last updated: April 29, 2026
Injection bugs — SQL, OS command, LDAP, NoSQL, XPath, template engines — are not about “bad input validation.” They’re about mixing two languages in one string and letting the attacker supply a mix that changes the grammar. Once you see injection as a grammar problem rather than an input problem, every class of injection becomes the same idea with different syntax.
Why this happens
Developers use string concatenation because it’s the fastest way to build a command. "SELECT * FROM users WHERE id=" + user_id feels natural; it reads like English. But what the database parses is not “a query plus an ID” — it’s one string that the database tokenizes into tokens. If the attacker controls enough of the string to inject tokens of their own, the grammar of the original query changes.
The root assumption is: “I know what SQL I’m writing because I wrote it.” The truth is: the database only knows what SQL it was handed. The user has written part of the SQL by being part of the string.
Parameterized queries (prepared statements) break the injection class because they send the query template and the parameters separately. The database parses the template once, binds parameters second. The parameters cannot become tokens. String concatenation merges the two, and the defence collapses.
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.