Spring Boot集成Spring Security部署Cloud Foundry后HEAD接口返回403排查

你遇到的HEAD请求返回403的问题，和Spring Security的配置没有直接因果关系，核心拦截点发生在Cloud Foundry平台网关层，请求根本没有抵达你的Spring Boot应用进程。
对应几个现象的验证逻辑：

• 你设置最高优先级的自定义过滤器、调整Spring Security过滤器最低优先级均未生效的原因是：所有应用内的过滤器都运行在Spring Boot的Servlet容器进程内，被平台网关拦截的请求不会被转发到应用进程，自然所有应用层的逻辑都不会触发。
• 应用启动时看到的For security constraints with URL pattern [/*] only the HTTP methods [HEAD OPTIONS] are covered. All other methods are uncovered.是Spring Security的常规提示告警，并非403的诱因——你自己的对比测试已经证明：同路径的GET请求可以正常遍历Spring安全过滤链，最终返回符合预期的405，说明Spring Security的规则匹配逻辑是正常运行的。
• 应用侧没有捕获到HEAD请求对应的Spring过滤链、DispatcherServlet日志的特征，和「请求在进入Spring容器前被拦截」的现象完全匹配，排除嵌入式Servlet容器（Tomcat/Jetty）拦截的可能——因为如果是容器层拦截，会在应用侧打印对应请求日志；项目无web.xml配置的特征，也进一步排除了Servlet层面静态安全规则拦截的可能，这类拦截发生在应用进程内，必然会在应用侧留存日志。

企业部署的Cloud Foundry环境通常会在边缘网关（GoRouter、前置WAF、绑定的路由服务）配置HTTP方法白名单规则，多数场景下默认仅放行GET/POST/PUT/DELETE方法，会将HEAD、PATCH等非常规方法直接拦截，返回403响应。这类网关层的拦截不会把请求转发到后端应用，因此应用侧不会留存任何处理日志。

• 第一优先级验证：联系平台运维团队检查对应应用所在空间的网关规则，确认HEAD方法是否在HTTP方法放行列表中。可以通过同空间的测试应用发起内网HEAD请求做交叉验证，如果同样返回无应用日志的403，即可100%确认拦截发生在平台层。
• 启动告警消噪操作（不解决当前403问题，仅消除日志噪音）：
  该告警的本质是配置授权规则时，未将HTTP方法和对应的权限规则做绑定，Spring Security默认会单独对HEAD、OPTIONS方法做规则匹配，因此触发提示。可在authorizeRequests配置中显式声明对应路径的HEAD方法匹配规则，示例：

  http.authorizeRequests(auth -> auth
      .antMatchers(HttpMethod.HEAD, "/api/v2/**").authenticated()
      .antMatchers("/api/v2/**").authenticated()
      .antMatchers("/actuator/**").hasAuthority("Internal")
      .anyRequest().authenticated()
  )
  

• 临时绕过方案：如果暂时无法调整网关的拦截规则，可以将HEAD请求替换为标准GET请求，在接口逻辑中增加判断：如果请求携带X-HTTP-Method-Override: HEAD请求头，则清空响应体仅返回状态码，模拟HEAD方法的语义。

内容的提问来源于stack exchange，提问作者Boudhayan Dev