什么是最大允许 Content-Security-Policy？

Question

我有一个大型的遗留代码库，我想在其中引入 Content-Security-Policy header。短期内要真正 lock-down 站点是不可行的（例如，到处都是内联脚本，没有自动测试覆盖率），但至少我可以从禁止访问内容源开始我知道目前肯定没有使用，然后随着时间的推移慢慢降低它。

不幸的是，未使用的来源列表相当短。这是我第一次尝试 Content-Security-Policy 值：

default-src * 'unsafe-eval' 'unsafe-inline'

这破坏了很多东西，例如 images sourced using the data: scheme. Looking around, I see , such as connect-src ws:, that aren't explicitly called out in the docs。

基本上允许网站执行浏览器默认允许执行的所有操作的最大许可值是多少？Content-Security-Policy header 值是多少？换个方式问：我可以介绍什么 header 值绝对不会破坏网站上的任何东西？

如果我可以从我知道不会破坏任何东西的东西开始，然后减去我知道可以安全删除的权限，我会更愿意将 header 引入旧站点。

Answer 1

tl;dr 使用 "report only" 模式向遗留站点引入策略。

参见 w3.org/TR/CSP2/#source-list-guid-matching。

As defined above, special URL schemes that refer to specific pieces of unique content, such as "data:", "blob:" and "filesystem:" are excluded from matching a policy of * and must be explicitly listed.

因此，default-src * 'unsafe-eval' 'unsafe-inline' 'unsafe-dynamic' data: filesystem: about: blob: ws: wss: 的内容可能接近最宽松的政策。当然，可能还有更多协议需要列入白名单。

然而

人们通常采取相反的方法。他们将部署 header 和 Content-Security-Policy-Report-Only: default-src 'none'，这不会影响您网站的加载，并允许您根据违规或控制台警告逐步降低您的政策。

我强烈建议您从 caspr chrome extension 开始创建初始策略，然后使用 report-uri.io 查看报告违规行为。当您的政策看起来稳定并且违规行为很少时，请将您的政策切换到强制模式。

Answer 2

尝试

default-src *  data: blob: filesystem: about: ws: wss: 'unsafe-inline' 'unsafe-eval' 'unsafe-dynamic'; 
script-src * 'unsafe-inline' 'unsafe-eval'; 
connect-src * 'unsafe-inline'; 
img-src * data: blob: 'unsafe-inline'; 
frame-src *; 
style-src * data: blob: 'unsafe-inline';
font-src * data: blob: 'unsafe-inline';

即便如此，你还是可能会发现违规行为，如果你发现了，请向我举报！

什么是最大允许 Content-Security-Policy？

What is the maximally permissive Content-Security-Policy?

content-security-policy