CSRF 与 CSP

• script-src nonce-source
• script-src hash-source
• 适用场景

CSP 的 script-src 'nonce-xxx' 允许带指定 nonce 的内联脚本执行，'sha256-xxx' 允许哈希匹配的内联脚本。nonce：每次响应生成随机 nonce，浏览器比对脚本的 nonce 属性，用于动态内联脚本；hash：内联脚本内容的哈希，静态校验，无需服务端随机。工程应用：nonce 适合动态生成的内联脚本（需服务端每次生成），hash 适合固定的内联脚本（构建产物）。取舍：nonce 灵活但需服务端支持，hash 稳定但内容变需更新。现代配合 strict-dynamic 传递信任。工程上两者选一或结合，避免 unsafe-inline。

nonce 与 hash 是 CSP 允许内联脚本的安全方式。nonce 动态、hash 静态。它们避免 unsafe-inline，配合 strict-dynamic 是现代 CSP 最佳实践。

• Privacy Sandbox 目标
• 跨域隔离（COOP/COEP）
• 与隐私 API 的关系

Privacy Sandbox 是 Google 提出的面向隐私的浏览器功能集，目标是在不依赖第三方 Cookie 的情况下实现广告、归因、防欺诈等。跨域隔离（COOP/COEP）是其中的安全基础：COOP/COEP 开启跨域隔离，提供 SharedArrayBuffer 等能力，也是隐私沙箱某些 API（如 Fenced Frames、Shared Storage）的安全前提。Privacy Sandbox 的组件（Topics API、Protected Audience、Attribution Reporting、Fenced Frames、Shared Storage）与跨域隔离配合，实现隐私友好的广告与归因。工程价值：跨域隔离是隐私沙箱的安全边界，限制了跨源数据共享。

Privacy Sandbox 提供隐私友好的广告/归因 API，跨域隔离（COOP/COEP）是其安全基础，提供 SharedArrayBuffer 等能力并限制跨源数据。工程上部署 COOP/COEP 以支持隐私沙箱。

• Trusted Types 强制机制
• require-trusted-types-for
• 防 DOM XSS

Trusted Types 的强制策略：CSP 的 require-trusted-types-for 'script' 开启后，DOM 注入 API（innerHTML、script.src、iframe.src 等）必须使用 Trusted Types 策略创建的值（TrustedHTML/TrustedScript/TrustedScriptURL），否则抛错。这从机制上阻止"不可信字符串直接注入 DOM"，是防 DOM XSS 的强制手段。工程实践：创建策略（createPolicy）定义可信值来源，用 DOMPurify 净化 createHTML，配置 CSP 开启。强制策略的取舍：需改造现有代码（包装 DOM 操作），但极大提升 XSS 防护。配合 trusted-types 指令限制策略名。

Trusted Types 强制策略通过 require-trusted-types-for 让 DOM 注入必须经策略，阻止字符串注入。配合 createPolicy 与 DOMPurify，是 DOM XSS 的强防御。需改造代码。

• Referrer-Policy 各值
• strict-origin-when-cross-origin 语义
• referer 泄露防护

Referrer-Policy: strict-origin-when-cross-origin 规定：同源请求发送完整 URL，跨源请求只发送 origin（不发送路径与查询参数），HTTPS→HTTP 降级时不发送 referer。这是安全的默认策略，防止跨源请求泄露完整 URL（含路径、查询参数、敏感信息）。工程价值：减少 referer 泄露（跨源时只暴露 origin），保护隐私与安全。相比 no-referrer（完全不发送）更实用，相比 unsafe-url（全发）更安全。工程实践：设置该策略（或更严格），防止敏感参数泄露到第三方。

strict-origin-when-cross-origin 跨源只发 origin，防查询参数泄露，是推荐的默认策略。工程价值是防 referer 泄露，同时保留同源完整 URL。

• defaultPolicy 与 createPolicy
• 策略创建与回退
• 工程应用

Trusted Types 中 createPolicy(name, factory) 创建命名策略，defaultPolicy 是无名策略（只能创建一个），用于未指定策略的注入。策略工厂定义 createHTML/createScript/createScriptURL 等回调。defaultPolicy 是兜底：当代码未指定策略时用 defaultPolicy（若存在）。工程应用：创建 defaultPolicy 处理遗留注入（如 DOMPurify 净化），用 createPolicy 按用途创建策略（app-html、app-script）。取舍：defaultPolicy 兜底便利但可能放宽，命名的 createPolicy 更可控。CSP 的 trusted-types 指令限制允许的策略名。

createPolicy 创建命名策略，defaultPolicy 是兜底策略。defaultPolicy 处理未指定注入，createPolicy 提供细粒度控制。工程上结合用，配合 CSP 白名单。

• COOP 隔离窗口
• Spectre 侧信道
• 协作防护

COOP（Cross-Origin-Opener-Policy）控制页面与跨源 opener 的关系，same-origin 使页面与跨源窗口隔离，切断 window.opener 引用。这与 Spectre 侧信道防护协作：Spectre 利用高精度计时与推测执行读取跨源数据，跨源隔离（COOP+COEP）配合可隔离跨源窗口，减少侧信道攻击面。COOP 隔离窗口防止跨源窗口通过 opener 访问，COEP 限制跨源资源，共同为 Spectre 防护提供"进程隔离"基础。工程价值：COOP 是跨源隔离的一部分，配合 COEP 降低 Spectre 风险，并启用 SharedArrayBuffer 等能力。

COOP 隔离窗口与跨源 opener，配合 COEP 形成跨源隔离，是 Spectre 侧信道防护的基础。COOP 减少跨源窗口访问，COEP 限制资源，共同降低侧信道面。

• Private State Tokens 防欺诈
• DPoP 证明 token 持有
• 与 CSRF/身份

Private State Tokens 是 Privacy Sandbox 的防欺诈机制，用匿名令牌证明"用户曾通过某平台验证"，不暴露身份，用于反欺诈（防滥用、防机器人）。DPoP（RFC 9449，Demonstrating Proof-of-Possession）通过 DPoP 的 JWT 绑定请求与密钥，证明请求持有某个 token 对应的私钥，防止 token 被重放/盗用。两者与 CSRF/身份：DPoP 加强 token 的持有证明（防 token 注入/重放），Private State Tokens 匿名防欺诈。工程价值：DPoP 强化 OAuth 安全，Private State Tokens 提供隐私友好反欺诈。取舍：DPoP 增加握手与密钥管理。

DPoP 证明 token 持有（防重放/盗用），Private State Tokens 匿名防欺诈（隐私友好）。两者是不同的安全机制，DPoP 强化身份令牌，Private State Tokens 强化反欺诈。

• nonce-source 允许内联脚本
• strict-dynamic 信任传递
• 内联脚本控制

CSP 的 script-src 'nonce-xxx' 允许带 nonce 的内联脚本，strict-dynamic 让被 nonce 允许的脚本动态加载的脚本也获得信任（信任传递）。工程价值：现代应用的内联脚本（如构建产物、事件处理）用 nonce 控制，strict-dynamic 让动态加载的模块脚本无需在 CSP 列信任域名，避免通配符。内联脚本控制：nonce 允许特定内联脚本，strict-dynamic 传递信任，避免 unsafe-inline 与 unsafe-eval。取舍：需服务端生成 nonce，配合 strict-dynamic 减少 CSP 维护。这是现代 CSP 的内联脚本安全控制。

nonce 控制内联脚本，strict-dynamic 传递信任给动态加载脚本。两者结合避免通配符域名与 unsafe-inline，是现代 CSP 内联脚本控制的核心。

• require-trusted-types-for 强制
• 部署阶段
• 兼容与安全

