Content Security Policy(CSP)应该在后端还是前端进行配置？

两种CSP配置方式的核心区别 #

• 生效时机不同：响应头配置的CSP在浏览器拿到HTTP响应的第一时间就生效，早于HTML内容解析，能覆盖页面从加载到运行的全流程，没有防护盲区；meta标签配置的CSP要等浏览器解析到该标签才会生效，放在标签之前的内联脚本、资源请求都不受管控，哪怕放在head里，只要位置不是最靠前，就会有防护漏洞。
• 支持的指令范围不同：响应头支持所有CSP指令，包括用来防iframe嵌套的frame-ancestors、违规上报的report-uri、全局沙箱的sandbox等特殊指令，这些指令meta标签是完全不支持的。
• 调试灵活度不同：响应头支持Content-Security-Policy-Report-Only模式，可以只上报违规行为不实际拦截，非常适合调试和灰度验证规则；meta标签没有这个模式，一旦配置就会直接生效拦截，调试成本很高。
• 规则叠加逻辑不同：如果同时配置了两种方式的CSP，浏览器会同时执行两套规则，最终生效的是两者最严格的交集，不会出现后者覆盖前者的情况。

仅使用一种配置方式是否足够 #

仅用响应头配置是完全足够的，能覆盖所有CSP的使用场景。
仅用meta配置仅适用于非常简单的场景：你没有修改服务端响应头的权限，且只需要限制页面内的资源加载，不需要用到frame-ancestors这类特殊指令，同时能保证meta标签放在head的最开头，不会有任何内联脚本、资源引用出现在它之前，这种场景下仅用meta是够用的，其余场景仅用meta都会有防护漏洞。

配置方式选择建议 #

优先选择仅服务端配置响应头的方式，这是官方推荐的最佳实践，覆盖能力最全、生效时机最早、没有防护盲区，调试也更灵活。
只有当你完全没有服务端配置权限，比如使用静态页面托管服务无法自定义响应头的时候，再考虑用meta标签配置，注意一定要把CSP的meta标签放在head的最靠前位置，避免出现防护遗漏。
除非你需要在现有响应头CSP的基础上叠加更严格的规则，否则没必要同时配置两种，反而容易出现规则冲突，排查问题成本很高。

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