Python编写Flask API如何防止SQL注入_使用参数化查询与ORM安全防护-Python教程-PHP中文网

拼接字符串执行sql必出安全问题，因攻击者可注入恶意代码；必须用参数化查询分离数据与语句，sqlite3用?或:name，psycopg2用%s或%(key)s，表名等动态部分需白名单校验。

python编写flask api如何防止sql注入_使用参数化查询与orm安全防护

Flask中用`sqlite3`或`psycopg2`执行SQL时，为什么拼接字符串必出问题

直接用f"SELECT * FROM users WHERE id = {user_id}"或"SELECT * FROM users WHERE name = '" + name + "'"，等于把数据库的钥匙塞给前端。哪怕user_id看着是数字，攻击者也能传1 OR 1=1 --进来，绕过条件、拖库、删表。

根本原因不是“没过滤”，而是SQL解析器会把拼进去的字符串当语句一部分执行——参数化查询强制让数据和语句分离，数据库只把占位符当值处理，不重新编译语法。

sqlite3必须用?或:name占位，不能用%s（那是Python字符串格式化，早于SQL解析）
psycopg2支持%s和%(key)s，但%s不是字符串插值，是驱动层转义后送进PostgreSQL的二进制协议参数
连ORDER BY或table_name这种无法参数化的字段，得白名单校验，不能靠escape_string()糊弄

SQLAlchemy ORM里`filter()`和`text()`的安全边界在哪

filter(User.name == name)是安全的，ORM自动转成参数化查询；但一旦写filter(text("name = '{}'".format(name)))，就退化回拼接陷阱。

常见误操作：用text()动态拼接排序字段、模糊搜索关键词、或带函数的条件（比如LOWER(name) = LOWER('{name}')）。这些看似灵活，实则绕过了ORM的防护层。

模糊搜索统一走like()方法：User.name.like(f"%{keyword}%")，它生成的是WHERE name LIKE ? + 参数
需要text()时，只用于固定结构SQL（如窗口函数），且所有变量必须用bindparam()注入，例如text("SELECT * FROM users ORDER BY :sort_field").bindparams(sort_field=bindparam("sort_field"))
execute()原生查询必须配session.execute(text(sql), {"param": value})，不能裸调session.execute(sql.format(...))

Flask-SQLAlchemy里`db.session.execute()`的两种写法风险差异

新手常以为用了Flask-SQLAlchemy就万事大吉，结果在db.session.execute("UPDATE users SET status = 'active' WHERE id = {}".format(user_id))里翻车——这行代码完全没走ORM参数机制，纯字符串拼接。

Python 3.14.2

Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。

下载

真正安全的写法只有两种：一是用ORM对象操作（user.status = "active"; db.session.commit()），二是用带参数的text()。

安全写法1：db.session.execute(text("UPDATE users SET status = :status WHERE id = :id"), {"status": "active", "id": user_id})
安全写法2：db.session.query(User).filter(User.id == user_id).update({"status": "active"})
危险信号：execute()里出现.format()、%、f-string、+拼接，基本可以判定有漏洞

为什么用`mysql-connector-python`时`%s`写法反而可能出错

MySQL官方驱动对参数占位符极其严格：%s只能用于值，不能用于表名、列名、LIMIT偏移量。有人试过"SELECT * FROM %s LIMIT %s"，第二个%s能参数化，第一个会直接报ProgrammingError: Wrong number of arguments。

更隐蔽的问题是，某些旧版驱动把%开头的字符串（如"%admin%"）误判为格式化指令，导致execute("SELECT * FROM users WHERE name LIKE %s", ["%admin%"])实际发出去的是LIKE '%admin%'还是LIKE '%%admin%%'，取决于驱动版本。

解决方案：表/列名用白名单映射，比如{"users": "users", "orders": "orders"}.get(table_arg, "users")
LIMIT参数必须转成int再拼，但仅限于你完全控制输入来源（如分页页码从request.args.get("page", 1, type=int)来）
模糊匹配统一用CONCAT('%', %s, '%')替代手动加%，让数据库处理通配符

参数化不是贴膏药，是重构查询逻辑的前提。漏掉一个format()，整个API就等于裸奔。别信“我这个字段只管理员能改”——权限控制和SQL安全是两层事，谁也替不了谁。