后端参数校验的漏洞不是“功能缺陷”，而是“攻击入口”。很多开发者习惯把校验逻辑全部堆在前端，认为用户只会通过浏览器表单提交数据，这种假设在真实攻击场景中完全站不住脚。攻击者根本不需要打开你的网页，直接用脚本构造HTTP请求就能绕过所有前端限制。参数校验必须落在后端，而且要覆盖数据类型、长度、格式、取值范围、业务逻辑一致性等多个维度，否则恶意数据一旦进入系统，轻则导致业务异常，重则触发SQL注入、XSS、越权访问甚至远程代码执行。

先看一个最典型的场景：用户注册接口接收年龄字段。前端限制了只能输入数字，但攻击者用curl发送age=abc或者age=-100，如果后端没有校验，这个非法值会直接进入数据库。更危险的是，如果后续业务逻辑用年龄做除法运算或者数组索引，就可能引发未预期行为。正确的做法是在控制器层或服务层入口处，对每一个入参做严格类型判断和范围限制。以Java的Spring Boot为例，可以使用@NotNull、@Min、@Max、@Pattern等注解，但注解只能覆盖基础场景，复杂业务规则还需要在服务层写显式校验代码。

// 错误示范：直接信任前端传来的值
public User createUser(String ageStr) {
    int age = Integer.parseInt(ageStr); // 可能抛NumberFormatException
    // 如果age为负数或超大值，后续逻辑可能异常
    return userRepository.save(new User(age));
}

// 正确做法：显式校验类型和范围
public User createUser(String ageStr) {
    if (ageStr == null || !ageStr.matches("\\d+")) {
        throw new IllegalArgumentException("年龄必须为正整数");
    }
    int age = Integer.parseInt(ageStr);
    if (age < 1 || age > 120) {
        throw new IllegalArgumentException("年龄超出合理范围");
    }
    return userRepository.save(new User(age));
}

字符串类型的参数是恶意数据入侵的重灾区。用户昵称、搜索关键词、评论内容等字段如果不对长度和字符集做限制，攻击者可以提交超长字符串导致数据库截断异常或内存消耗过大，也可以注入控制字符或特殊Unicode字符绕过过滤规则。一个常见的攻击手法是利用零宽字符或同形字符伪造管理员用户名，例如在“admin”中间插入零宽空格，视觉上看起来一样，但系统认为是不同用户。因此，对字符串参数要同时校验长度上限、允许的字符集、是否包含控制字符，并且对Unicode进行规范化处理。

数组和集合类型的参数同样不能掉以轻心。批量导入接口如果接收一个JSON数组，攻击者可以提交包含百万个元素的数组，瞬间拖垮服务器内存。必须限制数组长度，并且对数组内每个元素做与单条数据相同的校验。分页参数page和size如果没有上限控制，攻击者请求size=99999999会导致数据库全表扫描。建议对分页参数设置默认值和最大值，例如size默认20，最大不超过200。

枚举类型参数经常被忽略。很多接口用字符串表示状态，比如status=active，后端直接用这个值去数据库查询。攻击者可以传status=1 OR 1=1，如果后续拼接SQL就产生注入。即使使用ORM框架，非法枚举值也可能导致查询异常或绕过权限过滤。正确的做法是定义明确的枚举类，接收参数后先转换为枚举，转换失败直接拒绝请求。对于必须用字符串的场景，要用白名单校验，只允许预定义的合法值。

日期和时间参数需要额外注意格式和时区问题。攻击者可以提交2024-02-30这种不存在的日期，或者0000-00-00，如果后端用SimpleDateFormat解析并设置宽松模式，可能会得到意想不到的结果。建议使用java.time包下的严格解析器，并指定时区。对于时间范围查询，还要校验开始时间不晚于结束时间，防止攻击者利用反向区间绕过数据过滤逻辑。

