快速找到http请求中莫名其妙的增加的header的元凶

目前的一项工作是基于一个上游的大型单体应用进行二次开发。

在拉取到最新后，发现js无法请求其他的后端服务，即使其他的后端服务上配置有CORS也是不可以。提示blocked:csp。大概查了一下，发现上游代码在页面请求的返回中，Header中增加了
Content-Security-Policy --> connect-src 'self'

经过一翻搜索，https://cloud.tencent.com/developer/section/1189861 这里简单进行了描述。

在增加这个CSP(Content-Security-Policy)后，网页的安全性得到了增强，其中包括不允许js向非当前ip:port的目标进行交互；这对二次开发的功能造成干扰；这里简单介绍问题排查思路。

 

1、首先排查Servlet的Filter，如果是tomcat的，可以下断点在 ApplicationFilterChain类的 internalDoFilter 方法中，因为这里采用的是链式调用法，此处的 internalDoFilter 方法会被连续调用；

 

2、但是单纯的下断点不太方便，不容易排查问题；可以采用动态执行的代码，让其输出日志信息：

在这里下断点：

 

 

 

同时，对这个断点，进行修改，不让断点停下，而且动态执行语句  不要带中括号  [System.out.println(filterConfig.getFilterClass() + ((HttpServletResponse)response).getHeader("Content-Security-Policy"))]：

 

然后可以观察应用的标准输出； 如果不想看标准输出，可以把System.out.println换成 logger.info之类的，到日志里观察；

 

此时，触发业务逻辑； 当发现日志中的 header的信息，被人加上CSP之后， 上一条Filter的类就是添加CSP的元凶。

 

-----------------------------------------------分割线--------------------------------------------------

当然，这里可能有更复杂的情况，当使用了Spring Security后，Spring Security自己维护有一个Filter链路，也可以对Response进行修改；

如果前面的定位方式，定位到最后发现是 org.springframework.boot.web.servlet.DelegatingFilterProxyRegistrationBean$1 这就尴尬了，是Spring Security定制的过滤链路；里面又可以包含一批Filter。

 

需要再次在spring中下断点： FilterChainProxy的 doFilter方法

 

 

然后修改断点的属性， 去掉停顿，设置 Evaluate and Log

System.out.println(nextFilter.getClass().getName() + ((HttpServletResponse)response).getHeader("Content-Security-Policy"))

 

然后继续观察，当发现日志中的 header的信息，被人加上CSP之后， 上一条Filter的类就是添加CSP的元凶。

 

 

 

如此，就可以在不清楚整体代码的情况下，快速找到修改Response的header的元凶了。