Every API endpoint that builds a query, a shell command, or a rendered document out of a string it did not fully control has the same underlying defect: it cannot tell the difference between data the caller supplied and instructions the caller supplied, because both arrived as the same kind of text. A search endpoint that concatenates a customer's search term into a SQL statement is not trusting the customer to search politely — it is trusting the customer to never type anything that a SQL parser would interpret as a new clause, which is not a property any input validation rule can promise for arbitrary text.
This lesson treats SQL, NoSQL, command and template injection as four instances of one design failure rather than four unrelated bugs, because the fix is structurally identical across all four: keep the interpreter's grammar and the caller's data on separate channels, so the interpreter never has to guess which part of the incoming string was meant as code. A parameterised SQL query, a typed MongoDB filter object, a subprocess call given an argument list instead of a shell string, and a template engine that never evaluates caller-supplied text as a template are the same defence wearing four different names.
Analogy🏏Cricket
🏏 Think of it like cricket: A scorer at the ground has one job during a run-out appeal — record what the third umpire's replay actually shows, not what a fielder shouts from the boundary. If the scorebook simply wrote down whatever the loudest fielder claimed happened, a batting side's fielder could shout "not out" on a genuine dismissal and the record would reflect the shout, not the replay. The entire point of routing every close decision through the third umpire's review process, rather than trusting whoever speaks first on the field, is that the review process cannot be talked into recording something the replay does not actually show — it evaluates the frame-by-frame evidence on its own fixed rules, deaf to how confidently either side argues. A scoring system that instead let players narrate the outcome directly into the record would be exploitable by any player willing to shout with enough conviction. Just as the third umpire's review evaluates only the video evidence against a fixed rule set and never just accepts a fielder's spoken claim as fact, a database must evaluate only the query's fixed structure and treat the caller's input purely as data, never as an instruction it executes. Just as separating the appeal (a request for review) from the verdict (the umpire's own fixed process) prevents a shouted claim from becoming the official record, separating a query's structure from its data prevents a crafted input string from becoming part of the executed command. The insight is that any system which lets an untrusted party's words be recorded as the system's own decision has already lost the distinction between a request and an instruction, and injection is exactly that distinction collapsing.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.