本文详解 Stripe v3 加载 hcaptcha-invisible 页面时触发的 CSP “Refused to execute inline script” 报错原因，指出其本质是服务端误配 Content-Security-Policy-Report-Only 响应头所致，并提供安全、合规的修复方案（禁用 Report-Only 模式、使用哈希白名单），避免滥用 'unsafe-inline'。

本文详解 stripe v3 加载 hcaptcha-invisible 页面时触发的 csp “refused to execute inline script” 报错原因，指出其本质是服务端误配 `content-security-policy-report-only` 响应头所致，并提供安全、合规的修复方案（禁用 report-only 模式、使用哈希白名单），避免滥用 `'unsafe-inline'`。

该错误看似发生在前端集成 Stripe 时，实则根源在服务端 Content Security Policy（CSP）的配置策略上。关键线索藏在报错信息末尾的 [Report Only] —— 这明确表明浏览器正在以只报告不阻断（Content-Security-Policy-Report-Only）模式执行策略，而非真正生效的 Content-Security-Policy。因此，即使你通过 标签添加了宽松策略（如包含 'unsafe-inline'），它也无法覆盖或绕过已存在的 HTTP 响应头策略，因为浏览器要求所有 CSP 规则必须同时满足（“all policies must pass”）。

⚠️ 重要澄清：无法作用于第三方资源（如 js.stripe.com 域下的 hcaptcha-invisible-*.html）。该 HTML 文件由 Stripe 服务器动态生成并返回，其执行环境受 Stripe 自身响应头控制，而非你的页面 。你在自己页面中设置的 CSP 只约束你域下加载的脚本、样式等资源，对跨域 iframe 或嵌入内容无管辖权。

真正需要排查和修改的是：你的后端服务器（或 CDN、反向代理如 Nginx/Apache）是否错误地为所有响应（包括 HTML 页面）设置了 Content-Security-Policy-Report-Only 响应头？ 例如：

Content-Security-Policy-Report-Only: script-src 'self';

✅ 正确做法是：

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

1. 定位并移除 Content-Security-Policy-Report-Only 头，改用标准 Content-Security-Policy；
2. 若需允许 Stripe 的特定内联脚本（如 hcaptcha-invisible 中的初始化代码），优先采用哈希白名单（Hash-based allowlist），而非 'unsafe-inline'：

Content-Security-Policy: script-src 'self' js.stripe.com 'sha256-CBu0w5uiOaPgb2R6Zgf7E0+STJHF4lcPIdhZzQXE6yk=';

该哈希值（sha256-...）已在报错信息中明确给出，对应 Stripe 当前版本中该内联脚本的精确内容。只要 Stripe 不更新该内联代码，此哈希即长期有效。若未来 Stripe 升级导致哈希失效，浏览器会再次报错并提示新哈希，便于及时更新。

❌ 错误尝试示例（应避免）：

• 在 中添加 ：既无效（不作用于 Stripe 资源），又严重削弱安全性；
• 试图在前端 JS 中动态注入 <script> 标签绕过：CSP 在解析阶段即拦截，JS 无法干预。</script>

? 总结：该问题不是 Stripe 集成缺陷，而是 CSP 策略配置不当引发的误报/误阻。修复核心在于——统一策略入口（服务端响应头）、关闭 Report-Only 模式、对必要内联脚本使用哈希授权。这既保障了应用安全性，又确保了 Stripe 无感集成的稳定性。