sql注入漏洞源于直接拼接用户输入到sql字符串，无论是否使用flask-sqlalchemy；安全前提是sql静态+变量参数化，字段名等结构元素须白名单校验。
直接拼接 request.args 到 SQL 字符串就是漏洞本身
只要看到 f"WHERE name = '{name}'"、"WHERE id = {}".format(user_id) 或 "'%s'" % name 这类写法，不管有没有用 Flask-SQLAlchemy，漏洞已经存在。数据库驱动不会解析你拼出来的字符串，它只执行整条语句——攻击者输入 ' OR 1=1 -- 就能绕过条件、拖库、删表。
常见错误现象：
- 接口返回了不该返回的记录（比如管理员账号）
-
sqlalchemy.exc.ProgrammingError报错里出现字段名或表名（说明用户输入已进入结构层） - 页面空白但日志里有
sqlite3.OperationalError: near "OR": syntax error
text() 不等于“可以随便写 SQL”，它只是个裸通道
text() 本身不防注入，它只是把字符串原样交给数据库。安全的前提是：SQL 字符串必须静态、所有变量必须走参数绑定。
错误写法：
-
text(f"SELECT * FROM users WHERE name LIKE '%{q}%'")—— 变量提前插进字符串，text()完全失效 -
text("ORDER BY " + sort_field)—— 字段名无法参数化，必须白名单校验 -
db.session.execute(text(sql_str), {"id": user_id})但sql_str是拼出来的 —— 绑定参数没用，SQL 已被污染
正确写法：
db.session.execute(text("SELECT * FROM users WHERE name LIKE :pattern"), {"pattern": f"%{q}%"})-
db.session.execute(text("SELECT * FROM users ORDER BY :field").bindparams(field=sort_field))不行 ——bindparam()不能用于字段名/表名，得先白名单判断：if sort_field not in ["created_at", "username"]: raise ValueError
ORM 查询安全 ≠ 所有查询都安全，filter() 外全是雷区
session.query(User).filter(User.name == name) 安全，因为 ORM 构建表达式树，底层转成带占位符的语句；但一旦跳出这个模式，防护就消失。
容易踩的坑：
-
extra()和raw()：完全绕过 ORM，必须用params=传参，且不能拼字符串 -
Q对象里用eval(request.GET.get("q_expr"))：等于把 Python 解释器钥匙交出去 -
filter(**{field_name: value})：若field_name来自用户输入（如request.args.get("sort_by")），可能触发User.is_staff__gt等非预期字段访问
安全做法：
- 字段名动态化时，强制白名单：
allowed_fields = {"id", "name", "email"}，不在其中就 fallback 到默认值 - 复杂条件用
and_()、or_()拼表达式，别拼字符串
RequestParser 和类型转换不是 SQL 注入防火墙
RequestParser 只负责从请求里取值、转类型、做基础校验（比如 type=int），但它拦不住绕过它的请求。攻击者可以直接发 raw body、删掉 Content-Type、用 curl 伪造参数。
所以：
- 即使
parser.add_argument("id", type=int)，后续仍必须用filter(User.id == user_id)或execute(..., (user_id,))，不能拼字符串 -
required=True和choices=["a","b"]能减少脏数据流入，但不能替代参数化查询 - 对
headers、cookies、url path里的值同样要走参数化——它们和args一样不可信
最常被忽略的一点：表名、字段名、排序方向（ASC/DESC）、LIMIT 偏移量这些“结构元素”，没法参数化，只能靠硬编码或白名单。哪怕 SQL 语句里只剩一个 {sort_field} 没校验，整条语句就失守。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
