首页 > 数据库 >Python Django原生SQL查询如何防SQL注入？

Python Django原生SQL查询如何防SQL注入？

来源：互联网 2026-07-12 08:38:11

python资讯合集

Django原生SQL防注入需遵循：raw()必须用params传参且仅支持%s占位符，禁止字符串拼接；extra()的where参数绑定params；RawSQL混入用户输入需手动参数化；cursor.execute()严格参数化。结构化参数（如表名、字段名）不受参数化保护，需白名单校验。

在Django中执行原生SQL时，防SQL注入的规则其实很明确：raw()必须用params=传参，而且只认%s占位符，绝对不能用字符串拼接；extra()的where等参数同样靠params绑定；RawSQL混入用户输入必须手动参数化；至于字段名这类结构化参数，参数化机制根本救不了，只能靠白名单校验。这几个点，一个都不能含糊。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

raw() 必须用 params= 传参，不能拼字符串

Django的raw()完全绕过了ORM编译器，SQL字符串由你全权负责。只要出现"%s" % user_input或f"WHERE name = '{name}'"，就等于把数据库钥匙递出去了。

raw()只认位置占位符%s，所有后端（PostgreSQL、MySQL、SQLite）都兼容；命名参数如%(name)s在SQLite下会直接报错
params必须是列表或元组，不能是字典——除非你明确只跑PostgreSQL且确认驱动支持
错误示例：User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{username}'")
正确写法：User.objects.raw("SELECT * FROM auth_user WHERE username = %s", params=[username])

extra() 的 where 参数不自动转义，必须走 params

extra()看似像filter()，但它内部的where、tables、joins都是原始字符串拼接点，不经过任何参数化处理。

extra(where=["status = %s"], params=[user_status])是唯一安全路径
extra(where=[f"status = '{user_status}'"])和裸写SQL没区别，直接触发注入
别试图用connection.ops.adapt_unknown_value()手动转义——难维护、易漏、不跨数据库
真需要动态条件，优先改用Q()组合，或提前定义好字段白名单映射

RawSQL 表达式里混用户输入必须手动参数化

RawSQL用在annotate()或filter()中时，它本身不继承外层QuerySet的参数化机制，params=只绑定它自己SQL内的占位符。

错误：annotate(score=RawSQL(f"CASE WHEN title LIKE '%{search}%' THEN 1 ELSE 0 END")) —— search被直接插进字符串
正确：RawSQL("CASE WHEN title LIKE %s THEN 1 ELSE 0 END", params=[f"%{search}%"])
LIKE模糊匹配还要额外注意通配符转义：用户输入的%、_会被数据库当语法执行，不算注入但属逻辑漏洞，需用escape参数或__icontains替代
更稳妥方案：优先用ORM原生表达式，比如Case(When(title__icontains=search, then=1), output_field=IntegerField())