Trusted Types 强制策略通过 CSP 的 require-trusted-types-for 'script' 强制 DOM 注入必须用 Trusted Types。部署策略：1) 先只启用 trusted-types 允许策略名（不强制），观察违规；2) 用 report-only 收集违规（require-trusted-types-for 通过 report 观察）；3) 修复违规（创建策略、改造 DOM 操作）；4) 强制启用（强制注入用 Trusted Types）。取舍：强制提升安全但需改造代码，分阶段部署。工程价值：渐进实施 Trusted Types，避免中断。配合 CSP 的 report 上报违规。

Trusted Types 强制部署是"先观察后强制"。用 report-only 收集违规，修复后再强制。分阶段部署减少中断，最终提升 DOM XSS 防护。

• HTTPS 加密
• HSTS 强制 HTTPS
• 防降级/中间人

HTTPS 加密传输，HSTS（Strict-Transport-Security）响应头 Strict-Transport-Security: max-age=...; includeSubDomains 让浏览器在指定时间内强制使用 HTTPS，禁止降级到 HTTP。工程价值：防止 SSL 剥离攻击（中间人把 HTTPS 降级为 HTTP）、防 HSTS 绕过、保证全站 HTTPS。首次访问 HTTPS 后才生效（HSTS preload 可提前）。工程实践：全站 HTTPS + HSTS + HSTS preload list。取舍：HSTS 强制 HTTPS 但需确保证书正确，preload 有提交门槛。工程价值是防中间人降级。

HSTS 强制浏览器用 HTTPS，防降级与中间人。首次访问后生效，preload 可提前。工程价值是防 SSL 剥离，保证网络安全。

• CSRF Token 原理
• Synchronizer Token Pattern
• Double-Submit Cookie

CSRF Token 防御：服务端生成随机 token，随请求（表单/请求头）携带，服务端校验。Synchronizer Token Pattern：服务端把 token 存在会话，页面携带 token，提交时服务端比对会话 token，是最标准的模式。Double-Submit Cookie：token 同时放在 Cookie 与请求参数/头，服务端校验两者是否一致（无需会话存储），但若子域可写 Cookie 则可能被绕过。工程取舍：Synchronizer 更安全（会话存储），但需服务端状态；Double-Submit 无状态但需 Cookie 安全。现代常配合 SameSite Cookie 与自定义头。工程价值：防 CSRF。

CSRF Token 是"服务端校验随机 token"。Synchronizer 用会话存储 token，Double-Submit 用 Cookie+请求双提交对比。取舍是会话状态 vs 无状态、安全 vs 简单。

• crypto.subtle 的算法
• 对称/非对称/派生/签名
• 工程应用

Web Crypto API（crypto.subtle）提供密码学能力：对称加密（AES-GCM）、非对称（RSA-OAEP、ECDH）、密钥派生（PBKDF2、HKDF）、签名（HMAC、RSA-PSS、ECDSA、Ed25519）。工程价值：前端加密/签名/密钥协商，无需引入加密库。应用：端到端加密（数据加密）、密钥派生（从口令派生密钥）、签名验证（验签）、随机数（crypto.getRandomValues）。需 Secure Context。取舍：crypto.subtle 是异步、安全（不可导出密钥），但需理解算法。工程价值：前端密码学能力。

crypto.subtle 提供对称/非对称/派生/签名等密码学能力。工程价值是前端加密、签名、密钥协商。需 Secure Context，算法选择需安全。

• TLS 1.2 握手（2-RTT）
• TLS 1.3 握手（1-RTT/0-RTT）
• 安全与性能差异

TLS 1.2 握手通常 2-RTT（ClientHello→ServerHello/证书→密钥交换→finish），需多次往返；TLS 1.3 握手 1-RTT（ClientHello 携带密钥就绪，ServerHello 后一个往返完成），恢复会话时 0-RTT。TLS 1.3 移除不安全算法（RC4、SHA-1、静态 RSA），强制前向安全（ECDHE），简化握手。差异：1.3 更快（1-RTT/0-RTT）、更安全（前向安全、移除弱算法）、更简单。工程价值：TLS 1.3 减少握手延迟，提升 HTTPS 性能，同时更安全。服务端需启用 TLS 1.3。

TLS 1.3 相比 1.2：握手从 2-RTT 减到 1-RTT（0-RTT 恢复）、移除弱算法、强制前向安全。工程价值是性能与安全双提升。

• QUIC 0-RTT 重放风险
• Early Hints 103
• 工程取舍

QUIC 的 0-RTT 在恢复会话时首包即携带数据，省 RTT，但有重放风险（攻击者重放 0-RTT 数据，服务端未完成握手无法区分），因此 0-RTT 只适合幂等请求。Early Hints（103）是 HTTP 层在最终响应前发送 103 携带 preload 提示，与 0-RTT 不同：103 是"提示"，仍由浏览器主动请求，无重放副作用。关系：两者都用于减少首屏延迟，但 0-RTT 有重放风险需限制，Early Hints 无风险。工程取舍：0-RTT 用于建连加速（幂等），Early Hints 用于资源加载提前。工程上对 0-RTT 限制应用，Early Hints 安全使用。

0-RTT 省 RTT 但有重放风险（仅幂等），Early Hints 103 提前提示资源加载无副作用。两者都减延迟，但安全语义不同。工程上 0-RTT 受限、Early Hints 安全。

• TLS 1.3 1-RTT 握手
• 减少建连延迟
• 大型应用性能

TLS 1.3 的 1-RTT 握手相比 TLS 1.2 的 2-RTT 减少一个往返，显著降低建连延迟。对大型应用（大量 HTTPS 请求、移动用户、弱网），减少建连 RTT 直接提升 TTFB 与首屏性能。配合 HTTP/2/3、0-RTT、连接复用，进一步降低延迟。工程价值：HTTPS 建连更快，尤其对移动弱网与高 HTTPS 请求量场景。服务端启用 TLS 1.3，CDN 支持。取舍：1-RTT 已很快，0-RTT 更快但有重放风险。工程上大型应用应启用 TLS 1.3 并用连接复用。

TLS 1.3 1-RTT 减少建连往返，提升大型应用 HTTPS 性能。配合连接复用与 0-RTT 进一步优化。工程价值是降低 TTFB。

• HTTPS-only 强制
• 混合内容（HTTP 资源）
• 防护

HTTPS-only 约束页面必须使用 HTTPS，浏览器会阻止/警告混合内容（Mixed Content）：HTTPS 页面加载 HTTP 资源。混合内容分两类：主动混合内容（脚本、iframe、CSS 等，会被浏览器阻止）与被动混合内容（图片、音视频，可能被警告或在 Chrome 中升级为 HTTPS）。防护：页面内所有资源用 HTTPS（相对协议 // 或绝对 HTTPS）、服务端配置 HSTS、CSP 的 upgrade-insecure-requests 强制升级 HTTP 请求到 HTTPS。工程价值：保证全站 HTTPS，防中间人窃听主动内容。工程上全站 HTTPS + upgrade-insecure-requests。

混合内容是 HTTPS 页面加载 HTTP 资源，主动内容被阻止。防护是资源全 HTTPS + HSTS + upgrade-insecure-requests。工程价值是防降级与窃听。

• AES-GCM 对称加密
• SHA-256 哈希
• Ed25519 签名

Web Crypto 的安全算法：AES-GCM（对称加密，带认证，当前推荐）、SHA-256（哈希，安全）、Ed25519（EdDSA 签名，现代安全）。安全生命周期：算法会过时，需跟踪推荐（如 SHA-1 已弃用，RSA 密钥长度要求提高）。AES-GCM 用于数据加密（需随机 IV），SHA-256 用于完整性/派生，Ed25519 用于签名（现代、高性能）。工程价值：选用安全算法，避免弃用算法（如 SHA-1、RC4）。密钥生命周期：生成、使用、轮换、销毁。取舍：算法选择影响安全与性能。

Web Crypto 安全生命周期是"选安全算法 + 密钥轮换"。AES-GCM 加密、SHA-256 哈希、Ed25519 签名是当前安全选择。需跟踪算法弃用与密钥轮换。

