Entity Framework Extensions Is Entity Framework Extensions SQL Injection Safe?

The short answer: Yes.

The long answer: No library is 100% SQL injection safe if you open the door yourself.

Even queries generated by EF Core can become unsafe if, for example, you use an interceptor and replace part of the query with raw user input. At some point, no library can protect you if you deliberately create the vulnerability.

⚠️ Quick Answer By default, Entity Framework Extensions is safe. SQL injection is only a risk if you misuse advanced Formula/Sql options with raw user input.

Why do some tools report Entity Framework Extensions?

These are false positives.

Static analysis tools often flag any option that can accept raw SQL, even if it’s never used unsafely.

Our library does replace strings in templates, concatenates column names, etc. — but that does not mean it is unsafe. We escape table names, column names, and other identifiers. The warnings you see are usually because scanners detect features that could be misused, not because the library builds queries insecurely by default.

Are there options that can be vulnerable?

Yes, but they are clearly marked and must never be used with raw user input.

These options have a Formula or Sql suffix and include a warning in the docs. They exist for advanced scenarios where expressions or property references are not enough.

For example, MatchedAndFormula lets you hardcode a SQL fragment directly. That gives you maximum flexibility, but it also shifts responsibility to you, the developer, to avoid injecting unvalidated data.

It’s also important to note that these options are hardcoded by the developer. They are not designed to accept user input, and in most cases it wouldn’t even make sense to pass user data directly into them. The only way they can become unsafe is if a developer explicitly misuses them.

// @nuget: Z.EntityFramework.Extensions.EFCore

// ✅ Safe (hardcoded condition)
options.MergeMatchedAndFormula = "Price > 100";

// ❌ Unsafe (user input directly injected)
options.MergeMatchedAndFormula = $"Price > {userInput}";

Here is the full list:

• Bulk Insert

  • InsertNotMatchedAndFormula
  • InsertPrimaryKeyAndFormula
  • InsertStagingTableFilterFormula

• Bulk Update

  • UpdateMatchedAndFormula
  • UpdatePrimaryKeyAndFormula
  • UpdateStagingTableFilterFormula

• Bulk Delete

  • DeleteMatchedAndFormula
  • DeletePrimaryKeyAndFormula
  • DeleteStagingTableFilterFormula

• Bulk Merge

  • MergeMatchedAndFormula
  • MergeNotMatchedAndFormula
  • MergePrimaryKeyAndFormula
  • MergeStagingTableFilterFormula

• Bulk Synchronize

  • SynchronizeDeleteDestinationTableFilterFormula
  • SynchronizeMatchedAndFormula
  • SynchronizeNotMatchedAndFormula
  • SynchronizeSoftDeleteFormula
  • SynchronizePrimaryKeyAndFormulaDelete
  • SynchronizePrimaryKeyAndFormulaMerge
  • ColumnSynchronizeDeleteKeySubsetFormula

• Misc

  • QueryFilterPrimaryKeyAndFormula
  • QueryHint
  • TableHintSql

• Oracle-specific

  • OracleDeleteTableHintSql
  • OracleInsertTableHintSql
  • OracleMergeInsertTableHintSql
  • OracleMergeUpdateTableHintSql
  • OracleSelectInsertIfNotExistsTableHintSql
  • OracleUpdateTableHintSql

Conclusion

Entity Framework Extensions is SQL injection safe by default. All queries generated by the library escape identifiers such as table names and column names.

The only exceptions are the advanced Formula and Sql options, which deliberately let you inject raw SQL for scenarios where expressions or column references are not enough. These options are meant to be developer-controlled and hardcoded — they are not built to accept user input, and using them that way usually doesn’t even make sense.

• If you never use them → ✅ there’s no risk.
• If you use them with only hardcoded SQL → ✅ still safe.
• If you use them with raw user input → ❌ you create the risk yourself.

In short: the library gives you flexibility — but the responsibility is yours.