先说一个核心判断：在Spring Boot导出Excel时，如果用户能指定排序字段，那ORDER BY后面的内容绝对不能参数化——JDBC和所有主流ORM都不支持对排序字段做参数绑定。直接拼接字符串等于把SQL解析权拱手交给攻击者，这可不是危言耸听。
ORDER BY 字段不能参数化，必须白名单校验
假设导出接口允许用户传?sort_field=created_at&sort_order=desc，常见的错误是试图用正则过滤或转义单引号，但攻击者总能绕过：sort_field=1; DROP TABLE users--、sort_field=(SELECT password FROM admins)、sort_field=`status` ASC, (SELECT 1) -- 都能成功执行。所以唯一可靠的手段就是白名单硬编码。
- 白名单必须硬编码，比如
private static final SetALLOWED_SORT_FIELDS = Set.of("id", "name", "email", "created_at", "amount"); - 校验要严格区分大小写：PostgreSQL默认区分，MySQL默认不区分；建议统一用小写存储白名单，输入调用
.toLowerCase()后再比对 - 排序方向（
ASC/DESC）也要单独白名单校验，比如Set.of("ASC", "DESC")，禁止透传任意字符串 - 如果业务支持多字段排序（如
sort_field=name,created_at），必须拆分后逐个校验，任一不匹配就拒绝
MyBatis-Plus 动态排序的正确写法
用@Select注解或XML写原生SQL时，${}是危险的（直接替换），而#{}对ORDER BY无效（会加引号导致语法错误）。所以别指望MyBatis的占位符能蒙混过关。正确做法是：在Service层完成白名单校验，再拼接安全的SQL片段。
String sortField = request.getParameter("sort_field");
String sortOrder = request.getParameter("sort_order");
if (!ALLOWED_SORT_FIELDS.contains(sortField.toLowerCase()) ||
!ALLOWED_SORT_ORDERS.contains(sortOrder.toUpperCase())) {
throw new IllegalArgumentException("Invalid sort parameter");
}
String safeOrderBy = String.format("%s %s", sortField, sortOrder);
// 再传入 MyBatis 的 ${}，此时已无风险
- XML中写成
ORDER BY ${safeOrderBy}，但前提是safeOrderBy已经是校验后的纯字母+空格+ASC/DESC - 避免在Mapper接口方法签名里直接接收
@Param("sortField") String sortField并传给${}——校验必须在进入DAO层前完成 - 如果用QueryWrapper，不要写
wrapper.orderBy(true, true, sortField)，因为sortField未校验；应先校验，再调用wrapper.orderByAsc("id").orderByDesc("created_at")等固定链式调用
Spring Data JPA 的排序注入风险点
Sort.by("user_input")看着挺安全的，但实际很危险——它底层仍然把字符串拼进ORDER BY子句，且不做白名单检查。传入new Sort(Sort.Direction.ASC, "name; DROP TABLE users--")就能触发注入。JPA的Pageable构造函数同样不校验字段名，PageRequest.of(0, 10, Sort.by("status"))中的"status"必须来自可信源。
- 禁止直接将
request.getParameter("sort")塞进Sort.by() - 正确做法：解析参数 → 白名单比对 → 映射为预定义的
Sort实例，比如Map.of("created_at", Sort.by(Sort.Direction.DESC, "created_at")) - 若需支持多字段，用
Sort.by(Sort.Order.asc("name"), Sort.Order.desc("created_at"))，而不是拼字符串 - 注意
Sort.Order构造器接受字段名但不校验，所以映射逻辑必须前置
导出接口中容易被忽略的别名与反引号陷阱
有些导出需求允许用户自定义列别名，比如SELECT name AS `Full Name`, email AS `Contact Email` FROM users。反引号内的内容如果来自用户输入，就可能逃逸并闭合引号，插入恶意SQL。比如用户传alias=`status` ASC, (SELECT 1)--，拼进去变成SELECT status AS `status` ASC, (SELECT 1)--` FROM users，直接破坏语法甚至执行子查询。
- 别名必须走第二套白名单，或者干脆禁止用户自定义别名，统一用代码内建的中文映射（如
Map.of("name", "姓名", "email", "邮箱")） - 如果必须支持带空格别名，只允许用下划线替代空格（
full_name），并拒绝任何反引号、双引号、单引号字符 - 校验逻辑应放在Controller层，早于任何SQL拼接动作；不要依赖前端传来的“看起来合法”的字符串
- 特别注意MySQL的标识符引号是反引号，PostgreSQL是双引号，SQL Server是方括号——白名单校验不解决跨库问题，统一用小写字母+下划线是最稳妥的兼容方案
说到底，真正的难点不在于写校验逻辑，而在于确认所有导出入口——包括后台管理页、API文档测试框、Swagger UI、Postman收藏夹里的旧请求——都经过同一套白名单校验。漏掉一个，就等于整条防线失效。
