SQL injection and parameterised queries

When user input is glued into SQL text, input can change the query’s meaning. Parameters keep data as data.

Time O(1)Space O(1)Code C#

Watch it animatedStep through it, with the running line highlighted. Free with an account.

The idea

The database parses the SQL text into a plan. If untrusted input is concatenated into that text, input containing quote characters and SQL keywords can rewrite the plan. With parameters, the plan is parsed first and the input is bound later as a plain value, so it can never become code.

Code

// Vulnerable: input becomes part of the SQL text
var sql = "SELECT * FROM Users WHERE Email = '" + email + "'";
// Safe: the query shape is fixed, the value is sent separately
using var cmd = new SqlCommand(
    "SELECT * FROM Users WHERE Email = @email", conn);
cmd.Parameters.AddWithValue("@email", email);
// EF Core LINQ queries are parameterised for you

Tips

Fix: parameterised queries or an ORM, never string building, even for "trusted" input.
Defence in depth: least-privilege database accounts and input validation.
Stored procedures are only safe if they don’t build dynamic SQL inside.

In the .NET library

EF Core turns LINQ into parameterised SQL. FromSqlInterpolated parameterises too; avoid FromSqlRaw with string concatenation.