Tomcat+Wicket应用遇严格CSP限制，无法定位政策定义源

首先明确：Chrome不是CSP规则的定义方，它只是负责检测并执行收到的CSP指令，你看到的报错是它执行规则时的提示，规则本身来自你的服务端（Tomcat或Wicket）。

接下来分两种核心可能性排查：

1. 最可能的来源：Wicket 9.x 默认CSP配置 #

Wicket 9.0+版本内置了CSP支持，默认在生产模式下会自动添加较严格的CSP响应头，目的是提升应用安全性。它会限制内联样式、脚本，以及资源加载的来源，这正好匹配你遇到的报错（拒绝加载样式/脚本、禁止内联样式）。

排查方式：

• 打开项目的Application子类（继承自WebApplication的类），检查是否有如下类似配置：

  @Override
  protected void init() {
      super.init();
      // 可能开启了严格的CSP阻断模式
      getCspSettings().blocking().enabled(true);
  }
  

• Wicket的CSP配置优先级很高，即使你在Tomcat里设置了CSP，也会被Wicket的配置覆盖，这也解释了你在Tomcat中设置无效的原因。

2. 次要可能：Tomcat中的自定义CSP配置 #

Tomcat本身默认不会添加CSP，但如果你的项目中配置了安全过滤器（比如第三方安全框架的过滤器），或者在Tomcat全局conf/web.xml、项目web.xml里添加了Content-Security-Policy相关的响应头配置，也可能导致这个问题。

排查方式：

• 检查项目的web.xml文件，是否有<filter>或<filter-mapping>配置了添加CSP头部的逻辑；
• 检查Tomcat的conf/web.xml，看全局是否有统一的CSP配置。

关键验证步骤 #

用Chrome开发者工具确认CSP的来源：

1. 打开Chrome DevTools（F12），切换到「Network」标签；
2. 刷新页面，找到主页面的请求（一般是第一个请求）；
3. 查看「Response Headers」部分，找到Content-Security-Policy字段，结合你的配置对比，就能确定是Wicket还是Tomcat添加的。

另外，你之前用HTML meta标签配置CSP无效，是因为当响应头中已经存在CSP时，meta标签的CSP规则会被忽略，meta标签只在没有响应头CSP的情况下生效。

内容的提问来源于stack exchange，提问作者Eric Lemaitre