• Passkeys/WebAuthn 机制
• 抗钓鱼（公钥、来源绑定）
• 登录流程取舍

Passkeys 基于 WebAuthn/FIDO2，用公钥密码学替代密码：设备生成密钥对，私钥保存在设备（受保护），公钥注册到服务器，登录时设备签名挑战，服务器验签。抗钓鱼：私钥不离开设备、绑定来源（origin）、不发送密码，钓鱼攻击者无法重放凭据。工程取舍：替代密码与令牌，更安全（抗钓鱼、防破解）、用户体验好（生物识别）；但需设备支持、跨设备同步（需平台支持）、有恢复流程。登录流程：注册（生成密钥对）、认证（签名挑战）。工程价值：无密码登录、抗钓鱼。

Passkeys 用公钥密码学实现无密码登录，私钥在设备、绑定 origin，抗钓鱼。取舍是安全/体验 vs 设备依赖与恢复。是登录流程的现代替代。

• crypto.randomUUID
• crypto.getRandomValues
• 安全随机数

crypto.randomUUID() 生成 RFC 4122 的 UUID（v4），crypto.getRandomValues() 填充加密安全的随机字节。两者都是加密安全随机数（CSPRNG），用于生成 ID、token、nonce、密钥等。工程价值：避免用 Math.random（非加密安全，可预测）生成安全相关值。应用：生成请求 ID、防重放 nonce、CSRF token、会话标识。取舍：randomUUID 简单（UUID），getRandomValues 灵活（任意字节）。工程价值：安全随机数生成，防预测。

crypto.randomUUID/getRandomValues 是加密安全随机数，用于 ID/token/nonce。避免 Math.random（可预测）。工程价值是安全随机数生成。

• 抗量子密码（PQC）
• ML-KEM/ML-DSA/SLH-DSA
• 混合密钥交换

抗量子密码学（PQC）应对量子计算机对传统密码的威胁。ML-KEM（CRYSTALS-Kyber，密钥封装）、ML-DSA（CRYSTALS-Dilithium，签名）、SLH-DSA（SPHINCS+，哈希签名）是标准化算法。浏览器混合密钥交换：在 TLS 握手中结合传统（如 ECDHE）与 PQC（ML-KEM）密钥交换，即使量子攻击破解传统或 PQC 之一，仍安全（混合）。工程价值：为未来量子威胁做准备。取舍：PQC 密钥/签名更大、性能开销，混合信任。浏览器支持逐步加入。工程上关注支持与兼容。

抗量子密码用 ML-KEM/ML-DSA/SLH-DSA 应对量子威胁。混合密钥交换结合传统与 PQC，防御量子攻击。工程价值是前瞻安全，取舍是开销与兼容。

• DoH 加密 DNS
• CDN/边缘缓存
• 工程价值

DoH（DNS over HTTPS）加密 DNS 查询，防窃听与篡改。在 CDN/边缘缓存场景，DoH 与 CDN 协作：浏览器用 DoH 解析域名，获得 CDN 节点 IP；DoH 防止 DNS 被劫持/污染，确保解析到正确的 CDN 节点。工程价值：DoH 提升 DNS 安全与稳定性，避免 DNS 污染导致 CDN 接入错误；与 CDN 的 GSLB/Anycast 配合。取舍：DoH 走 HTTPS（443 端口），可能被防火墙针对；与 CDN 的解析策略需协调。工程价值：安全解析 + 正确 CDN 接入。

DoH 加密 DNS 防劫持/污染，保障解析到正确 CDN 节点。工程价值是安全与稳定，与 CDN 的节点选择配合。取舍是隐蔽性与兼容。

• Double Submit Cookie
• 自定义 Header（X-Requested-With）
• 防御组合

双重 Cookie 提交（Double Submit Cookie）：服务端设置随机 token 的 Cookie，前端在请求参数/自定义头中带上相同 token，服务端校验 Cookie 与请求中 token 是否一致。自定义 Header 防御：要求请求带自定义头（如 X-Requested-With），因为跨站请求无法获取/设置自定义头（需 CORS 配置），从而防御 CSRF。组合：双重 Cookie 校验 + 自定义头 + SameSite。取舍：双重 Cookie 无状态（服务器不存 token）但需 Cookie 安全；自定义头需前端配合。工程价值：多层 CSRF 防御。

双重 Cookie 校验 token 一致性，自定义头因跨站无法设置而防 CSRF。组合 SameSite 形成纵深防御。取舍是无状态 vs 前端配合。

• OCSP Stapling 机制
• 证书吊销状态
• 性能与安全

OCSP Stapling：服务器在 TLS 握手中附带证书的 OCSP 响应（证明证书未吊销），客户端无需额外访问 OCSP 服务器。工程价值：1) 性能——避免客户端单独查询 OCSP 服务器（减少往返与故障）；2) 安全——提供证书吊销状态（防使用已吊销证书）。大型前端项目（大量 HTTPS 连接）启用 OCSP Stapling 减少握手延迟与 OCSP 依赖。取舍：需服务器配置 OCSP 响应的缓存与更新；若 OCSP 服务器不可用，Stapling 可能失败。工程价值：提升握手性能与证书安全。

OCSP Stapling 在握手中附带证书吊销状态，减少客户端 OCSP 查询。工程价值是性能（少往返）与安全（吊销状态）。需服务器配置。

• Origin/Referer 头
• 同源策略
• 服务端校验

Origin/Referer 头由浏览器添加，携带请求来源。服务端校验 Origin/Referer 判断请求是否来自可信来源（防 CSRF）。同源策略（SOP）是浏览器侧的读取限制，Origin/Referer 校验是服务端侧的来源校验。两者关系：SOP 限制浏览器跨源读取，Origin/Referer 是服务端判断请求来源的依据。工程价值：服务端校验 Origin（可信来源白名单）防 CSRF；SOP 是浏览器基础。注意 Origin/Referer 可被伪造（非浏览器），是辅助手段。工程上用 Origin 校验 + SameSite + Token。

SOP 是浏览器读取限制，Origin/Referer 是服务端来源校验。服务端校验 Origin 防 CSRF，但需配合 SameSite/Token。两者是不同层级的防护。

• Same-Origin（协议+域名+端口）
• Schemeless Same-Site（仅站点）
• 现代策略差异

Same-Origin 要求协议、域名、端口完全相同（严格）；Schemeless Same-Site 只看"站点"（eTLD+1，忽略协议与子域）。现代浏览器策略：Cookie 的 SameSite 属性基于 Same-Site（站点），而非 Same-Origin；SOP 的 DOM/数据访问基于 Same-Origin。差异：https://a.com 与 http://a.com 是不同 Origin 但同 Site；https://a.com 与 https://b.a.com 是不同 Origin 但同 Site。工程价值：理解差异才能正确配置 Cookie 的 SameSite 与跨域策略。Schemeless Same-Site 忽略协议，HTTP 与 HTTPS 同站，需注意安全影响。

Same-Origin 严格（协议+域名+端口），Schemeless Same-Site 宽松（仅站点）。Cookie 的 SameSite 基于站点，SOP 基于源。理解差异是正确配置跨域/Cookie 的关键。

• Origin/Referer 校验
• 局限性
• 组合防御

Origin/Referer 头校验是 CSRF 防护的手段：服务端校验请求的 Origin/Referer 是否可信，拒绝跨站请求。工程价值：识别跨站请求来源，是 CSRF 的防线。但存在局限：1) 头可被伪造（非浏览器环境）；2) 某些情况 Referer 被策略清空（隐私）；3) 浏览器兼容性差异。因此不作为唯一手段——需与 CSRF Token、SameSite Cookie 组合。工程实践：Origin 校验（优先）+ SameSite + Token，形成纵深防御。取舍：Origin 校验简单但不可靠，需组合。

