过滤器（Filter）不应修改请求参数值，仅负责检测、记录和告警；必须全面覆盖所有输入来源，包括JSON、multipart、路径变量、请求头、查询字符串等；优先采用白名单校验机制，若使用正则匹配则需添加单词边界；配置需外置，确保加载顺序正确，同时日志需进行脱敏处理。
需要明确的是，过滤器并不能替代参数化查询，它仅作为一道辅助防线，并且很容易误拦截正常请求。要真正防御SQL注入，必须从使用PreparedStatement或MyBatis的#{} 开始。
首先给出一个核心判断：过滤器如果使用得当，就像一位优秀的守门员；但如果使用不当，反而会成为团队的负担。许多团队一开始就试图在Filter中修改参数值，结果往往导致系统问题频发。
为什么过滤器不应进行转义或修改参数值
很多团队一开始就编写HttpServletRequestWrapper来重写getParameter()方法，将单引号替换为两个单引号，或者直接删除分号。这种做法会导致以下三类问题：
- JSON字段中包含如{"type": "SELECT"}这样的内容被截断，导致后端解析失败
- 用户昵称如O'Reilly被错误处理为OReilly，造成前端显示异常
- Servlet容器可能缓存原始参数，导致getInputStream()和getParameterMap()返回的数据不一致
真正安全的做法是：过滤器仅负责检测、记录和告警，绝不修改原始请求数据。
过滤器必须覆盖所有输入源，不能仅扫描getParameterMap()
POST请求的JSON体、PUT请求的body、multipart/form-data的文件上传字段、路径变量（Path Variable）、请求头中的token等，都不会出现在getParameterMap()中。仅扫描表单参数相当于没有防护。
- 针对application/json格式：使用request.getInputStream()读取原始body，然后通过Jackson或Gson解析，遍历所有字符串字段进行检查
- 针对multipart/form-data格式：调用request.getParts()方法，逐个检查每个Part的内容类型和字符串值
- 针对路径变量：Spring Boot的@PathVariable值在Filter阶段不可见，需要改用HandlerInterceptor或提前在路由层提取（但不推荐这种做法）
- 不要遗漏GET请求的查询字符串，它和表单参数一样通过getParameterMap()获取
正则匹配关键字是高风险操作，应优先采用白名单加日志告警策略
使用像str.contains("union") || str.contains("select")这样的规则，会将搜索接口如/api/docs?q=select * from users误判为攻击而拦截；而注释中的/* SELECT FROM */却可能被忽略，导致漏检。
- 如果必须使用正则匹配，应使用Pattern.compile("(?i)\b(select|insert|delete|update|exec|declare)\b", Pattern.UNICODE_CASE)，并添加单词边界和大小写不敏感标志
- 匹配到可疑内容后，不要直接返回response.sendError(403)，而是记录日志并设置标记，由后续的HandlerInterceptor或全局异常处理器决定是否拦截
- 更稳妥的做法是：仅对已知的高危上下文采用白名单策略，例如排序字段只允许["id", "created_at", "status"]等值，其余一律拒绝
- 配置项必须外置到配置文件中，例如使用@Value("${security.sql-filter.enabled:true}")，以便在上线前可以快速关闭，避免误伤正常请求
过滤器加载顺序和路径范围常被忽略
仅仅编写了@WebFilter(urlPatterns = "/*")就以为万事大吉？这是错误的。Spring Boot内嵌的Tomcat默认不会扫描非@Component注解的Filter类，而且SecurityFilterChain会在你的Filter之前处理未认证的请求。
- 必须添加@Component注解，否则@WebFilter注解将不生效
- 使用@Order(Ordered.HIGHEST_PRECEDENCE)确保过滤器排在Spring Security之前
- urlPatterns需要排除健康检查、静态资源、Swagger等路径：例如@WebFilter(urlPatterns = "/api/*", excludePatterns = {"/actuator/**", "/css/**", "/v3/api-docs/**"})
- 日志中不要打印完整参数值，尤其是包含password、token、id_card等敏感字段，否则会引入新的信息泄露风险
最困难的部分并不是编写一个能拦截“or 1=1”的过滤器，而是确保它在multipart/form-data、application/json以及带文件上传的PUT请求中都能真正生效——而这一点，90%的团队直到上线后才发现测试不够全面。
