禁用非安全内联脚本并允许受控外部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()"> 等 HTML 事件属性
• <a href="javascript:..."> 类伪协议跳转

因此，策略中必须移除 '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 先灰度运行，收集违规报告，定位残留内联代码