Origin/Referer 校验是 CSRF 辅助防线，但可被伪造/缺失，故需与 Token、SameSite 组合。工程价值是纵深防御的一部分，不作为唯一依据。

• CSRF 与 CORS 的关系
• CORS 配置的边界
• 防 CSRF

CSRF 与 CORS 相关但不同：CORS 控制浏览器跨源读取，CSRF 是跨站利用合法请求。CORS 配置不当可能扩大 CSRF 面：若 Access-Control-Allow-Origin 允许任意源（*）且带凭据，跨站可读取响应；若配置过宽，攻击者可跨站请求。但 CORS 本身不直接防 CSRF（CSRF 是简单请求无需 CORS）。边界：CORS 控制"读取"与"预检"，CSRF 靠 SameSite、Token、Origin 校验。工程取舍：CORS 白名单精确（不滥用 * 带凭据），CSRF 靠 Token/SameSite。两者互补。

CORS 控制跨源读取，CSRF 靠 SameSite/Token/Origin 防御。CORS 配置过宽（*+凭据）扩大风险，需精确白名单。两者是不同层级，互补出于安全。

• report-uri 与 report-to
• Reporting API
• CSP 违规上报

CSP 的 report-uri（旧）与 report-to（新，Reporting API）让浏览器上报违规事件。report-to 是 Reporting API 的一部分，支持 Report-To 头配置端点，多个报告类型（CSP、COEP、Permissions-Policy）。工程价值：收集 CSP 违规报告，监控策略是否生效、发现绕过与漏网、渐进部署（report-only）。取舍：report-to 现代、可扩展，report-uri 旧。工程实践：配置 report-to 端点，聚合分析违规，用于 CSP 调整与安全监控。

report-to（Reporting API）上报 CSP 违规，替代 report-uri。工程价值是监控策略、发现绕过、渐进部署。report-to 更现代可扩展。

• Angular 默认启用
• React 实验支持
• 框架集成

Trusted Types 在现代框架集成：Angular 默认启用 Trusted Types（对 DomSanitizer 的返回值用 Trusted Types，innerHTML 需经安全管道），React 的 Trusted Types 支持是实验性的（react-dom 提供 TrustedTypesUtil）。工程价值：框架层集成 Trusted Types，让 DOM 注入默认走安全策略。取舍：Angular 默认启用（安全但需适配），React 实验（需自行集成）。工程实践：按框架启用，配置 createPolicy，配合 DOMPurify。工程价值：框架级 XSS 防护。

Angular 默认启用 Trusted Types，React 实验支持。框架集成让 DOM 注入默认走策略。工程价值是框架级安全，取舍取决于框架支持度。

• script-src 脚本来源
• style-src 样式来源
• frame-ancestors 防嵌入

CSP 关键指令：script-src 限制脚本来源（nonce/hash/白名单，防 XSS）；style-src 限制样式来源（防样式注入）；frame-ancestors 限制可嵌入本页的 iframe 来源（防点击劫持）；connect-src 限制连接来源（fetch/XHR/WebSocket，防数据外传）。配置：script-src 'self' 'nonce-xxx'、style-src 'self'、frame-ancestors 'self'、connect-src 'self' https://api.example.com。工程价值：精细控制资源来源，防 XSS、防点击劫持、防数据外传。取舍：需平衡严格与功能（域名白名单）。

CSP 各指令控制不同资源：script-src 防脚本注入、style-src 防样式注入、frame-ancestors 防点击劫持、connect-src 防数据外传。工程价值是精细化资源控制。

• SameSite=None 的兼容性陷阱
• 旧浏览器/WebView 的隐式 Strict
• 调试定位

SameSite=None 兼容性陷阱：部分旧浏览器/移动端 WebView 不认识 SameSite=None，会把它当作不设置（隐式默认），可能按 Strict 处理，导致跨站 iframe 的 Cookie 不发送。受影响的如旧版 iOS Safari、某些 Android WebView、旧浏览器。调试：DevTools Application 面板查看 Cookie 的 SameSite 属性与实际发送；Network 面板查看请求是否携带 Cookie；Charles 抓包看请求头 Cookie 与响应 Set-Cookie。差异定位：在 DevTools 中检查 Cookie 生效与发送，用 Charles 抓包对比不同环境的 Cookie 行为。工程上对 SameSite=None 需兼容处理（如 UA 检测、降级）。

SameSite=None 在旧浏览器被当隐式 Strict，导致跨站 Cookie 不发送。调试用 DevTools 看 Cookie 状态与请求，Charles 抓包对比。工程上需兼容降级。

• Double Submit Cookie 机制
• 无状态校验
• 安全边界

Double Submit Cookie 模式：服务端在 Cookie 中设置随机 token，前端在请求参数/自定义头中携带相同 token，服务端校验 Cookie 与请求中的 token 是否一致。若无状态（服务端不存 token），只需校验一致性。优点：无状态、简单、适合分布式。安全边界：若攻击者能写子域 Cookie（如子域 XSS），可设置与请求一致的 token 绕过；需 Cookie 的 Secure/HttpOnly 与子域安全。工程取舍：无状态便利 vs 子域风险。工程上用 Double Submit + 自定义头 + 校验域隔离。

Double Submit Cookie 是"Cookie 与请求双提交对比"。无状态但需 Cookie 安全（子域可写风险）。工程上配合自定义头与子域隔离。

• Sec-Fetch-* 头
• 兼容旧浏览器
• Referer 清空时的判断

Sec-Fetch-Site/Mode/Dest 由浏览器自动添加，描述请求上下文。CSRF 防御中：服务端可校验 Sec-Fetch-Site（cross-site 请求可疑）、Sec-Fetch-Mode、Sec-Fetch-Dest。但旧浏览器不发送这些头，需兼容：Sec-Fetch-* 缺失时不拒绝（或降级到其他校验）。当 Sec-Fetch-Site = same-origin 但 Referer 被严格策略清空时，应以 Sec-Fetch-Site 为准（它是浏览器主动提供的、更可靠，且 same-origin 表示同源请求，可信）；Referer 缺失是隐私策略导致，不应误判。减少 false positive：优先信任 Sec-Fetch-Site，Referer 缺失不视为异常。

Sec-Fetch-* 是浏览器提供的可靠上下文，same-origin 可信。Referer 被隐私策略清空是正常，不应误判。兼容旧浏览器需处理头缺失。工程上以 Sec-Fetch-Site 为准。

• unsafe-hashes 指令
• 事件处理器（onclick）
• 取舍

CSP 的 unsafe-hashes 允许内联事件处理器（如 onclick）脚本，但这些脚本的哈希需匹配。它是"允许特定事件处理器内联脚本"的机制，比 unsafe-inline 更严格（只允许哈希匹配的）。工程取舍：onclick 等内联事件处理器是 CSP 常见问题，unsafe-hashes 允许它们但需维护哈希；更推荐移除内联事件处理器（改用 addEventListener），避免 unsafe-hashes。取舍：unsafe-hashes 便利（保留事件处理器）但维护哈希且放宽；addEventListener 更安全。工程上尽量用 addEventListener，避免内联事件处理器。

unsafe-hashes 允许哈希匹配的内联事件处理器，比 unsafe-inline 严格。但更推荐用 addEventListener 移除内联事件。取舍是便利 vs 安全与维护。

• React 的 Trusted Types 支持
• react-dom 自动包装
• 工程应用

React（react-dom）的 Trusted Types 支持：React（react-dom）在启用 Trusted Types 的环境下自动创建默认策略并用于 dangerouslySetInnerHTML 的 innerHTML 注入；对 script/iframe 的 src 等属性，若传入值已是 Trusted Script/URL 对象则原样透传而不字符串化。注意 style 不属于 Trusted Types 约束范围，dangerouslySetInnerHTML 的内容仍需自行消毒（如 DOMPurify）。react-dom 自动包装意味着 React 的 DOM 注入默认走 Trusted Types 策略（若启用）。工程价值：React 渲染的 DOM 注入默认安全，减少内联注入风险。取舍：需启用 Trusted Types 环境，且 dangerouslySetInnerHTML 仍需消毒。工程实践：配置 React 的 Trusted Types 策略，配合 DOMPurify。

