Next.js 13.5静态站点(SSG)中基于哈希的CSP实现问询

1. 如何判断站点是否属于“不需要nonce”的情况？ #

Next.js文档中“不需要nonce”的核心判定标准是：站点所有内联脚本、样式在构建完成后完全固定，不会随用户请求动态变化。

SSG站点天生符合这个条件——因为所有页面都是预渲染生成的静态文件，内联代码在构建阶段就已确定，不存在请求时动态生成的内联内容。官方给出的示例配置用unsafe-inline只是为了兼容绝大多数场景的通用方案，并非“不需要nonce”场景下的严格CSP标准，这也是Lighthouse标记它不安全的原因，和“不需要nonce”的判定逻辑无关。

2. 如何在JS版Next.js SSG中实现基于哈希的严格CSP？ #

按以下步骤操作即可实现符合规范的严格哈希型CSP：

• 步骤1：构建并导出静态站点
  先执行构建命令生成静态文件：

  npm run build && npm run export
  

• 步骤2：提取内联代码的哈希值
  打开生成的静态HTML文件，找出所有内联<script>和<style>的内容，用SHA-256/384/512算法计算哈希，格式为'sha256-xxxxxx'（注意单引号和哈希前的标识）。

  注意：Next.js 13.5的App Router可能会生成 hydration 相关的内联脚本，这类脚本也需要计算哈希。

• 步骤3：配置next.config.js
  替换官方示例中的unsafe-inline为计算好的哈希值，同时移除不必要的unsafe-eval（如果你的代码未使用eval类函数），示例配置如下：

  const cspHeader = `
    default-src 'self';
    script-src 'self' 'sha256-[你的脚本哈希1]' 'sha256-[你的脚本哈希2]';
    style-src 'self' 'sha256-[你的样式哈希]';
    img-src 'self' blob: data:;
    font-src 'self';
    object-src 'none';
    base-uri 'self';
    form-action 'self';
    frame-ancestors 'none';
    upgrade-insecure-requests;
  `;
  
  module.exports = {
    async headers() {
      return [
        {
          source: '/(.*)',
          headers: [
            {
              key: 'Content-Security-Policy',
              value: cspHeader.replace(/\n/g, '').trim(),
            },
          ],
        },
      ];
    },
    output: 'export', // 强制开启SSG静态导出模式
  };
  

• 步骤4：验证与调整
  重新构建部署后，用浏览器控制台或Lighthouse检查CSP是否有违规报错，若有则补充遗漏的内联代码哈希，直到无违规。

3. SSG无法遵循严格CSP？它的安全性价值何在？ #

这是误解，SSG不仅能遵循严格CSP，反而天生适配严格哈希型CSP：

• SSG的预渲染特性决定了所有内联代码固定不变，完美匹配哈希CSP的要求（反而SSR因为可能动态生成内联内容，才需要依赖nonce）。
• SSG的安全性价值体现在：没有服务端运行时，大幅减少服务端攻击面；静态内容部署在CDN上，抗DDoS能力更强；内容预构建完成后不会被动态注入恶意代码。
• 官方文档的示例只是通用兼容配置，并非SSG的最优解，SSG完全可以实现符合Google规范的严格CSP，不存在“安全性无用”的情况。

内容的提问来源于stack exchange，提问作者VanAlbert