禁用非安全内联脚本并允许受控外部es模块是现代前端安全关键：移除'safe-inline'和'unsafe-eval'，用script-src限制源；type="module"脚本不受内联规则约束，需满足源白名单；初始化数据改用json元数据或动态nonce。
直接禁用非安全内联脚本、同时允许受控的外部 ES 模块，是现代前端安全落地的关键平衡点。核心思路是：用 script-src 切断所有不安全执行路径，再精准放行可信模块脚本——不靠宽松值，而靠机制隔离。
彻底禁用内联脚本与危险执行方式
浏览器将以下三类统一视为“内联脚本”，只要 script-src 中不含 'unsafe-inline' 或有效 nonce/哈希，就会拒绝：
-
<script>alert(1)</script>这类嵌入式脚本块 -
<button onclick="doIt()"></button>等 HTML 事件属性 -
<a href="javascript:..."></a>类伪协议跳转
因此，策略中必须移除 'unsafe-inline' 和 'unsafe-eval' —— 它们不是“可选开关”，而是明确的高危后门。
允许外部 type="module" 脚本的正确写法
ES 模块（<script type="module" src="main.js"></script>）本身不属于内联脚本，它受 script-src 的源限制，而非内联规则约束。只要模块 URL 符合白名单，即可加载：
- 若模块部署在同域：
script-src 'self';已足够 - 若模块来自 CDN（如
https://cdn.example.com/app.mjs）：script-src 'self' https://cdn.example.com; - 模块中 import 的子模块也需满足同一策略，浏览器会逐层校验来源
注意：type="module" 脚本默认为 defer 行为，且具有独立作用域和 CORS 要求，天然比传统脚本更安全可控。
禁用内联但保留必要初始化逻辑的替代方案
业务常需传递初始数据（如用户信息、配置），又不能拼内联脚本。推荐两种安全方式：
-
JSON 元数据 + 外部模块读取：用
<meta name="app-config" content='{"user":"abc"}'>或<script type="application/json" id="init-data">{...}</script>存数据，再由type="module"脚本解析——这类标签不受 CSP 的script-src限制 -
nonce 白名单仅用于极少数必需内联：如服务端渲染首屏 JS，必须用动态生成的 nonce：
Content-Security-Policy: script-src 'self' 'nonce-AbC123';+<script nonce="AbC123">hydrate();</script>，且该 nonce 绝不可复用
验证与调试建议
上线前务必检查实际行为是否符合预期：
- 打开开发者工具 → Console，确认无
Refused to execute inline script误拦（说明策略过严）或漏放（仍有onclick执行） - 查看 Network → Response Headers，确认 CSP 响应头已生效，且不含
'unsafe-inline' - 用
Content-Security-Policy-Report-Only先灰度运行，收集违规报告，定位残留内联代码