react-dom 自动用 Trusted Types 包装 DOM 注入，让 React 渲染默认走安全策略。工程价值是框架级默认安全，但 dangerouslySetInnerHTML 仍需消毒。

• Permissions-Policy 控制权限
• 团队规范
• 安全审计

Permissions-Policy（Permissions-Policy 头）控制页面与 iframe 可用的浏览器权限（camera、microphone、geolocation、clipboard 等）。与团队规范协作：团队制定权限基线（哪些权限默认禁用、按需开放），用 Permissions-Policy 统一配置。安全审计：审计权限使用（哪些页面用敏感权限），用 Permissions-Policy 最小化权限面，减少钓鱼/滥用。工程价值：权限最小化 + 规范落地 + 审计。取舍：Permissions-Policy 限制需平衡功能。工程上建立权限清单与策略。

Permissions-Policy 控制权限面，与团队规范（最小权限）与安全审计（审计权限使用）协作。工程价值是权限最小化，减少滥用风险。

• Topics API 机制
• 隐私友好兴趣信号
• 第三方 Cookie 替代

Topics API 是 Privacy Sandbox 的兴趣追踪 API：浏览器根据用户浏览历史计算兴趣主题（topics），在广告相关请求中向站点提供（按周更新、可控制）。工程价值：在第三方 Cookie 淘汰后，提供隐私友好的兴趣信号用于广告/内容定向，无需跨站追踪。前端工程：调用 document.browsingTopics() 获取主题，用于广告个性化。取舍：主题粒度粗、隐私保护（用户可关闭）、用于非敏感定向。工程价值：替代第三方 Cookie 的定向信号。

Topics API 提供隐私友好的兴趣主题，替代第三方 Cookie 定向。前端调用 browsingTopics() 获取。取舍是粒度粗但隐私友好。工程价值是 Cookie 淘汰后的定向方案。

• default 策略
• 框架集成
• 工程实践

Trusted Types 的 default 策略（createPolicy('default', ...)）是兜底策略：当代码未指定策略时，default 策略处理 DOM 注入。框架集成：框架（如 Angular、React）的 DOM 注入若未指定策略，会走 default 策略。工程实践：创建 default 策略（通常用 DOMPurify 净化 createHTML），处理框架/遗留的内联注入；同时用命名策略（createPolicy）处理特定场景。取舍：default 策略兜底便利但可能放宽（统一净化），命名策略更精确。工程上 default 策略净化 + 命名策略控制。

default 策略是兜底，处理未指定策略的注入。框架集成中 default 策略常用 DOMPurify 净化。取舍是兜底便利 vs 精确控制。

• frame-src 限制 iframe 来源
• 第三方 iframe 兼容
• 边界

CSP 的 frame-src 限制可嵌入的 iframe 来源，frame-ancestors 限制本页可被嵌入的位置。第三方广告 iframe 嵌入需在 frame-src 白名单中允许广告域名。兼容性边界：CSP 限制太严会阻止广告/第三方 iframe加载；需为第三方 iframe 配置 frame-src 白名单（广告网络域名）。取舍：frame-src 限来源（安全），但需包含第三方域名（兼容）。工程上针对广告 iframe 配置 frame-src 白名单，配合 sandbox 限制。工程价值：安全与第三方兼容的平衡。

CSP 的 frame-src 限制 iframe 来源。第三方广告 iframe 需在 frame-src 白名单。取舍是安全限制 vs 第三方兼容，用白名单 + sandbox。

• Content-Security-Policy-Report-Only
• 灰度部署
• 工程价值

Content-Security-Policy-Report-Only 只上报违规不阻止，用于灰度部署 CSP。工程价值：在新策略正式启用前，用 report-only 观察违规，收集真实违规，调整策略，避免强制后资源被阻断。灰度部署：先 report-only 全量/部分观察，修复违规，再切换强制执行。取舍：report-only 不保护（只报告），但安全地评估策略。工程上阶梯式：report-only → 修复 → 强制执行 → 持续监控。工程价值：无风险部署 CSP。

report-only 模式只上报不阻止，用于 CSP 灰度部署。先观察违规再强制，避免中断。工程价值是安全评估与渐进实施。

• Trusted Types 与 Shadow DOM
• 组件内 DOM 注入
• 工程应用

Web Components 用 Shadow DOM 封装，其内部 DOM 注入（innerHTML、slot 内容）同样受 Trusted Types 约束。组件内应使用 Trusted Types 策略创建安全 DOM 注入。工程价值：组件库的 DOM 操作默认安全，防 XSS。实践：组件内用 createPolicy 包装 DOM 注入，避免直接 innerHTML 不可信内容；slot 内容需消毒。取舍：组件与全局共享 CSP 的 Trusted Types 策略。工程上组件库接入 Trusted Types，提升组件安全性。

Web Components 的 Shadow DOM 内 DOM 注入也受 Trusted Types 约束。组件内用策略包装注入，防 XSS。工程价值是组件库安全。

• Permissions-Policy 指令
• 精细化权限控制
• iframe 权限

Permissions-Policy（原 Feature-Policy）通过 Permissions-Policy 响应头控制页面与 iframe 可用的浏览器权限（camera、microphone、geolocation、clipboard、payment 等）。可设置 allow 列表控制 iframe 权限（<iframe allow="camera">）。工程应用：精细化控制——默认禁用敏感权限，按需开放；限制 iframe 权限（防滥用）；权限最小化。工程价值：减少权限滥用与钓鱼面。取舍：限制需平衡功能。工程实践：建立权限基线，用 Permissions-Policy 统一配置。

Permissions-Policy 精细化控制浏览器权限，支持 iframe 权限控制。工程价值是权限最小化与防滥用。取舍是安全限制 vs 功能。

• CSP 与 Trusted Types 协作
• 大型应用部署
• 渐进策略

CSP 与 Trusted Types 协作：CSP 的 require-trusted-types-for 'script' 启用 Trusted Types，trusted-types 限制策略名，两者共同防 XSS。大型应用部署策略：1) 先 report-only（CSP 与 Trusted Types 都 report 观察）；2) 收集违规，修复（创建策略、改造 DOM 操作）；3) 逐步收紧（先 trusted-types 白名单，再 require-trusted-types-for）；4) 强制执行并持续监控。工程价值：分阶段部署，避免中断，最终形成强 XSS 防护。取舍：需全量改造，但安全提升大。

CSP 与 Trusted Types 协作防 XSS，大型应用需渐进部署（report-only→修复→强制）。工程价值是安全部署与强防护，取舍是改造成本。

• Angular 默认启用
• Vue/React 支持现状
• 工程取舍

Trusted Types 的框架支持现状：Angular 默认启用（对 DomSanitizer 的返回值用 Trusted Types，innerHTML 需安全管道）；React 的实验性支持（react-dom 提供 Trusted Types 集成，需配置）；Vue 原生支持有限（v-html 直接注入，需手动配合 Trusted Types）。工程取舍：Angular 默认安全（但需适配），React/Vue 需自行集成（用 createPolicy 包装 v-html/dangerouslySetInnerHTML）。工程价值：按框架利用原生支持，未支持的用策略包装。工程上评估框架支持度。

Trusted Types 框架支持：Angular 默认、React 实验、Vue 有限。工程取舍是原生支持 vs 手动集成。都需配合 DOMPurify 与策略。

• TrustedHTML/TrustedScript 类型
• 自定义清理
• 工程应用