文件上传接口的参数校验更加复杂。除了常规的文件名长度和扩展名白名单，还要校验文件的MIME类型和实际内容。攻击者可以把可执行脚本伪装成.jpg文件上传，如果服务器后续把这个文件包含到页面中，就形成存储型XSS或代码执行漏洞。文件大小必须在服务端限制，不能依赖前端。对于图片文件，可以用ImageIO.read()尝试解析，解析失败说明文件内容不是合法图片。对于文档类文件，要检查文件头魔数，不能只看扩展名。

关联对象和嵌套结构的校验往往被遗漏。一个订单接口可能接收orderItems数组，每个元素包含productId和quantity。开发者可能只校验了订单总金额，却忽略了productId是否存在、quantity是否为正整数。攻击者可以提交productId为其他用户的私有商品ID，或者quantity为负数来篡改库存。这类业务逻辑校验必须放在服务层，结合数据库查询验证关联数据的合法性和归属权限。

参数校验的时机和层次同样关键。控制器层适合做基础的类型、格式、长度校验，服务层负责业务规则校验和跨字段校验。不要在数据访问层才做校验，因为此时恶意数据可能已经参与了部分业务逻辑。对于公开API，还要在网关层做第一道粗粒度过滤，比如限制请求体大小、拒绝明显非法的Content-Type。多层校验虽然看起来冗余，但能有效缩小攻击面。

异常处理策略直接影响参数校验的效果。如果校验失败后返回的异常信息过于详细，比如直接抛出SQLException的堆栈，攻击者就能从中推断出数据库表结构。应该捕获所有校验异常，统一返回模糊的错误提示，例如“参数不合法”，同时将详细错误记录到服务端日志。对于不同错误类型，可以返回不同的错误码，但错误码本身不应泄露内部实现细节。

使用框架自带的校验注解时要注意分组校验和嵌套校验的配置。例如更新用户信息时，id字段必填，创建用户时id字段必须为空，这需要通过校验分组来区分。对于嵌套对象，要加上@Valid注解才能触发级联校验，否则内层对象的校验规则不会生效。这些细节在快速开发中很容易被忽略，导致校验形同虚设。

针对NoSQL数据库的参数校验有特殊要求。MongoDB的查询参数如果接收一个JSON对象，攻击者可以注入$gt、$ne等操作符，绕过原本的查询条件。例如登录接口接收{"username": "admin", "password": {"$ne": ""}}，如果后端直接把这个对象传给MongoDB的findOne()，就能绕过密码验证。必须对这类参数做严格的键值类型校验，只允许预期的字段和数据类型，拒绝任何包含$开头的键。

参数校验还要考虑幂等性和并发场景。一个转账接口如果只校验了金额为正数，但没有校验请求的唯一性，攻击者可以重复发送相同的转账请求，造成资金重复扣减。这类问题需要在参数中引入请求唯一标识，并在服务端做幂等处理。校验逻辑本身也应该是无状态的，避免因为并发请求导致校验条件被绕过。

对于需要跨字段联合校验的场景，单独校验每个字段是不够的。例如一个优惠券接口接收couponCode和orderAmount，如果只校验couponCode格式合法、orderAmount为正数，攻击者可以用一个仅限高额订单使用的优惠券去抵扣低额订单。必须把这两个字段放在一起校验，验证优惠券的使用条件和订单金额的匹配关系。

参数校验的代码应该集中管理，避免散落在各个业务方法中。可以设计统一的校验工具类或校验器接口，把常用的校验规则封装成可复用的方法。对于复杂业务规则，可以定义领域对象并在构造方法或工厂方法中完成校验，确保非法对象根本无法被创建。这种方式比在业务逻辑中到处写if判断更可靠，也更容易维护。

最后要强调的是，参数校验不能替代其他安全防护措施。即使参数校验做得再完善，如果数据库查询使用字符串拼接SQL，仍然存在注入风险；如果输出到页面时没有做HTML编码，仍然存在XSS风险。参数校验是纵深防御体系中的第一道防线，它的目标是阻止明显非法的数据进入系统，减少后续安全机制的压力。开发者应该把参数校验视为编码习惯的一部分，而不是额外的负担。