直接拼接$_get['sort']到order by存在sql注入风险，因数据库会解析任意字符串为列名，攻击者可构造如"id asc, (select password from users)"等恶意payload；白名单校验是唯一可靠方案，需硬编码允许列名与方向并严格类型比较，拼接时用反引号包裹列名。
为什么不能直接拼接 $_GET['sort'] 到 ORDER BY 后面
因为数据库会把任意字符串当列名解析，攻击者传入 id ASC, (SELECT password FROM users LIMIT 1) 这类 payload，就能触发子查询泄露数据；更隐蔽的是传 name; DROP TABLE products--（虽然多数 MySQL 配置禁用多语句，但风险仍在）。关键不是“有没有执行成功”，而是“数据库是否尝试解析并执行了恶意片段”。
白名单是唯一可靠方案——只允许预设的、业务真正需要的列名进入 SQL，其余一概拒绝。
如何定义和校验排序列名白名单
白名单必须硬编码在 PHP 中，不能从配置文件或数据库读取（否则可能被污染）。校验逻辑要放在 SQL 拼接之前，且失败时必须中止，不能 fallback 到默认列名（那等于绕过校验）。
- 定义白名单数组：
$allowedSortColumns = ['id', 'name', 'created_at', 'price']; - 严格校验输入：
if (!in_array($_GET['sort'] ?? '', $allowedSortColumns, true)) { http_response_code(400); die('Invalid sort column'); } - 注意：必须用
===或in_array(..., true)做严格类型比较，避免'0'匹配到0等弱类型陷阱 - 不要用正则匹配（如
/^[a-z_]+$/i），列名有下划线、大小写混合、甚至带数字（如user_id）时极易漏判或误放
如何安全拼接 ORDER BY 子句（含方向控制）
排序方向（ASC/DESC）同样不能信任用户输入。即使列名合法，传入 ASC; DROP TABLE-- 仍可能被解析为注释后执行——取决于 MySQL 版本和 SQL_MODE。所以方向也得走白名单。
- 方向白名单：
$allowedSortDirections = ['ASC', 'DESC']; - 完整拼接示例：
$column = $_GET['sort'] ?? 'id'; $direction = strtoupper($_GET['order'] ?? 'ASC'); if (!in_array($column, $allowedSortColumns, true) || !in_array($direction, $allowedSortDirections, true)) { die('Invalid sort parameter'); } $sql = "SELECT * FROM products ORDER BY `$column` $direction LIMIT 20"; - 列名用反引号包裹（
`$column`），防止列名含空格或关键字（如order）导致语法错误 - 不要用 PDO 的命名参数绑定
:sort——PDO::prepare()不支持绑定列名或关键字，只会原样拼进 SQL，失去防护意义
容易被忽略的边界情况
真实项目里，白名单失效往往不是因为逻辑错，而是细节松动：
- 前端传参键名不一致：比如前端发
sort_by=name，但后端只检查$_GET['sort']，结果绕过校验 - 列别名未同步进白名单：SQL 中用了
SELECT price AS cost，但白名单只写了price，用户传cost就被拒，或更糟——开发者为兼容加了'cost' => 'price'映射，却忘了过滤映射值 - 大小写混用：MySQL 默认不区分列名大小写，但 PHP 白名单是区分的；如果白名单写
'Name'，而用户传name，就失败；建议统一转小写校验，或白名单全小写 + 输入强制小写 - 多表 JOIN 场景：ORDER BY 可能涉及
users.name这种带表前缀的写法，白名单需明确是否允许点号，以及是否验证前缀合法性（如只允许users.和orders.）
白名单不是设一次就完事，每次新增排序需求、重构表结构、引入新字段时，都得同步更新它——漏掉一个，整套防护就形同虚设。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
