Next.js 高级架构

Next.js 如何实现 CSP、nonce 和第三方脚本治理？

CSP 不是加一行 Header 就结束，还要解决 nonce 的请求级生成、脚本加载策略、缓存和违规回报。

适合阶段：安全面 / 平台治理核心能力：CSP · Nonce · 第三方依赖

面试官想考什么

• 为什么 nonce 不能写死？ 考察请求级安全。
• 动态 nonce 对静态缓存有什么影响？ 考察安全与性能取舍。
• 第三方分析脚本如何接入？ 考察供应链治理。
• CSP 报错如何收集和修复？ 考察闭环能力。

一句话回答

Nonce 应按请求随机生成并同时用于 CSP Header 和需要执行的内联脚本，不能写死或放到客户端生成；策略要覆盖 Next.js/RSC、第三方脚本和缓存影响，并通过 report-only、违规上报和白名单治理逐步收紧。

面试回答详解

1. CSP 目标

限制脚本来源、对象来源、图片、连接、frame 和 worker，降低 XSS 后的执行与数据外传风险。CSP 是纵深防御，不替代输出转义、依赖审计和权限控制。

2. Nonce 链路

request -> generate cryptographic nonce
-> CSP header -> render approved inline scripts with nonce
-> browser enforces same request policy

nonce 必须不可预测、每次请求不同，并且只授予必要脚本。客户端生成 nonce 无法保护服务端输出。

3. 缓存影响

请求级 nonce 会使响应更难作为公共静态内容缓存。公开内容可以考虑 hash/static CSP 或拆分动态与静态响应；个性化页面不应为了 CDN 命中牺牲 nonce 和数据安全。

4. 第三方脚本

每个域名都要有业务 owner、用途、数据范围和下线机制。使用 next/script 选择合理加载时机，限制 connect-src、img-src 和 frame-src；不要因为某个 SDK 要求 unsafe-eval 就全站放开。

5. 发布和观测

先使用 Content-Security-Policy-Report-Only 收集违规，再逐条修复、灰度和切换 enforce。报告接口脱敏、限流，区分真实攻击、浏览器扩展和误配置。记录 release、route 和 script source，支持快速禁用第三方脚本。

可直接背诵的 30 秒回答

CSP 的重点是建立可执行资源白名单和违规闭环。动态页面按请求生成不可预测 nonce，并同时写入 Header 和受控内联脚本，不能写死或由浏览器生成。第三方脚本按用途、域名和权限治理，先 report-only 再 enforce，同时评估 nonce 对静态缓存的影响，并准备 SDK 下线开关。

扩展知识

nonce 与 hash

• Nonce：适合动态生成的内联脚本，按请求变化。
• Hash：适合内容稳定、可在构建时确定的内联脚本。
• 外部来源白名单：只能限制来源，不能证明第三方脚本本身可信。

面试官追问链

追问一：用了 CSP 就没有 XSS 了吗？

• 考察点：防护边界。
• 回答方向：不是。CSP 是降低影响的纵深防御，仍需安全渲染、依赖治理、服务端校验和权限隔离。

追问二：为什么不直接加 unsafe-inline？

• 考察点：策略质量。
• 回答方向：它会扩大注入后的执行面；优先 nonce/hash，确有兼容性约束时也要限定范围并评估风险。

追问三：CSP 违规突然增多怎么处理？

• 考察点：运维响应。
• 回答方向：按 release/source/route 分类，判断攻击、扩展或发布误配，必要时回滚策略或关闭新增脚本，同时保留证据。

推荐阅读

• Next.js Content Security Policy
• Content Security Policy - MDN
• Next.js Script Component
• Next.js 高级架构