框架接口被恶意请求攻击，本质上不是带宽被打满，而是攻击者利用框架在路由解析、参数绑定、序列化与异常处理链路中的低成本高收益缺陷，持续消耗应用服务器的CPU、内存和数据库连接。多数情况下，单次请求体只有几KB，却能触发数秒的接口计算或一次全表扫描。防护配置要做的不是简单加验证码或限流阈值，而是从框架层切断恶意请求进入业务逻辑的路径。
先看最常被攻击的几个框架接口特征。第一类是自动参数绑定过深，例如Spring MVC或某些PHP框架允许前端直接提交嵌套对象字段，攻击者可以构造超长JSON或表单字段名，触发框架递归解析，造成CPU飙升。第二类是内容协商机制被滥用，攻击者通过修改Accept头或添加特殊后缀，让接口返回XML、序列化对象甚至触发模板渲染。第三类是框架默认开启的异常堆栈回显，攻击者利用它探测内部类名、SQL片段和依赖版本。第四类是正则表达式匹配漏洞，部分框架路由使用用户可控的正则片段，恶意正则会导致灾难性回溯。
防护配置的第一步是关闭框架中非必要的自动绑定和深度解析能力。以Java生态为例，如果使用Jackson作为JSON解析器，必须显式限制最大嵌套深度和字符串长度。配置方式如下：
ObjectMapper mapper = new ObjectMapper();
mapper.getFactory().setStreamReadConstraints(
StreamReadConstraints.builder()
.maxNestingDepth(10)
.maxStringLength(20000)
.maxNumberLength(100)
.build()
);
对于Spring Boot应用，还需要在配置文件中禁用不必要的HTTP方法，并限制请求体大小。很多攻击的第一步是发送超大请求体或畸形Content-Length，框架在读取阶段就耗尽内存。配置server.tomcat.max-swallow-size和max-http-form-post-size只能解决一部分问题，更彻底的做法是在反向代理层和框架层同时设置请求体上限，通常API接口设置为1MB以内足够，文件上传接口单独走独立路由并限制MIME类型。
框架路由配置是第二个关键点。攻击者经常扫描类似/api/user/{id}这样的路径，通过遍历ID或注入特殊字符探测接口行为。如果框架路由支持正则表达式，必须避免在路由定义中使用用户输入直接拼接正则。例如某些Node.js框架允许开发者写router.get('/search/:keyword', handler)，框架内部会将keyword作为字符串处理，这本身安全，但若开发者又在handler里用keyword构造new RegExp(keyword)，就引入了ReDoS风险。防护配置上，建议在框架中间件层增加参数白名单校验，对路径参数只允许字母、数字、短横线和下划线，长度限制在64字符以内。任何不符合规则的路径参数直接返回400，不让请求进入业务逻辑。
内容协商攻击的防护常常被忽略。很多框架默认根据Accept头自动选择响应格式，攻击者发送Accept: application/xml或Accept: text/x-java-properties时，框架可能尝试用XML序列化器输出对象，而XML序列化器历史上存在大量反序列化漏洞。即使不触发漏洞，序列化大对象也会消耗大量CPU。防护配置上，应该在框架配置中显式声明只支持application/json，关闭其他所有消息转换器。Spring Boot中可以这样配置：
@Configuration
public class WebConfig implements WebMvcConfigurer {
@Override
public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
configurer.defaultContentType(MediaType.APPLICATION_JSON);
configurer.mediaType("json", MediaType.APPLICATION_JSON);
configurer.ignoreAcceptHeader(true);
}
}
ignoreAcceptHeader设为true后，框架不再解析Accept头，攻击者无法通过修改Accept头改变响应格式。对于必须支持多格式的接口，建议拆分为独立端点，例如/api/data.json和/api/data.xml，并在路由层做严格匹配，而不是依赖内容协商。
异常处理配置是框架接口防护的第三道防线。默认情况下，很多框架在发生未捕获异常时会返回包含堆栈信息的HTML或JSON，攻击者可以从中提取框架版本、类路径、数据库表名甚至部分SQL语句。防护配置必须覆盖所有异常类型，统一返回无敏感信息的错误响应。在Spring Boot中，使用@ControllerAdvice全局异常处理器，只返回错误码和通用消息，不返回exception.getMessage()。同时要在配置文件中设置server.error.include-message=never和server.error.include-stacktrace=never。对于Node.js的Express框架，要在所有路由之后添加错误处理中间件，并且不要在响应中输出err.stack。
更隐蔽的攻击方式是利用框架的异步处理或线程池耗尽。某些框架接口支持异步返回，攻击者发送大量请求后故意不读取响应，导致框架为每个请求分配线程或连接，最终线程池满，正常请求无法处理。防护配置需要在框架层设置异步超时时间和最大并发异步请求数。以Spring MVC的DeferredResult为例，必须设置超时时间，并在超时回调中主动释放资源。同时，在容器层限制最大线程数和连接数，例如Tomcat的maxThreads和maxConnections参数，根据服务器CPU核数和业务特征调整，而不是使用默认值。对于高并发API，建议将maxThreads设置为CPU核数的2到4倍，配合异步IO和队列削峰。
框架接口的幂等性设计也是防护配置的一部分。恶意请求攻击中有一类叫重放攻击，攻击者截获合法请求后反复发送，如果接口不具备幂等性，可能造成重复扣款、重复下单或数据重复写入。防护配置上，对于写操作接口，应该在框架层引入幂等键机制。客户端每次提交时携带唯一请求ID，服务端在Redis或内存缓存中记录该ID的处理状态，相同ID的请求直接返回首次处理结果。这个逻辑可以放在框架拦截器中统一实现，而不是散落在每个业务方法里。拦截器在进入Controller之前检查幂等键，处理完成后写入缓存并设置过期时间，过期时间根据业务特征设置为10分钟到24小时不等。
框架接口的限流配置不能只依赖IP维度。攻击者使用代理池或僵尸网络时，IP限流很容易被绕过。更有效的做法是在框架层实现多维度限流，包括用户ID、API Key、设备指纹和接口路径的组合。对于未认证接口，可以结合IP和请求特征（如User-Agent、Accept-Language、请求频率）进行评分。具体配置上，可以在网关层使用令牌桶或滑动窗口算法，每个接口单独设置阈值。例如登录接口限制为每IP每分钟5次，查询接口限制为每用户每分钟60次，批量操作接口限制为每用户每分钟10次。超过阈值后返回429状态码，并在响应头中返回Retry-After时间。框架层需要配合网关的限流结果，对429响应做缓存，避免限流判断本身成为性能瓶颈。
还有一个经常被忽视的防护点是框架的CORS配置。如果CORS配置过于宽松，例如允许任意Origin且允许携带凭证，攻击者可以构造恶意网页，在用户浏览器中跨域调用框架接口，利用用户的登录态执行未授权操作。防护配置上，CORS的allowedOrigins必须使用白名单，不能使用通配符*同时允许credentials。对于不需要跨域访问的接口，直接关闭CORS支持。在Spring Boot中，如果使用了@CrossOrigin注解，要检查每个注解的origins属性是否明确指定了域名。更推荐的做法是全局统一配置CORS，避免开发者在单个接口上随意开启。
框架接口的请求头校验也应该纳入防护配置。很多攻击工具会发送畸形或缺失的请求头，例如没有Host头、Content-Length与实际长度不符、Transfer-Encoding异常等。框架默认行为可能容忍这些畸形请求，但攻击者可以利用这种容忍绕过WAF或代理层的检测。防护配置上，应该在框架入口处增加请求头规范化校验，强制要求Host、Content-Type（对于有请求体的接口）、User-Agent等关键头存在且格式合法。对于不符合规范的请求，直接返回400并记录日志。同时，框架应配置为拒绝HTTP/1.0请求或不带Host头的HTTP/1.1请求，因为这类请求通常是扫描器或攻击工具发出的。
针对框架接口的恶意请求攻击，最终要落实到日志和监控。没有日志的防护配置是盲目的，无法判断攻击是否被成功拦截，也无法发现新的攻击模式。框架层应该记录每个请求的关键信息，包括请求路径、方法、来源IP、响应状态码、处理耗时、请求体大小和关键请求头。对于被拦截的请求，要单独记录拦截原因和命中的规则。日志格式建议使用结构化JSON，方便后续分析。同时，监控指标要覆盖接口的QPS、错误率、P99延迟、线程池使用率和内存占用。当某个接口的QPS突然上升或错误率异常时，应该触发告警，而不是等服务器宕机后才去查日志。
框架接口防护配置不是一次性工作，而是需要根据攻击态势持续调整。每次框架升级都可能引入新的默认行为，每个新接口上线都可能暴露新的攻击面。建议将上述防护配置沉淀为框架的默认模板，新项目初始化时就包含这些安全基线。对于存量项目，可以按照请求体限制、内容协商关闭、异常信息脱敏、路由参数校验、限流配置、CORS白名单、请求头校验、日志监控的顺序逐步推进。每一步都能立即减少攻击面，不需要等到全部完成才生效。
真正有效的框架接口防护，是让攻击者发现无论怎么构造请求，要么被框架直接拒绝，要么被限流拦截，要么触发告警后被快速封禁。攻击成本远高于攻击收益时，恶意请求自然会转向其他目标。而这一切的前提，是框架配置层面已经堵住了那些默认开启的危险能力，而不是依赖业务代码里的if判断去逐个防御。
