SQL Injection Vocabulary

SQL injection happens when user-supplied input is concatenated directly into a SQL query string, letting an attacker embed extra SQL syntax, such as a stray quote followed by additional clauses, that changes what the query actually does, potentially bypassing authentication or exfiltrating unrelated data. Cross-site scripting instead injects a malicious script into a page rendered in a victim's browser, a different attack surface entirely. This direct-concatenation pattern is exactly what makes user input dangerous the moment it's treated as part of the query's own syntax rather than as pure data.

Parameterized queries, or prepared statements, send user input to the database as a separate, strictly-data parameter, so the database engine itself never interprets that value as part of the query's syntax, regardless of what characters it contains. Continuing to concatenate input directly into the query string leaves that separation entirely up to careful escaping, which is exactly the kind of manual defense that's historically proven unreliable. This parameter-versus-syntax separation is the single most effective, broadly recommended defense against SQL injection.

This is an incomplete, bypassable SQL injection defense, since stripping only single-quote characters ignores the many other ways an attacker can construct a working injection payload, depending on the database engine's own syntax quirks, encoding tricks, or numeric contexts that don't require a quote at all. A parameterized query is the actual robust defense, not this partial character-stripping approach. This is exactly why ad hoc input sanitization is considered fragile compared to parameterized queries, which remove the injection risk structurally rather than trying to filter out every possible dangerous pattern.

Using parameterized queries or prepared statements for every query built from user-supplied input ensures injected SQL syntax in a field like a username is always treated as inert data, never as part of the query's actual structure, which closes off exactly the attack described in this incident. Continuing to concatenate that field directly into the query string with no parameterization is precisely what let the attacker exfiltrate the entire user table. This parameterization requirement is a baseline, non-negotiable defense for any application accepting user input that eventually reaches a SQL query.

Manual escaping requires correctly anticipating every dangerous character, encoding, and database-specific syntax quirk that could let an attacker's input break out of its intended data context, and missing even one edge case reopens the injection vulnerability. Parameterized queries remove that ambiguity structurally, since the database driver itself keeps user-supplied values in a strictly separate data channel from the query's syntax, with no dependence on the developer correctly anticipating every attack variant. The tradeoff is essentially none here in terms of security, which is why parameterization, not escaping, is the industry-standard recommended defense.