Trusted Types 的类型：TrustedHTML（用于 HTML 注入）、TrustedScript（用于脚本）、TrustedScriptURL（用于脚本 URL）。自定义清理：策略的 createHTML/createScript 返回这些类型，配合自定义清理逻辑（如 DOMPurify 净化 HTML、白名单脚本）。工程应用：createHTML 用 DOMPurify 净化返回 TrustedHTML；createScript 限制脚本内容返回 TrustedScript。工程价值：按类型分化的清理，精细化控制。取舍：需维护各类型策略。工程上按注入类型定义清理策略。

TrustedHTML/TrustedScript 是 Trusted Types 的类型，策略的 create 函数返回这些类型。自定义清理按类型定义（HTML 净化、脚本限制）。工程价值是精细化。

• TLS 1.3 0-RTT
• 重放风险
• Safari 严格 0-RTT

TLS 1.3 的 0-RTT（恢复会话时首包带数据）省一个 RTT，提升性能，但存在重放风险（0-RTT 数据可被重放）。Safari 对 0-RTT 更严格（默认禁用或限制 0-RTT 使用），以规避重放风险。工程边界：0-RTT 只适合幂等请求（GET 静态资源），服务端需限制 0-RTT 数据量、anti-replay；Safari 的严格处理导致 0-RTT 在 Safari 不可用（回退 1-RTT）。取舍：0-RTT 提升性能但 Safari 不支持，需回退。工程价值：理解 0-RTT 的兼容性，性能优化需考虑 Safari。

0-RTT 省 RTT 但有重放风险，Safari 严格（禁用/限制）。0-RTT 仅幂等请求，Safari 回退 1-RTT。工程上需处理兼容性。

• JWT alg 头部
• alg: none 攻击
• HS256/RS256 混淆

JWT 算法协商攻击：1) alg: none——攻击者把算法改为 none，token 无签名，若服务端接受则伪造；2) HS256/RS256 混淆——服务端用公钥（RS256）验证时，攻击者用公钥作为 HMAC 密钥（HS256）签名，若服务端不验证算法类型，可伪造。防御：严格校验签名算法——服务端固定并校验 alg 头（拒绝 none、拒绝算法切换）、校验签名密钥类型、验签时明确算法。工程实践：服务端只接受白名单算法、验签前校验 alg、用安全库处理。工程价值：防 JWT 伪造。

JWT 算法攻击利用 alg 头（none、算法混淆）。防御是严格校验 alg 与签名算法、拒绝 none、防 RS256/HS256 混淆。工程上白名单算法并验签。

• JWE 加密与 JWS 签名
• 用途差异
• 工程取舍

JWS（JSON Web Signature）对 token 签名（保证完整性/真实性，不保密），JWE（JSON Web Encryption）对 token 加密（保证机密性，内容不可读）。用途：JWS 用于验证 token 来源（如 access token、ID token 签名），JWE 用于需要保密传输的数据（如敏感 claims）。取舍：JWS 公开可读但防篡改，JWE 保密但不可读（需解密）。工程取舍：默认用 JWS（验签），需保密时用 JWE（或 JWS 与 JWE 嵌套）。工程价值：选择正确的机制（签名 vs 加密）。

JWS 签名（防篡改、公开），JWE 加密（保密）。取舍是完整性 vs 机密性。工程上默认 JWS，敏感数据用 JWE。两者可嵌套。

• DPoP 证明 token 持有
• DPoP-Proof JWT
• 防重放/盗用

DPoP（Demonstrating Proof-of-Possession，RFC 9449）让客户端证明持有 token 对应的私钥：客户端生成密钥对，用私钥对每个请求生成 DPoP-Proof JWT，服务端用公钥验证。DPoP 绑定 token 与请求/密钥，防止 token 被重放或盗用（即使 token 泄露，攻击者无私钥无法生成有效 DPoP-Proof）。工程价值：强化 OAuth 安全性，防 token replay/盗用。取舍：需密钥管理、每次请求生成 JWT。工程上用于高安全场景（如支付、敏感 API）。

DPoP 证明客户端持有 token 对应私钥，通过 DPoP-Proof JWT 绑定请求。防 token 重放/盗用。工程价值是强化 OAuth 安全，取舍是密钥管理开销。

• mTLS 双向认证
• 服务间通信
• Service Mesh

mTLS（双向 TLS）要求客户端与服务端都提供证书验证，实现双向认证。工程价值：后端服务到服务通信中，mTLS 保证双方身份可信、通信加密，防中间人、防未授权访问。Service Mesh（如 Istio、Linkerd）把 mTLS 作为核心能力：自动为服务间通信注入 mTLS 证书，透明实现服务身份认证与加密。工程价值：服务网格中 mTLS 提供零信任网络基础。取舍：mTLS 需证书管理（Service Mesh 自动化）。工程上 Service Mesh 用 mTLS 网格化。

mTLS 双向认证，服务间通信与服务网格中保证身份与加密。Service Mesh 自动化 mTLS。工程价值是零信任网络基础，取舍是证书管理。

• HSTS preload
• 各浏览器 preload list
• 部署边界

HSTS preload list 是硬编码在浏览器中的域名列表，强制这些域名始终用 HTTPS（即使首次访问也禁止 HTTP）。提交到 preload list 需满足条件（有效证书、HSTS 头、includeSubDomains、max-age 足够）。部署边界：Chrome、Safari、Firefox 都维护 preload list（Chrome 主导，其他浏览器同步）；提交后生效需时间（跨浏览器）；preload 是"不可逆"的强制（移除需等待）。工程取舍：preload 提供最强 HTTPS 强制，但需满足条件且不可逆。工程价值：全站 HTTPS 强制。

HSTS preload 硬编码域名强制 HTTPS，跨浏览器（Chrome 主导）。部署需满足条件且不可逆。工程价值是最强 HTTPS 强制，取舍是提交门槛。

• SameSite=Strict
• OAuth 回调重定向
• 第三方 OAuth 嵌入

SameSite=Strict Cookie 只在同站请求发送，跨站（含顶级导航）不发送。OAuth 回调重定向：OAuth 授权后重定向回应用，若 session Cookie 是 Strict，重定向属于跨站导航，Cookie 不发送，导致登录状态丢失（需重新认证）。取舍：Strict 最安全但破坏 OAuth 回调；Lax 允许顶级导航 GET 携带 Cookie，更适合 OAuth 回调（GET 重定向）。第三方 OAuth 嵌入（iframe）需 None。工程取舍：登录态用 Lax（兼容 OAuth 回调）或 Strict（需处理重定向），第三方嵌入用 None。工程价值：平衡安全与 OAuth 流程。

SameSite=Strict 阻止跨站导航 Cookie，破坏 OAuth 回调重定向。Lax 允许顶级导航 GET，适合 OAuth 回调整。取舍是安全 vs OAuth 流程兼容。

• PKCE 机制（code_verifier/code_challenge）
• 防授权码拦截
• OAuth 2.1 强制

PKCE（Proof Key for Code Exchange）用于 OAuth 授权码流程：客户端生成 code_verifier（随机串），计算 code_challenge（S256 哈希）随授权请求发送，授权时用 code_verifier 换取 token，服务端验证 challenge 匹配。工程价值：防授权码拦截（authorization code interception）——即使攻击者截获授权码，无 code_verifier 无法换取 token。OAuth 2.1 强制 PKCE 于所有授权码流程。工程价值：SPA/移动端防授权码劫持。取舍：无状态（客户端生成凭证），提升安全。

PKCE 用 code_verifier/challenge 绑定授权码，防拦截。OAuth 2.1 强制。工程价值是防授权码劫持，SPA/移动端必需。

• Refresh Token Rotation
• Reuse Detection
• 长期会话安全

Refresh Token Rotation 是每次刷新 token 时轮换 refresh token（旧 token 失效，发新 token）。Reuse Detection：检测到 refresh token 被重用（泄露/重放）时，撤销整个会话（所有 token）。工程价值：长期会话安全——即使 refresh token 泄露，轮换限制其生命周期，复用检测发现泄露并撤销。工程实践：刷新时轮换、检测复用即撤销、存储刷新 token。取舍：轮换增加复杂度但提升安全。工程价值：防 token 泄露的长期会话防护。

