Parameterised Queries and ORM-Safe Coding Patterns

If SQL injection is the disease, parameterised queries are the cure, and this lesson is about applying that cure correctly and consistently. A parameterised query separates the command's structure from its data, sending each over a different channel so input can never be interpreted as SQL. Understanding the mechanism turns it from a rule you follow into a guarantee you can reason about.

Analogy🏏Cricket

🍳 Think of it like cooking: A recipe can look flawless on paper, but a head chef only truly judges the dish by tasting the finished plate, because heat, timing, and the actual oven reveal problems the written method never shows. Just as tasting the cooked result catches what reading the recipe cannot, DAST probes the running application and catches the misconfigurations and runtime behaviour that reading the source cannot. This reveals DAST's stance: it judges the dish as it is actually served, not the recipe as it was merely written.

Modern applications rarely write raw SQL by hand; they use an Object-Relational Mapper or query builder. These tools parameterise by default, which is a major win, but they also expose raw-query escape hatches that reintroduce every risk if misused. The goal here is to make the safe path your default and to recognise the exact moments an ORM stops protecting you.

Analogy🏏Cricket

💰 Think of it like finance: A real audit that actually attempts a sample transaction proves beyond doubt whether a control can be bypassed, with little room for a false alarm, but it can only test the accounts and processes the auditors actually reach. Just as a hands-on audit yields high-confidence, low-false-positive results yet is bounded by what it examines, DAST yields high-confidence findings about real exploitability yet is bounded by the surface it can reach. This reveals its trade-off: what it confirms is solid, but it only confirms what it manages to touch.