Django原生SQL查询防止SQL注入的实践方法

在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())

cursor.execute() 也得严格参数化

绕过ORM直接用connection.cursor()时，Django不提供任何防护，完全依赖底层驱动的参数化能力。

• 必须用cursor.execute("SELECT * FROM user WHERE id = %s", [user_id])
• 禁止cursor.execute(f"SELECT * FROM user WHERE id = {user_id}")或"%s" % user_id
• 不同数据库占位符不互通：MySQL/SQLite用%s，PostgreSQL支持%s和%(name)s，但混用会导致迁移失败
• 如果涉及多数据库部署，统一用位置参数%s最保险

这里必须强调一点：结构化参数永远不被保护——表名、字段名、ORDER BY、GROUP BY、函数名这些，哪怕你用params=也救不了。它们不属于“值”，而是SQL语法骨架，必须靠白名单校验或静态定义兜底。这才是在Django中安全执行原生SQL的真正底线。