Refresh Token Rotation 轮换 token、Reuse Detection 检测复用撤销会话。工程价值是防 token 泄露与重放，长期会话更安全。取舍是复杂度。

• crypto.subtle.sign/verify
• 前后端签名验证
• 工程应用

crypto.subtle.sign 与 crypto.subtle.verify 用于签名与验签（HMAC、ECDSA、RSA-PSS、Ed25519）。工程价值：前端签名/验签，无需引入加密库。应用：前端签名请求（防篡改）、验签（验证服务端/第三方数据）、端到端签名。需 Secure Context。前后端协作：前端用签名算法签数据，后端验签；或后端签名前端验证。工程取舍：crypto.subtle 是异步与安全（密钥不可导出），但需理解算法。工程价值：前端密码学签名能力。

crypto.subtle.sign/verify 提供前端签名与验签。工程价值是防篡改与验证，需 Secure Context。前后端协作需算法一致。

• TLS 1.3 early data
• 0-RTT replay 防护
• anti-replay nonce

TLS 1.3 的 0-RTT 使用 early-data 携带请求数据，有重放风险。防护：服务端用 anti-replay 机制——如包含 nonce 的会话票据、一次性票据、地址验证、重放窗口检测。服务端对 early-data 用 nonce 检测重复/重放，拒绝重放的 0-RTT 数据。工程取舍：0-RTT 提升性能但重放防护需服务端实现；对非幂等请求禁用 0-RTT。工程价值：在享受 0-RTT 性能的同时防重放。实践：服务端限制 early-data 大小、anti-replay 票据、仅幂等请求。

0-RTT early-data 有重放风险，服务端用 anti-replay nonce/一次性票据检测重放。工程上仅幂等请求用 0-RTT，并实现 anti-replay。

• JWS 签名 + JWE 加密
• 嵌套 token
• 隐私数据交换

JWT 可嵌套：外层 JWE（加密）包裹内层 JWS（签名），实现"签名 + 加密"双层。JWS 保证完整性/真实性，JWE 保证机密性。OAuth 2.0 隐私数据交换：用嵌套 token 既验签（防篡改）又加密（防泄露），适合敏感 claims（如 ID token 中的隐私数据）。工程价值：在需要保密与真实性的场景（如跨域交换隐私数据）使用。取舍：嵌套增加处理开销，但提供完整安全。工程上按需嵌套。

嵌套 JWT（JWE 包 JWS）实现加密+签名。OAuth 隐私数据交换用嵌套保证真实与保密。取舍是开销 vs 完整防护。

• frame-ancestors 与 X-Frame-Options
• 浏览器优先级
• 点击劫持与 iframe 嵌入

点击劫持防护：X-Frame-Options（DENY 禁止所有嵌入、SAMEORIGIN 仅同源嵌入）与 CSP 的 frame-ancestors（限制可嵌入本页的 iframe 来源）。差异：frame-ancestors 更灵活（可精确白名单、支持多个来源），X-Frame-Options 简单（DENY/SAMEORIGIN）。浏览器优先级：现代浏览器支持 frame-ancestors 时优先于 X-Frame-Options（frame-ancestors 覆盖）。取舍：需要白名单嵌入（如第三方支付/嵌入）用 frame-ancestors；简单禁止/同源用 X-Frame-Options。工程上两者都设（旧浏览器用 X-Frame-Options，现代用 frame-ancestors）。

frame-ancestors 比 X-Frame-Options 灵活，现代浏览器优先 frame-ancestors。取舍是精确白名单 vs 简单。工程上两者都设兼容。

• Protected Audience API
• Interest Group 与竞拍
• 隐私边界

Protected Audience API（原 FLEDGE）是 Privacy Sandbox 的广告竞拍方案：广告商把用户加入 Interest Group（兴趣组，本地存储），竞拍时在设备端（Worklet）根据兴趣组与出价挑选广告，数据不出设备。工程边界：竞拍在设备端 Worklet 执行，广告主不直接获取用户数据（隐私）；需配置 Interest Group 与竞拍逻辑。取舍：替代基于第三方 Cookie 的竞拍，隐私友好但能力受限（无跨站数据）。工程价值：Cookie 淘汰后的广告竞拍方案。

Protected Audience API 在设备端 Worklet 竞拍，数据不出设备，替代第三方 Cookie 竞拍。工程边界是隐私保护与环境限制。价值是 Cookie 淘汰后的广告方案。

• Attribution Reporting API
• 转化归因
• 隐私约束（噪声、跨站）

Attribution Reporting API 是 Privacy Sandbox 的转化归因方案：广告点击/展示（source）与转化（trigger）通过浏览器归因，报告延迟且有噪声（防单个用户追踪），跨站限制（不暴露用户身份）。前端埋点设计：广告事件注册 source，转化事件注册 trigger，浏览器聚合报告。工程边界：噪声与延迟降低精确性；跨站限制保护隐私。浏览器支持：Chrome 支持，其他浏览器有限。取舍：隐私友好但归因精确性受限。工程价值：无第三方 Cookie 的转化归因。

Attribution Reporting API 用噪声/延迟/跨站限制保护隐私，浏览器归因。前端埋点注册 source/trigger。取舍是隐私 vs 精确性，支持有限。

• Fenced Frames 隔离
• 与 iframe sandbox 差异
• 前端嵌入方案影响

Fenced Frames 是 Privacy Sandbox 的广告渲染隔离容器：内容在隔离的帧中渲染，父页面无法访问其 DOM/数据（更强的隔离），用于广告渲染防数据泄露。与 iframe sandbox 差异：iframe sandbox 通过属性限制（脚本、表单等），但父页面仍可访问部分；Fenced Frames 更严格（父页面无法读取内容，数据隔离），且与 Protected Audience/Shared Storage 集成。前端嵌入影响：广告用 Fenced Frames 渲染，父页面无法劫持/读取广告内容，需按 Fenced Frames API 嵌入。取舍：更强隔离但嵌入受限。

Fenced Frames 提供更强的广告渲染隔离（父页面不可读），与 iframe sandbox 不同。前端嵌入需按 Fenced Frames API。取舍是隔离 vs 嵌入灵活性。

• Topics 信号获取
• Protected Audience 竞拍
• Attribution 归因

第三方 Cookie 淘汰后，广告链路重构：Topics API 获取兴趣信号（browsingTopics()），Protected Audience 在设备端竞拍（Worklet），Attribution Reporting 归因（浏览器报告）。前端工程边界：信号获取用 Topics（粗粒度兴趣）、竞拍在设备端 Worklet（不出设备）、归因用浏览器报告（噪声/延迟）。取舍：隐私友好但精确性/能力受限，链路复杂。工程价值：无第三方 Cookie 的完整广告链路。前端需适配各 API。

广告链路重构：Topics（信号）+ Protected Audience（竞拍）+ Attribution（归因），全在隐私沙箱内。工程边界是隐私约束与能力受限。价值是 Cookie 淘汰后的方案。

• Shared Storage 键值存储
• selectURL
• Worklet 内不可见数据

Shared Storage API 是 Privacy Sandbox 的跨站共享存储：在 Worklet 中不可见地读写键值（数据不出设备），selectURL 在 Worklet 内根据存储数据选择 URL（如广告），父页面看不到数据。应用边界：数据在 Worklet 内处理，父页面不可见（隐私）；用于跨站广告（频率、A/B）、个性化。工程价值：跨站点共享状态（无需第三方 Cookie）用于广告/频率控制。取舍：数据不可见、Worklet 内计算，能力受限但隐私。

Shared Storage 在 Worklet 内不可见处理键值，selectURL 选择 URL。用于跨站广告与频率控制。工程价值是隐私友好共享状态，取舍是数据不可见受限。

