Next.js生产环境配置Content Security Policy (CSP)相关问题咨询

1. 能否在next.config.js的header配置中使用'nonce'？具体如何实现？ #

不能直接在next.config.js的静态headers配置中使用nonce。nonce要求每个请求生成唯一的随机值，属于请求级别的动态变量，而next.config.js里的header配置是构建阶段就固定的静态规则，天生不支持动态生成每个请求独有的nonce。
如果要使用HTTP Header形式的CSP搭配nonce，需要通过自定义Server、Edge Runtime、或者部署平台的Edge Function，在每个请求到来时生成随机nonce，一方面写入响应头的CSP规则里，另一方面把nonce传递给页面内所有Next.js自动注入的内联脚本、样式标签，实现放行。

2. 已有Next.js输入 sanitize和Mongo查询 sanitize的前提下，样式配置unsafe-inline是否还有安全风险？ #

仍然存在安全风险。Next.js默认的输入 sanitize仅针对JSX渲染的普通文本内容，如果你在代码中使用了dangerouslySetInnerHTML、允许用户控制元素的style属性、或者引入的第三方前端依赖存在XSS漏洞，攻击者仍然可以通过注入恶意内联样式实现钓鱼、页面内容篡改、敏感数据窃取等攻击，甚至可以配合其他漏洞实现代码执行。数据库层的查询 sanitize只能防范注入类的数据库攻击，对前端层面的XSS风险没有防护作用，因此不建议为了省事开启unsafe-inline。

3. 自定义_document.js注入meta标签的CSP方案，安全性是否和HTTP Header配置相当？ #

只要你不需要用到frame-ancestors、report-uri、sandbox这几个meta标签不支持的CSP指令，两种方案的安全性是完全相当的，不存在meta标签更容易被绕过的问题。唯一需要注意的是要把CSP的meta标签放在<head>的最顶部，确保在所有可执行的脚本、样式加载之前就生效，就可以避免被提前注入的内容绕过。

4. 配置最高强度CSP的推荐方案是什么？ #

优先选择动态nonce+HTTP Header的方案：通过Edge函数或者自定义服务为每个请求生成唯一nonce，在响应头里写入CSP规则，同时把nonce同步传递给页面内所有内置的内联资源，配合strict-dynamic指令减少需要手动配置的可信源列表，完全不需要开启unsafe-inline/unsafe-eval这类低安全性规则。
如果你的部署环境不支持动态修改响应头，可以使用官方示例中的自定义_document注入meta标签+哈希校验的方案：提前计算Next.js内置的内联脚本、样式的哈希值，写入CSP规则里放行，同样可以完全避免使用unsafe-inline。
不管用哪种方案，都建议先开启report-only模式在线上跑1-2周，收集所有拦截日志调整规则，确认没有误杀之后再开启强制拦截，避免影响正常业务。

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