In Entity Framework Core, FromSql and FromSqlInterpolated are safe against SQL injection because they always send values as separate SQL parameters. FromSqlRaw can be vulnerable if used improperly, because it lets you insert variable text directly into the SQL string.
The interpolation that is not just interpolation
This looks like ordinary C# string interpolation:
var user = "johndoe";
var blogs = await context.Blogs
.FromSql($"EXECUTE dbo.GetMostPopularBlogsForUser {user}")
.ToListAsync();
Microsoft's documentation explains that the supplied value is wrapped in a DbParameter and the generated parameter name is inserted at the placeholder. That is what makes FromSql safe, and it also sends the value efficiently and correctly to the database. FromSql arrived in EF Core 7.0. On older versions, use FromSqlInterpolated.
Where it goes wrong
The danger is converting the interpolated string to a regular string before the call. If you build the text first, with concatenation or a normal string variable, EF no longer sees the values separately.
// Unsafe: the string is built before EF sees it
var sql = "SELECT * FROM Blogs WHERE Url = '" + userUrl + "'";
var blogs = context.Blogs.FromSqlRaw(sql);
FromSqlRaw takes a string and optional parameters. Used with proper SqlParameter objects, it is safe for those values. Used with concatenated text, it is not.
Dynamic column names
The docs note that databases do not allow parameterizing column names or any other part of the schema, so this does not work as intended:
.FromSql($"SELECT * FROM [Blogs] WHERE {propertyName} = {propertyValue}")
If you decide you need dynamic SQL, the docs say to use FromSqlRaw, and that it is then your responsibility to make the inserted string safe, by detecting special characters such as semicolons and comments and either escaping or rejecting them. Values can still go through a DbParameter. Microsoft also suggests that, unless the case is truly dynamic, two queries for two column names are usually better than parameterizing one.
For a fixed allowlist approach see prepared statements and what they cannot bind.
Related methods
The same pattern applies to ExecuteSql and ExecuteSqlRaw for commands, and SqlQuery and SqlQueryRaw for scalar and unmapped results. The non raw versions parameterize interpolated values. The raw versions allow dynamic construction.
Review checklist
- Search for
FromSqlRaw,ExecuteSqlRawandSqlQueryRaw. - For each, ask where each interpolated or concatenated part comes from.
- Prefer the non raw method when only values vary.
- Use an allowlist when identifiers vary.
Safeguard's dependency scanning covers the NuGet packages in your solution, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Is FromSql with an interpolated string vulnerable?
Not when you pass the interpolated string directly. EF turns each value into a parameter.
Is FromSqlRaw always unsafe?
No. It is safe for values passed as parameters. It is risky when untrusted text is placed in the SQL string itself.
Sources
Last reviewed: 19 October 2026.
