在 Rails 7 里，Active Record 默认确实能挡住一部分 SQL 注入风险。但前提很明确：只对参数化查询有效。

一旦用了字符串插值、动态字段名，或者涉及 order/group/ha ving、find_by_sql、connection.execute 这些场景，就不能再掉以轻心了。

必须手动做白名单校验，或者直接改用更安全的接口。

Active Record 在 Rails 7 中默认防 SQL 注入，但只对参数化查询生效。

你不需要额外配置，真正起作用的是你写查询时有没有绕过绑定机制。

核心原则

Rails 7 的默认防护不是万能的。只有在使用参数化查询时，这层防护才会生效。

如果绕过了绑定机制，防护就等于失效。

where 和 find_by 必须用参数化写法

这两者语义不同，但防注入逻辑一致。

必须走问号占位符、哈希或命名绑定。字符串插值会完全跳过 ActiveRecord 的防护层。

• User.where("email = AND active = ", params[:email], true) —— 顺序绑定，最通用
• User.where(email: params[:email], active: true) —— 哈希写法，自动处理字段名和值，推荐用于简单等值条件
• User.find_by("email = :email", email: params[:email]) —— 命名绑定可行，但不如哈希直观
• User.find_by("email = '#{params[:email]}'") —— 禁止。加了 strip 或正则也拦不住注入

order/group/ha ving 动态字段必须白名单校验

order 本身并不支持 这类占位符。

因此，像 User.order("#{params[:sort]} #{params[:dir]}") 这样的写法，风险非常高。

更关键的是，Active Record 不会替你检查字段名是否有效。

最后这道关卡只能由业务代码自己把住。

• 方向白名单：%w{asc desc}.include(params[:dir]) params[:dir] : "desc"
• 字段白名单更健壮的做法是用 User.column_names 动态生成：User.column_names.include(params[:sort]) params[:sort] : "id"
• 别依赖 ActiveRecord::Base.sanitize_sql_for_order，它不校验字段是否存在，只做基础转义

find_by_sql 和 connection.execute 绝对不能拼接用户输入

这些方法绕过 ActiveRecord 全部防护，传入的字符串会被原样交给数据库驱动执行。

Ruby 插值发生在参数化之前，根本没有转义机会。

• User.find_by_sql("SELECT * FROM users WHERE name = '#{params[:name]}'") —— 直接裸奔
• ActiveRecord::Base.connection.execute("UPDATE users SET status = '#{params[:status]}'") —— 同样危险
• 正确做法只保留三种参数化形式：find_by_sql 传数组、connection.execute 配合 sanitize_sql、或直接用 where/update 等安全接口

强参数（Strong Parameters）本身不防 SQL 注入

它只过滤控制器参数，不负责 SQL 安全。

若没配好白名单，你会被迫退回到字符串拼接逻辑。这才是真正的突破口。

• params.require(:user).permit(:email, :name, :status) 确保你能放心写 User.where(user_params)
• 但 params[:sort] 这类动态字段名无法被 permit 放行，必须单独白名单校验
• 一旦因参数未被允许而 fallback 到 "WHERE #{...}" 拼接，注入就发生了

最容易被忽略的风险点

字段名、排序方向、分组依据这些“SQL 结构”从不参与参数化。

它们必须靠代码逻辑拦截，而不是指望框架自动兜底。