filter() 和 filter_by() 为什么默认安全
因为它们不拼 SQL 字符串，而是构造表达式树，最终由 SQLAlchemy 方言生成带占位符的预编译语句（如 WHERE name = %s），用户输入作为独立参数传给数据库驱动，完全隔离于 SQL 结构。
常见错误是误以为“用了 ORM 就万事大吉”，结果在 filter(User.name.like(f"%{q}%")) 里用 f"" 提前拼接——like() 方法本身不接管参数化，f-string 已在 Python 层完成字符串注入，数据库收到的就是恶意语句。
-
filter_by(username=request.args.get("u"))安全：仅支持硬编码字段名 + 等值匹配 -
filter(User.status == request.args.get("status"), User.created_at > now)安全：所有值走绑定参数，包括None、datetime、数字 - 避免
filter(User.name.like("%" + q + "%"))或filter(text("name LIKE '%s' % q"))—— 这两类都绕过 ORM 防护
text() 原生 SQL 必须配合命名占位符和字典传参
一旦用 text()，SQLAlchemy 就放弃语法解析，只负责把字符串发给数据库。安全与否，全看你怎么塞参数。
错误写法直接把变量插进字符串：text(f"SELECT * FROM users WHERE id = {user_id}")，攻击者输 1 OR 1=1 就查出全表；text("SELECT * FROM users WHERE name = '" + name + "'") 同理，引号闭合后任意注入。
- 正确写法必须用
:param占位符 + 字典传参：text("SELECT * FROM users WHERE name = :name AND status = :status")，然后session.execute(stmt, {"name": name, "status": "active"}) - 占位符冒号不能省：
?name或%s在text()中无效，PostgreSQL/MySQL 驱动只认:name - 禁止用元组传参：
session.execute(stmt, (name, status))易错位；也别用**locals()，键名可能不匹配或污染
表名、列名、ORDER BY 字段这些无法参数化，必须白名单校验
SQL 结构（比如 FROM users、ORDER BY created_at）在解析阶段就决定执行计划，数据库协议根本不允许把它们当参数传——这不是 SQLAlchemy 的限制，是 SQL 协议本身的硬约束。
典型翻车场景：前端传 ?sort=name%20ASC;DROP TABLE users--，后端直接 order_by(request.args.get("sort"))，结果生成 ORDER BY name ASC;DROP TABLE users--。
- 排序字段白名单：
if sort_field not in ["id", "created_at", "username"]: raise ValueError("Invalid sort field") - 动态列查询：
getattr(User, field)前先检查field in User.__table__.columns.keys() - 多模型路由：
model_map = {"user": User, "post": Post}，再取model_map.get(table_name)，绝不用globals()[table_name]
db.session.execute() 的两种调用方式风险天差地别
很多人以为只要用了 db.session.execute() 就算“走 ORM 流程”，其实它只是个执行入口，底层是否参数化，取决于你传进去的是什么。
危险信号：ProgrammingError: syntax error at or near "OR" 或页面报错里泄露数据库字段名——说明用户输入已作为 SQL 片段被执行。
- 安全更新方式一（ORM 对象）：
user = User.query.get(user_id); user.status = "active"; db.session.commit() - 安全更新方式二（原生 SQL）：
db.session.execute(text("UPDATE users SET status = :status WHERE id = :id"), {"status": "active", "id": user_id}) - 绝对禁止：
db.session.execute("UPDATE users SET status = '{}' WHERE id = {}".format(status, user_id))—— 这行代码跟 raw DB-API 拼接没区别，ORM 安全机制完全失效
真正容易被忽略的点是：动态字段名校验必须在 SQL 构建前完成，而不是等 execute() 报错才拦截；白名单不是可选项，是 SQL 元信息操作的强制前置步骤。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
