sql注入源于后端未过滤的用户输入拼接进sql语句，必须用参数化查询防御；前端校验可被绕过，orm使用不当仍会触发注入；表名等动态元素需白名单校验，日志记录也需防范二次注入。
表单提交的数据根本不会“自动”进SQL语句
HTML 表单本身不执行 SQL，也不会直接导致注入。真正危险的是后端代码把 request.form['username']（Python Flask）、$_POST['email']（PHP）这类未过滤的输入，拼进 SQL 字符串里，比如："SELECT * FROM users WHERE email = '" + email + "'"。这时候攻击者输 ' OR '1'='1 就能绕过验证。
所有数据库操作必须用参数化查询
这是唯一可靠的方式。不是“过滤引号”或“转义单引号”，而是让数据库驱动把值当纯数据、不参与 SQL 解析。
- Python（sqlite3 / psycopg2）：用
?或%s占位，传参为元组/列表，如cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,)) - PHP（PDO）：用命名占位符，
$stmt = $pdo->prepare("SELECT * FROM posts WHERE slug = :slug"); $stmt->execute(['slug' => $_GET['slug']]); - Node.js（pg）：用
$1,$2，client.query("SELECT * FROM logs WHERE level = $1", ["error"])
别碰 mysql_query("SELECT * FROM t WHERE x = '" . $_GET['x'] . "'") —— 这类写法哪怕加了 mysqli_real_escape_string 也扛不住多字节编码或宽字节注入。
前端 JS 校验和 HTML 属性只是体验层，不能替代后端防护
type="email"、pattern、required 或 jQuery 表单验证，全都可以被绕过。开发者工具禁用 JS、curl 直发请求、改 POST 数据——这些操作不需要任何技术门槛。
立即学习“前端免费学习笔记（深入）”；
- 前端限制长度（
maxlength）不阻止后端收到超长字符串 -
disabled或readonly的 input 可以被手动删掉再提交 - 任何
fetch()请求都能被重放，且 payload 可任意构造
所以，哪怕你前端写了十层校验，后端该做的参数化+类型检查+长度截断，一个都不能少。
ORM 并不等于免疫 SQL 注入
Django ORM、SQLAlchemy Core、Laravel Eloquent 默认安全，但一旦你用 raw()、extra()、whereRaw() 或字符串格式化拼接字段名/表名，风险立刻回归。
- 危险：
User.objects.extra(where=["name = '" + name + "'"])——name是用户输入 - 危险：
db.session.execute(f"UPDATE logs SET status = '{status}' WHERE id = {id}") - 安全：
User.query.filter(User.name == name).all()或db.session.execute(text("UPDATE logs SET status = :s"), {"s": status})
表名、字段名、排序方向（ORDER BY ?）这类动态 SQL 元素无法参数化，必须白名单校验，比如只允许 ["created_at", "name", "email"] 中的值。
最常被忽略的一点：日志记录里如果把原始请求参数直接写进 SQL 错误日志表，也可能触发二次注入——别以为“只是记个日志”就安全。
