sequelize 安全核心在于参数化绑定与白名单校验：字段定义不防注入，where 中值自动绑定；列名/表名等 sql 结构位置必须白名单校验，literal/fn/sequelize.query 拼接即破防。
Model.init() 里字段定义不防注入，但能帮你在 where 层守住边界
模型定义本身不参与 SQL 构建，Model.init() 只是告诉 Sequelize “这张表长什么样”，它不会自动过滤或转义用户输入。真正起防御作用的是后续查询时如何使用这些字段——比如 where: { email: req.query.email } 这种写法，Sequelize 才会把 req.query.email 当作独立参数绑定。
不过，字段定义里的 validate 和 type 能间接提升安全性：
-
type: DataTypes.STRING会让 Sequelize 在参数化时按字符串类型绑定，避免数字上下文误解析 -
validate: { isEmail: true }是运行时校验，不能替代参数化，但可提前拦截明显畸形输入（如admin'--） -
allowNull: false配合NOT NULL约束，防止空值绕过逻辑判断，但和注入无直接关系
别在 attributes 里塞动态列名，白名单校验必须做在 Controller 层
attributes 选项本身安全，只要别让它变成攻击入口。常见错误是把 req.query.sortBy 直接塞进 [[req.query.sortBy, 'alias']] ——列名无法参数化，拼进去就等于执行任意字段引用。
正确做法是 Controller 层先过白名单：
- 定义允许的排序字段：
const allowedSortFields = ['id', 'name', 'created_at'] - 取值前校验：
const sortField = allowedSortFields.includes(req.query.sortBy) ? req.query.sortBy : 'id' - 再传给查询：
attributes: [[sortField, 'sort_value']]
注意：白名单必须硬编码，不能从数据库读、不能用正则“过滤单引号”，攻击者早就能绕过。
findAll/update/destroy 这些方法默认走预编译，但 fn() 和 literal() 一用就破防
Model.findAll()、Model.update()、Model.destroy() 全部默认启用参数化，无需额外配置。它们的安全性只被三件事破坏：
- 在
where或attributes里调用literal(req.query.xxx)——literal()的设计就是“原样输出”，不加引号、不转义、不绑定 - 用
fn('LOWER', literal(req.query.q))包用户输入 —— 函数包装不改变 literal 的危险本质 - 把用户输入当列名用，例如
where: { [req.query.field]: req.query.value }—— 方括号属性名是 JS 语法，但最终生成的 SQL 里它就是裸字段名
真正该检查的不是“有没有调用 validate”，而是“这个变量是否出现在 SQL 结构位置（列名、表名、ORDER BY）还是纯值位置”。前者必须白名单，后者交给 Sequelize 绑定即可。
sequelize.query() 是唯一需要你手动选绑定方式的地方
所有模型方法都屏蔽了底层细节，但 sequelize.query() 把选择权交给你。它不强制任何方式，但只有两种写法真正安全：
- 用
replacements+ 命名占位符：sequelize.query("SELECT * FROM users WHERE status = :status", { replacements: { status: req.body.status } }) - 用
bind+ 位置占位符：sequelize.query("SELECT * FROM users WHERE id = ?", { bind: [req.params.id] })
以下全是危险操作：
- 模板字符串插值：
`SELECT * FROM users WHERE name = ${req.body.name}` - 字符串拼接：
"SELECT * FROM users WHERE id = " + req.params.id - 混用占位符：
:status和?出现在同一个查询里（会报错且不可预测）
最常被忽略的一点：哪怕你只在 sequelize.query() 里用了 1 次拼接，整条查询就失去参数化保护——没有“部分安全”这回事。
