Ecto的fragment存在SQL注入风险 如何确保其查询参数化安全？

首先你提到的case_when宏写法是安全的，不存在绕过安全限制的问题：它的fragment第一个参数是硬编码的固定SQL模板，所有动态内容都通过?占位符作为后续参数传入，Ecto会自动对这些参数做预编译处理，完全避免SQL注入风险。

关于fragment的安全使用和参数化保证，核心规则如下：

• fragment的第一个参数必须是硬编码的字符串字面量，绝对不要使用变量、动态拼接字符串、插值字符串作为首参数。Ecto的编译报错就是为了拦截这类高风险写法，避免开发者不小心把用户可控的内容拼接到SQL模板中。
• 所有动态查询值（比如条件判断的匹配值、用户输入的查询参数）全部通过?占位符作为fragment的后续参数传入，Ecto会自动将这些值做参数化处理，不会直接拼接到SQL语句中。
• 如果要封装通用SQL片段（比如CASE WHEN、EXISTS等常用子句），就参考你举例的case_when宏写法：把固定SQL模板硬编码在宏内部，动态的条件、返回值全部通过占位符传递，这类封装是合理的安全用法，不存在绕过安全防护的问题。

如果确实有动态表名、动态字段名的需求，不要直接把用户输入的内容拼接到SQL模板中，要先对动态的表名/字段名做白名单校验，确认属于允许的取值范围后再使用，避免注入风险。

错误用法示例（有注入风险/会触发编译报错） #

# 错误：首参数使用了带插值的动态字符串，用户如果可控`input_table`的取值就会造成注入
dynamic_sql = "SELECT 1 FROM #{input_table} WHERE id = ?"
fragment(dynamic_sql, ^user_id)

正确用法示例（安全参数化） #

# 固定SQL模板，动态值走占位符
fragment("SELECT 1 FROM users WHERE id = ?", ^user_id)

# 确实需要动态表名的场景，先做白名单校验
allowed_tables = ["users", "posts", "comments"]
if input_table in allowed_tables do
  # 表名已经过白名单校验，此时再使用是安全的
  fragment("SELECT 1 FROM #{input_table} WHERE id = ?", ^user_id)
end

内容的提问来源于stack exchange，提问作者SDReyes