跨站脚本攻击（XSS）一直是Web安全里最常见的漏洞类型，而内容安全策略（Content Security Policy，简称CSP）正是浏览器层面抵御XSS的最后一道防线。不过React开发者在实际落地CSP时常常发现，一旦加上严格策略，页面直接白屏、样式全部丢失，控制台里全是“Refused to execute inline script”这类报错。这背后的根源在于React生态大量依赖内联脚本和内联样式，而CSP默认恰恰禁止内联内容。本文将系统讲解CSP的核心指令、冲突产生的原因以及几种成熟的解决方案。
CSP核心指令与React应用的冲突点
CSP本质上是服务器通过HTTP响应头（或meta标签）下发给浏览器的一份白名单，浏览器会严格按照白名单决定哪些资源可以加载、哪些脚本可以执行。常用的指令包括script-src（控制脚本来源）、style-src（控制样式来源）、img-src、connect-src（限制fetch和XHR的目标地址）等。如果服务器返回了script-src指令，那么所有不符合规则的脚本都会被拦截，包括内联脚本。
冲突的第一个来源是打包工具的产物。以create-react-app为例，构建出的index.html里通常会有一段内联的引导脚本，比如用于设置%PUBLIC_URL%环境变量的代码。Vite虽然默认不注入内联脚本，但一旦启用PWA插件或某些压缩配置，同样会出现内联块。第二个来源是运行时样式注入：styled-components、emotion这类CSS-in-JS方案会动态生成<style>标签插入到DOM中，这属于典型的内联样式，会被style-src拦截。
第三个来源容易被忽视：React自身的JSX style属性其实是操作DOM节点的style属性，不受CSP的style-src指令限制，受限制的是<style>标签和style属性选择器注入。理解这个区别能帮你避免做无用的配置调整。简单验证方法是在控制台查看报错，如果提示的是style-src相关的inline违规，基本可以确定是CSS-in-JS库的问题。
方案一：使用nonce放行内联脚本
nonce（一次性随机数）是解决内联脚本冲突最主流的方式。它的原理是服务器为每个请求生成一个随机字符串，同时写进CSP响应头和HTML中的script标签，浏览器只执行nonce匹配的内联脚本。由于每次请求nonce都不同，攻击者即使能注入脚本，也无法预知合法的nonce值，安全性得以保留。
在Node.js和Express环境下实现比较直接，核心代码如下：
const crypto = require('crypto');
app.use((req, res, next) => {
// 每个请求生成16字节的随机数，转成base64
const nonce = crypto.randomBytes(16).toString('base64');
res.locals.nonce = nonce;
// 将nonce写入CSP响应头
res.setHeader('Content-Security-Policy',
`default-src 'self'; script-src 'self' 'nonce-${nonce}'; style-src 'self' 'nonce-${nonce}'`
);
next();
});
app.get('*', (req, res) => {
// 渲染时把nonce注入到模板中的script和style标签
res.render('index', { nonce: res.locals.nonce });
});
前端模板里对应的script标签要加上nonce属性：
<script nonce="{{nonce}}">
window.__INITIAL_STATE__ = {};
</script>
nonce方案有个前提：HTML必须由服务端动态渲染或至少经过服务端处理。如果你的React应用是纯静态部署（比如直接扔到CDN或对象存储上），服务器没有机会给每个请求生成随机数，nonce就不适用了，这时候应该考虑哈希方案。
方案二：哈希值与静态部署的适配
哈希方案的思路是对固定的内联脚本内容计算SHA256哈希，把哈希值写进CSP头。只要脚本内容不变，哈希就不会变，非常适合内容固定的静态资源。计算方法也很简单，在浏览器控制台看到违规报错时，Chrome会直接提示该脚本对应的哈希值，可以直接复制使用：
script-src 'self' 'sha256-abcdefgh123456...';
需要注意的是，哈希只对字节级一致的内容有效。如果构建工具在压缩时对脚本做了细微改动，哈希就会失效，每次发版都要重新计算并更新CSP配置。为降低维护成本，可以把计算哈希这一步集成进CI流程：构建完成后自动提取内联脚本、计算哈希、生成CSP配置文件，再交给Nginx加载。不少团队用csp-html-webpack-plugin插件在构建阶段自动完成这件事。
对于styled-components注入的动态样式，哈希方案处理起来比较麻烦，因为类名和样式内容包含随机成分。更实际的做法是放宽style-src的粒度，例如允许style-src 'self' 'unsafe-inline'。听起来不太安全，但实际上style注入的危害远低于脚本注入，绝大多数安全团队会接受这个折中。若项目要求非常严格，可以考虑迁移到构建期提取静态CSS的方案，比如Linaria或Vite自带的CSS代码分割。
Nginx配置与调试实践
生产环境通常在反向代理层统一配置CSP。以下是一份适配React应用、允许nonce透传的Nginx配置片段：
server {
listen 443 ssl;
server_name example.ipipp.com;
# 由上游Node服务返回CSP头，Nginx默认透传
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
}
# 静态资源走更宽松的策略
location ~* \.(js|css|woff2)$ {
add_header Content-Security-Policy "default-src 'self'";
expires 30d;
}
}
上线前务必先用Content-Security-Policy-Report-Only响应头跑一段时间。这个模式下浏览器只记录违规但不拦截，配合report-uri或report-to指令把违规日志上报到后端，可以完整评估策略影响范围。等报告里不再出现误伤再切换到强制模式，这是最稳妥的落地节奏。
最后总结几条实践经验：CSP头越具体越好，避免大而全的宽松配置；default-src 'self'作为兜底，再按需开放connect-src、img-src；对于RSC或SSR框架，nonce要在服务端注入到React的helmet或框架API中，而不是手动改模板。排查问题时打开Chrome控制台的过滤条件，搜索"Content Security Policy"关键字，每一行违规报错都会明确指出违反的指令和资源地址，按图索骥即可快速定位。