Sign in to track progress and bookmarks.
SQL Injection is the #1 database security threat. It occurs when an attacker "Injects" malicious SQL code into your query via a user input field. Even with modern ORMs like Entity Framework, you can still be vulnerable if you use **Raw SQL** incorrectly.
Never concatenate strings: "SELECT * FROM Users WHERE Name = '" + userInput + "'". Always use Parameters. Parameters treat the input as **Data**, not as **Code**, making it impossible for the attacker's SQL to ever execute.
Sometimes you NEED to build SQL dynamically (e.g., a search screen with 20 optional filters). Using EXEC(@sql) is extremely dangerous. You must use sp_executesql, which allows you to pass parameters into your dynamic string safely.
-- SAFE Dynamic SQL
DECLARE @sql NVARCHAR(MAX) = N'SELECT * FROM Users WHERE Id = @Id';
EXEC sp_executesql @sql, N'@Id INT', @Id = 5;Q: "Can SQL Injection still happen if I only use Stored Procedures?"
Architect Answer: "Yes! This is a common myth. If your Stored Procedure internally builds a dynamic SQL string using string concatenation and then calls `EXEC()`, you are still 100% vulnerable. A Stored Procedure is just a container; it doesn't automatically protect you unless the code *inside* the procedure is also following best practices for parameterization."
Quizzes linked to this course—pass to earn certificates.
On this page
1. The Fix: Parameterization 2. Dynamic SQL Hazards 4. Interview Mastery