Java安全处理用户输入的核心是“先校验、再使用”，需后端严格校验来源、层级（格式/范围/语义/上下文）并转义，禁用前端依赖、黑名单过滤，坚持白名单与防御性编码。
Java中安全处理用户输入，核心是“先校验、再使用”，不能依赖前端验证，必须在后端做严格校验和转义。重点在于区分输入来源（如HTTP参数、JSON Body、文件上传）、明确校验层级（格式、范围、语义、上下文），并配合防御性编码手段。
基础校验：非空与类型合法性
所有用户输入默认视为不可信字符串。第一步永远是判空和类型转换保护：
- 用 StringUtils.isNotBlank() 替代
!= null && !"".equals()，避免空指针和空白字符绕过 - 数字类参数不用
Integer.parseInt()直接强转，改用 NumberUtils.toInt(str, defaultValue) 或封装 try-catch + 日志告警 - 布尔值不靠
"true".equals(input)简单判断，使用 Boolean.parseBoolean() 并限定可接受值（如只允许 "true"/"false"，拒绝 "1"/"yes"）
格式校验：正则与白名单优先
邮箱、手机号、身份证号等有明确格式的字段，必须用预编译正则校验，且坚持白名单原则：
- 邮箱示例：
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$，注意结尾域名长度限制 - 手机号（国内）：用
^1[3-9]\\d{9}$，不接受带区号、括号、横线的“友好格式”——前端应统一格式化，后端只认标准11位 - 绝对避免黑名单过滤（如禁用
），攻击者总能变形绕过；只放行已知安全模式
业务语义校验：结合上下文做逻辑判断
格式正确不等于业务合法。例如：
立即学习“Java免费学习笔记（深入）”；
- 用户修改密码时，“新密码”不能与“旧密码”相同，需查库比对（明文比对需脱敏处理）
- 转账接口中，“金额”必须 > 0 且 ≤ 用户可用余额，需查账务状态，不能只校验正数
- 文章标题长度限制为1–50字符，但还要过滤控制字符（
\u0000–\u001F）、零宽空格（\u200B）等隐形非法字符
防御性输出与存储：防注入、防XSS、防路径遍历
校验通过后，仍需根据使用场景做安全处理：
- 拼SQL？用 PreparedStatement，绝不字符串拼接；ORM框架启用参数绑定
- 返回前端？HTML内容用 StringEscapeUtils.escapeHtml4() 转义；JSON响应确保序列化器已禁用危险类型（如 Hibernate 的 LazyCollection）
- 文件名来自用户？提取原始文件名后，用 FilenameUtils.getName() 获取纯名称，并重命名（如UUID）+ 限定扩展名白名单（如
["jpg","png","pdf"]）
基本上就这些。校验不是越严越好，而是要贴合业务真实约束；安全不是加一层过滤器，而是每个接收点都默认怀疑、主动验证、明确处置。不复杂但容易忽略。
