用预处理语句代替字符串拼接
SQL注入本质是用户输入被当作SQL代码执行，最直接有效的防御就是切断「输入 → 代码」的通路。MySQLi 和 PDO 都支持预处理（prepared statement），它把 SQL 结构和数据分开传输，服务端先编译语句模板，再绑定参数，此时参数值永远不会被解析为语法的一部分。
常见错误是仍用
mysqli_query()拼接
$_GET['id']或
$_POST['username']：
mysqli_query($conn, "SELECT * FROM users WHERE id = " . $_GET['id']); // 危险！
正确做法是使用
mysqli_prepare()+
mysqli_stmt_bind_param()，或 PDO 的
prepare()+
execute()：
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND status = ?");
$stmt->execute([$_POST['username'], 1]);
问号占位符（?）或命名参数（:name）由驱动层做类型转换和转义，不依赖 PHP 层手动过滤
即使传入 ' OR 1=1 --，也会被当作文本值匹配，不会改变 SQL 逻辑 注意：
mysql_real_escape_string()已废弃且不解决所有场景（如数字上下文无引号时无效），别用
最小权限原则：给应用账户只配必要权限
一个 Web 应用通常只需要查、增、改少量表，却常被赋予
GRANT ALL ON *.*，这是高危配置。攻击者一旦突破应用层（比如上传 Webshell 或利用框架漏洞），就能直接执行
DROP DATABASE或读取
mysql.user表。
应为每个应用创建独立账号，并限制作用域：
用CREATE USER 'app_rw'@'192.168.1.%' IDENTIFIED BY 'strong_pwd';明确指定 IP 段 只授权具体库表：
GRANT SELECT, INSERT, UPDATE ON myapp.users TO 'app_rw'@'%';禁止授予
FILE、
PROCESS、
SUPER等高危权限（它们可能用于读写文件或提权） 生产环境禁用 root 远程登录；本地管理用
localhost限定，避免暴露在公网
关闭危险配置与默认账户
MySQL 默认安装带一些便利但不安全的选项，上线前必须检查：
skip-grant-tables必须关闭——它会跳过所有权限验证，仅调试时临时启用
local_infile默认为 ON（尤其 MySQL 5.6+），攻击者可通过
LOAD DATA LOCAL INFILE读取服务器任意文件，应在 my.cnf 中设为
local_infile = OFF并重启 删除匿名用户：
DELETE FROM mysql.user WHERE User = '';删除 test 库：
DROP DATABASE IF EXISTS test;（它默认允许任何用户访问） 确保
secure_file_priv设为非空路径（如
/var/lib/mysql-files/），限制
LOAD_FILE()和
INTO OUTFILE的读写范围
应用层还需防绕过预处理的边界场景
预处理能挡住绝大多数注入，但有些地方它根本不起作用——因为 SQL 语法不允许参数化。比如表名、列名、排序字段、LIMIT 的 offset 值，这些都必须拼接进 SQL 字符串。
这时不能靠“过滤关键词”，而要走白名单校验：
排序字段只能从预定义数组中选：$valid_sorts = ['created_at', 'status', 'score'];，再用
in_array($_GET['sort'], $valid_sorts)判断 LIMIT 的 offset 和 count 必须强制转整型：
(int)$_GET['offset']，并加范围限制（如
max(0, min(1000, $offset))） 动态表名绝不能来自用户输入；如需多租户分表，应通过配置映射而非直接拼接 存储过程内若用
CONCAT()拼 SQL 再
EXECUTE，同样属于二次注入点，要同样白名单处理
真正难防的从来不是标准 CRUD，而是那些需要动态结构的场景——那里没有银弹，只有严格约束和人工审查。