• AI 流式内容 XSS
• CSP + DOMPurify + Trusted Types 链路
• 半截标签/javascript:/SVG/MathML/mXSS

AI 流式 Markdown 输出不可信内容，需唯一 DOM 写入链路：Trusted Types 强制所有 DOM 注入必须经策略（唯一写入路径），DOMPurify 作为 createHTML 净化（配置白名单、禁 HTML、禁 javascript: URL、处理 SVG/MathML），CSP Level 3（script-src nonce/strict-dynamic、require-trusted-types-for）限制脚本与强制 Trusted Types。防御：半截标签（流式中途）——净化器容错解析；javascript: URL——协议白名单；SVG/MathML——净化器禁用危险元素；mXSS——最新 DOMPurify、避免二次解析。唯一写入链路：所有渲染经这个策略，保证净化一致。

AI 流式内容防线是"唯一 DOM 写入链路"：Trusted Types 强制路径 + DOMPurify 净化 + CSP 限制。防御半截标签、javascript:、SVG/MathML、mXSS。工程价值是统一安全渲染。

• strict-dynamic 信任链
• AI/第三方脚本动态加载
• Trusted Types policy

AI 插件/第三方脚本动态加载时，CSP 信任链设计：非 nonce 脚本通过 strict-dynamic 从 nonce 脚本继承信任（避免通配域名），第三方脚本用 nonce 注入或通过受控的加载函数（经 Trusted Types 策略的 createScript 加载）。Trusted Types policy：createScriptURL 白名单校验第三方脚本 URL，禁止通配。Report-Only 灰度：先 report-only 观察违规，确认第三方脚本加载正常，再强制。避免通配域名：不添加 * 到 script-src，用 strict-dynamic + nonce + 白名单 URL。工程价值：安全动态加载第三方脚本。

strict-dynamic 传递信任避免通配域名，第三方脚本用 nonce/策略加载，Trusted Types 校验 URL，Report-Only 灰度。工程价值是安全动态加载而不扩大执行面。

• HPKP 机制
• 证书公钥固定
• 废弃原因

HPKP（HTTP Public Key Pinning）让服务器通过 Public-Key-Pins 头固定证书公钥，浏览器只信任固定的公钥，防证书被伪造/CA 被攻击。废弃原因：HPKP 风险大——若服务器配置错误（固定错误公钥、密钥轮换），会导致合法用户无法访问（DoS）；且被滥用（攻击者可固定恶意公钥）。Chrome 已移除 HPKP。替代：证书透明度（CT）、CAA、更严格的证书管理。工程价值：理解 HPKP 的废弃，避免使用，改用现代证书安全。

HPKP 固定证书公钥但风险大（误配置导致 DoS、被滥用），已废弃。替代是 CT、CAA。工程上避免 HPKP，用现代证书机制。

• ECDH 密钥协商
• 端到端加密
• 工程应用

ECDH（Elliptic Curve Diffie-Hellman）是密钥协商算法：双方用各自的私钥与对方公钥协商出共享密钥。WebCrypto 的 crypto.subtle 支持 ECDH（deriveKey）。端到端加密（E2EE）：双方协商共享密钥，用 AES-GCM 加密消息，密钥只存在于两端（服务器不可见），实现 E2EE。工程价值：聊天、文件等 E2EE。取舍：ECDH 需交换公钥（可通过服务器但不可见明文），需 Secure Context。工程上前后端协作协商。

ECDH 协商共享密钥，用于 E2EE 加密。WebCrypto 实现 deriveKey。工程价值是端到端加密，密钥只在两端。

• JWT 时间声明（exp/nbf/iat）
• clock skew
• 校验边界

JWT 的时间声明：exp（过期时间）、nbf（生效时间）、iat（签发时间）。校验时，若服务器与签发方时钟有偏移（clock skew），会导致误判（token 未过期却被判过期、或 nbf 未生效）。边界：校验时允许小的 clock skew（如几秒到几分钟的容差），避免因时钟偏差误判。工程取舍：容差过大降低安全（过期 token 有效），过小则误判。工程实践：设置合理的 skew 容差（如 30s-5min），或确保 NTP 同步。

JWT 时间校验需考虑 clock skew，设置合理容差避免误判。取舍是容差 vs 安全。工程上 NTP 同步 + 合理 skew。

• Passkey/WebAuthn
• 替代密码/令牌
• 工程价值

Passkey/WebAuthn 用公钥密码学替代密码与设备令牌：设备生成密钥对，认证用签名挑战，无密码/无 OTP。工程价值：抗钓鱼（私钥在设备、绑定 origin）、防破解、无密码用户友好、减少 OTP 依赖。替代：传统密码（防破解/钓鱼）、SMS/OTP 令牌（防钓鱼/拦截）。取舍：需设备支持、跨设备同步（平台）、恢复流程。工程价值：无密码登录、抗钓鱼、更安全。工程上逐步用 Passkey 替代密码/令牌。

Passkey 用公钥密码学替代密码与令牌，抗钓鱼、防破解。取舍是设备依赖与恢复。工程价值是无密码登录、更安全。

• JWT 跨子域传递
• Cookie 属性（SameSite/Path/HttpOnly）
• 安全策略

microfrontend 跨子域传递 JWT 常用 Cookie：设置 Cookie 的 Domain 为父域（.example.com）使子域共享，Path 为 /。安全策略：HttpOnly 防 XSS 读取 token；Secure 仅 HTTPS；SameSite 控制跨站（Lax 允许同站子域，跨站需 None）。取舍：跨子域共享 Cookie 便利但扩大攻击面（任一子域 XSS 可影响）；HttpOnly 防前端读取，但 SPA 需从非 HttpOnly 或 via 接口获取。工程价值：平衡跨子域共享与安全。工程上 HttpOnly+Secure+SameSite=Lax，子域最小化。

JWT 跨子域用 Cookie（Domain 父域）。安全用 HttpOnly+Secure+SameSite。取舍是跨子域共享 vs 攻击面。工程上最小化子域。

• Passkey 签名算法
• ML-KEM（封装）与 ML-DSA（签名）区别
• 混合迁移与能力协商

Passkey 用认证器签名算法（如 ECDSA、Ed25519）；ML-KEM 是密钥封装（KEM，用于密钥交换），ML-DSA 是后量子签名（用于签名），不可混用——ML-KEM 不能作为 Passkey 签名。PQ 迁移：在 WebAuthn 未普遍提供 PQ 算法时，设计混合迁移：1) 能力协商——注册/认证时协商算法（经典 + PQ 可选）；2) 混合凭据——同时注册经典与 PQ 多凭据，或用混合签名（经典 + PQ 组合）；3) 凭据轮换——逐步用 PQ 凭据替换经典，保留兼容。防止误用：明确 ML-KEM 是封装用于密钥交换，ML-DSA 才是签名，Passkey 签名用签名算法（ML-DSA 或混合）。工程价值：前瞻 PQ 迁移，避免算法误用。

ML-KEM 是封装、ML-DSA 是签名，Passkey 签名用签名算法。PQ 迁移用能力协商、混合凭据、凭据轮换。工程价值是正确 PQ 迁移。

• report-to/report-uri
• Reporting API
• 聚合去重、采样、灰度

CSP 违规上报：report-uri（旧）与 report-to（新，Reporting API）端点接收违规报告。CSP Level 3 的 Reporting API 用 Report-To 头配置端点，支持多报告类型。聚合去重——大量违规可能重复，需在收集端去重（按 URI/指令/来源 key）；采样——全量上报量大，可采样（按比例报告）；灰度——先 report-only 灰度部分流量，观察违规再强制。工程价值：高效收集违规、监控策略、渐进部署。工程实践：配置 report-to 端点、服务端聚合去重、按需采样、报告监控。

CSP 违规上报用 report-to（Reporting API），需聚合去重、采样、灰度管理。工程价值是监控与渐进部署。取舍是采集成本 vs 覆盖率。