# 1. CSP 的 nonce 与 hash 指令 A nonce 每次都相同 B hash 需服务端随机生成 C nonce 每次随机校验内联脚本，hash 静态校验脚本内容，避免 unsafe-inline ✓ 正确答案 D 两者必须配合 unsafe-inline
# 2. Privacy Sandbox 在跨域隔离（COOP/COEP） A Privacy Sandbox 依赖第三方 Cookie B Privacy Sandbox 提供隐私广告 API，跨域隔离（COOP/COEP）是其安全基础 ✓ 正确答案 C 跨域隔离与隐私沙箱无关 D Privacy Sandbox 不做跨站隔离
# 3. Trusted Types 防止 DOM XSS 的强制策略 A Trusted Types 仅用于服务端 B require-trusted-types-for 让 DOM 注入必须用 Trusted Types 策略，阻止字符串注入 ✓ 正确答案 C 强制策略无需改造代码 D Trusted Types 只防网络 XSS
# 4. Referrer-Policy strict-origin-when-cross-origin 在 referer 泄露防护的工程价值 A 跨源请求发送完整 URL B 它完全不发送 referer C 跨源请求只发送 origin，防查询参数泄露，是推荐的默认策略 ✓ 正确答案 D 它与隐私无关
# 5. Trusted Types 策略（defaultPolicy/createPolicy） A createPolicy 创建命名策略，defaultPolicy 是兜底策略处理未指定注入 ✓ 正确答案 B defaultPolicy 可以创建多个 C createPolicy 只能创建 defaultPolicy D 策略与 DOM 注入无关
# 6. Cross-Origin-Opener-Policy 与 Spectre 侧信道防护的协作 A COOP 增加跨源窗口访问 B COOP 隔离跨源窗口，配合 COEP 形成跨源隔离，降低 Spectre 侧信道风险 ✓ 正确答案 C COOP 与 Spectre 无关 D COOP 只影响性能
# 7. Private State Tokens 与 DPoP（RFC 9449） A DPoP 用于广告 B DPoP 证明 token 持有防重放，Private State Tokens 匿名防欺诈 ✓ 正确答案 C 两者功能完全相同 D DPoP 与 token 无关
# 8. CSP 的 nonce-source 与 strict-dynamic 在内联脚本控制的工程价值 A strict-dynamic 需要通配符域名 B nonce 与 strict-dynamic 互斥 C nonce 允许内联脚本，strict-dynamic 传递信任给动态加载脚本，避免通配符 ✓ 正确答案 D 两者都需 unsafe-inline
# 9. Trusted Types 强制策略（require-for-trusted-types）的部署策略 A 应立即强制启用，无需准备 B 强制策略无需改造代码 C 先 report-only 观察违规、修复后再强制，分阶段部署 ✓ 正确答案 D 强制策略只能一次性启用
# 10. HTTPS + HSTS（Strict-Transport-Security） A HSTS 允许降级到 HTTP B HSTS 与中间人无关 C HSTS 只在首次访问生效，无需 preload D HSTS 强制浏览器在指定时间内使用 HTTPS，防 SSL 剥离与降级攻击 ✓ 正确答案
# 11. CSRF Token（Synchronizer Token Pattern/Double-Submit Cookie） A Synchronizer Token Pattern 在会话存 token 并校验，Double-Submit Cookie 双提交对比 ✓ 正确答案 B 两者都无需校验 C Double-Submit 用会话存储 D CSRF Token 无法防 CSRF
# 12. Web Crypto API（crypto.subtle）的对称/非对称/密钥派生/签名的工程价值 A crypto.subtle 只支持对称加密 B crypto.subtle 提供对称/非对称/密钥派生/签名，用于前端加密与签名 ✓ 正确答案 C crypto.subtle 无需 Secure Context D crypto.subtle 只能用于服务端
# 13. TLS 1.2 与 TLS 1.3 握手差异 A TLS 1.3 握手比 1.2 慢 B 两者握手完全相同 C TLS 1.3 握手降为 1-RTT/0-RTT，移除弱算法并强制前向安全 ✓ 正确答案 D TLS 1.3 移除前向安全
# 14. QUIC 的 0-RTT 风险 与 Early Hints（103） A 0-RTT 省 RTT 但有重放风险（仅幂等），Early Hints 103 提前提示资源无副作用 ✓ 正确答案 B 0-RTT 无重放风险 C Early Hints 有重放风险 D 两者完全相同
# 15. TLS 1.3 的 1-RTT 握手 在大型应用的网络性能工程价值 A TLS 1.3 1-RTT 比 2-RTT 多一个往返 B TLS 1.3 1-RTT 握手减少建连延迟，提升大型应用 HTTPS 性能 ✓ 正确答案 C 1-RTT 不影响 TTFB D 大型应用需用 TLS 1.2
# 16. HTTPS-only 约束与混合内容（Mixed Content）防护 A HTTPS 页面加载 HTTP 脚本是安全的 B 混合内容无风险 C 主动混合内容（脚本）会被浏览器阻止，用全 HTTPS + upgrade-insecure-requests 防护 ✓ 正确答案 D HSTS 与混合内容无关
# 17. Web Crypto 算法的安全生命周期（AES-GCM、SHA-256、Ed25519） A 算法永不过时 B SHA-1 是安全哈希 C AES-GCM 加密、SHA-256 哈希、Ed25519 签名是安全选择，需跟踪算法弃用与密钥轮换 ✓ 正确答案 D 密钥无需轮换
# 18. Passkeys（基于 WebAuthn）的抗钓鱼与公钥密码学在登录流程的工程取舍 A Passkeys 会发送密码 B Passkeys 无法防钓鱼 C Passkeys 与密码相同 D Passkeys 用公钥密码学，私钥在设备并绑定 origin，抗钓鱼替代密码 ✓ 正确答案
# 19. crypto.randomUUID 与 crypto.getRandomValues 在前端生成随机 ID/Token 的工程价值 A getRandomValues 不可用于 token B Math.random 是安全的随机数 C randomUUID 生成非随机值 D 两者都是加密安全随机数，用于生成 ID/token/nonce，避免 Math.random ✓ 正确答案
# 20. 抗量子密码学（ML-KEM/ML-DSA/SLH-DSA）的浏览器混合密钥交换 A ML-KEM 是签名算法 B 量子计算机不影响传统密码 C 混合密钥交换结合传统与 PQC（ML-KEM）算法，防御量子攻击 ✓ 正确答案 D 抗量子密码无需浏览器支持
# 21. DNS over HTTPS 在 CDN/边缘缓存的工程价值 A DoH 加密 DNS 防劫持，确保解析到正确 CDN 节点 ✓ 正确答案 B DoH 会降低 DNS 安全 C DoH 与 CDN 无关 D DoH 无法加密 DNS
# 22. 双重 Cookie 提交与自定义 Header 的 CSRF 防御 A 两者都依赖会话存储 B 双重 Cookie 无需校验 C 自定义头可被跨站设置 D 双重 Cookie 校验 token 一致性，自定义头因跨站无法设置而防 CSRF ✓ 正确答案
# 23. OCSP Stapling 在大型前端项目的工程价值 A OCSP Stapling 让客户端单独查询 OCSP 服务器 B OCSP Stapling 在握手附带证书吊销状态，减少客户端查询，提升性能与安全 ✓ 正确答案 C OCSP Stapling 与证书无关 D OCSP Stapling 只影响 HTTP
# 24. Origin/Referer 校验与 Same-Origin Policy A SOP 是服务端来源校验 B 只需校验 Origin 即可完全防 CSRF C Origin 头无法被伪造 D SOP 限制浏览器跨源读取，服务端校验 Origin/Referer 作为来源判断（防 CSRF）辅助手段 ✓ 正确答案
# 25. Same-Origin Policy 与 Schemeless Same-Site 在现代浏览器策略的差异 A Same-Origin 严格（协议+域名+端口），Schemeless Same-Site 仅看站点，Cookie 的 SameSite 基于站点 ✓ 正确答案 B 两者完全相同 C Same-Site 忽略域名 D Cookie 的 SameSite 基于 Origin
# 26. Origin/Referer 头校验在 CSRF 防护的工程价值（不作为唯一手段） A Origin/Referer 校验可单独完全防 CSRF B Origin/Referer 校验是辅助防线，可被伪造，需与 Token、SameSite 组合 ✓ 正确答案 C Origin 头无法被伪造 D 校验 Referer 无价值
# 27. CSRF 与 CORS 配置的边界 A CORS 直接防 CSRF B 两者无关 C CORS 可以允许任意源带凭据 D CORS 控制跨源读取，CSRF 靠 SameSite/Token/Origin 防御，CORS 配置过宽会扩大风险 ✓ 正确答案
# 28. report-uri/report-to 与 Reporting API 在 CSP 违规上报的工程价值 A 违规上报无法监控 B report-uri 是新的 Reporting API C report-to 是 Reporting API，上报 CSP 违规，用于监控与渐进部署 ✓ 正确答案 D report-to 只能上报 CSP
# 29. Trusted Types policy 在现代框架（Angular 默认启用、React 实验） A Trusted Types 与框架无关 B React 默认启用 Trusted Types C 两者都不支持 Trusted Types D Angular 默认启用 Trusted Types，React 为实验支持 ✓ 正确答案
# 30. CSP 的 script-src、style-src、frame-ancestors、connect-src 配置 A script-src 防脚本、style-src 防样式、frame-ancestors 防点击劫持、connect-src 防数据外传 ✓ 正确答案 B script-src 控制样式，style-src 控制脚本 C frame-ancestors 控制脚本 D connect-src 限制图片
# 31. SameSite=None 的 Cookie 在跨站 iframe 嵌入场景下与 SameSite=Lax 的兼容性陷阱，哪些浏览器/移动端 WebView 仍会把 SameSite=None 当作隐式 SameSite=Strict 处理，调试时如何用 DevTools 与 Charles 抓包做差异定位 A 所有浏览器都支持 SameSite=None B 无需兼容处理 C SameSite=None 与 SameSite=Lax 完全相同 D 旧浏览器/WebView 可能把 SameSite=None 当隐式 Strict，需用 DevTools/Charles 定位并兼容 ✓ 正确答案
# 32. 双重提交 Cookie 模式（Double Submit Cookie） A Double Submit Cookie 校验 Cookie 与请求 token 一致，无状态，但需防子域可写 Cookie ✓ 正确答案 B 服务端存储 token 并校验 C 双重提交无需校验 D 子域可写 Cookie 无风险
# 33. 浏览器的 Sec-Fetch-Site / Sec-Fetch-Mode / Sec-Fetch-Dest 请求头在 CSRF 防御中应如何使用才能既兼容旧浏览器又能减少 false positive——当 Sec-Fetch-Site=same-origin 但 Referer 被严格策略清空时，应以哪一项为准 A Referer 缺失应视为 CSRF 攻击 B Sec-Fetch-Site=same-origin 可信，Referer 被清空是隐私策略正常，应以 Sec-Fetch-Site 为准 ✓ 正确答案 C 所有浏览器都发送 Sec-Fetch-* D Sec-Fetch-* 与 CSRF 无关
# 34. CSP Level 3 的 unsafe-hashes 在事件处理器（onclick）的工程取舍 A unsafe-hashes 允许任意内联事件处理器 B unsafe-hashes 允许哈希匹配的 onclick 事件处理器，但更推荐 addEventListener 替代 ✓ 正确答案 C unsafe-hashes 比 unsafe-inline 更宽松 D onclick 内联是安全的
# 35. Trusted Types 在 React 的应用（react-dom 自动包装） A dangerouslySetInnerHTML 自动安全 B React 完全不支持 Trusted Types C react-dom 自动包装 DOM 注入用 Trusted Types，但 dangerouslySetInnerHTML 仍需消毒 ✓ 正确答案 D React 的 DOM 注入无法受控
# 36. Permissions-Policy 与团队规范与安全审计的协作 A Permissions-Policy 只能放行全部权限 B Permissions-Policy 与权限无关 C 权限无需审计 D Permissions-Policy 控制浏览器权限，与最小权限规范与安全审计协作 ✓ 正确答案
# 37. Topics API 在现代前端项目的工程价值 A Topics API 依赖第三方 Cookie B Topics API 无法用于广告 C Topics API 是加密 API D Topics API 提供隐私友好的兴趣主题，替代第三方 Cookie 定向 ✓ 正确答案
# 38. Trusted Types 的 default 策略在框架集成的工程实践 A default 策略与框架无关 B default 策略只能创建一次且不能净化 C default 策略处理未指定策略的 DOM 注入，常用 DOMPurify 净化 ✓ 正确答案 D default 策略是最精确的控制
# 39. CSP 在第三方 iframe（嵌入广告）的工程兼容性边界 A frame-src 会阻止所有 iframe B frame-src 限制 iframe 来源，第三方广告需在 frame-src 白名单 ✓ 正确答案 C CSP 不影响第三方 iframe D 第三方 iframe 无需白名单
# 40. CSP 的 report-only 模式在灰度部署的工程价值 A report-only 会阻断违规资源 B report-only 无法收集违规 C report-only 与强制执行相同 D report-only 只上报不阻止，先观察违规再强制，安全灰度部署 ✓ 正确答案
# 41. Trusted Types 在 Web Components（Shadow DOM） A Shadow DOM 不受 Trusted Types 约束 B Web Components 内 DOM 注入也受 Trusted Types 约束，组件内用策略包装防 XSS ✓ 正确答案 C Trusted Types 与组件无关 D Shadow DOM 内 DOM 注入无风险
# 42. Permissions Policy（Permissions-Policy）在精细化权限控制的工程应用 A Permissions-Policy 与权限无关 B Permissions-Policy 只能放行全部权限 C Permissions-Policy 控制浏览器权限，可限制 iframe 权限，实现最小化 ✓ 正确答案 D Permissions-Policy 无法控制 iframe
# 43. CSP 与 Trusted Types 协作在大型应用的部署策略 A 应立即强制启用，无需报告 B 先 report-only 观察、修复、逐步收紧，再强制，形成强 XSS 防护 ✓ 正确答案 C 两者互斥 D 部署无需改造代码
# 44. Trusted Types 在 Angular/Vue/React 框架的原生支持的工程现状 A Angular 默认启用，React 实验，Vue 有限，需按框架集成 ✓ 正确答案 B 所有框架默认启用 Trusted Types C Vue 完全支持 Trusted Types D 框架无需 Trusted Types
# 45. Trusted Types 的 TrustedHTML 与 TrustedScript 在自定义清理的工程应用 A TrustedHTML 用于脚本，TrustedScript 用于 HTML B 两者类型相同 C 策略的 createHTML/createScript 返回 TrustedHTML/TrustedScript，可自定义清理逻辑 ✓ 正确答案 D 无法自定义清理
# 46. TLS 1.3 的 0-RTT 握手在性能与现代浏览器兼容性（Safari 严格 0-RTT） A 所有浏览器都支持 0-RTT B Safari 完全支持 0-RTT C 0-RTT 无重放风险 D 0-RTT 省 RTT 但有重放风险，Safari 严格处理，需回退 1-RTT ✓ 正确答案
# 47. JWT 的算法协商攻击（alg: none、HS256/RS256 混淆）在严格校验签名的防御 A alg: none 是安全的 B 算法混淆无风险 C 严格校验 alg 白名单、拒绝 none、防 HS256/RS256 混淆，是 JWT 签名防御 ✓ 正确答案 D 无需校验签名算法
# 48. JWE（JSON Web Encryption）相比 JWS（JSON Web Signature） A JWS 加密，JWE 签名 B 两者都保证机密性 C JWS 签名保证完整/真实性，JWE 加密保证机密性，按需求选择 ✓ 正确答案 D JWE 与 JWS 相同
# 49. DPoP（Demonstrating Proof-of-Possession） A DPoP 无法防重放 B DPoP 与签名无关 C DPoP 只用于加密 D DPoP 让客户端证明持有 token 对应私钥，防 token 重放/盗用 ✓ 正确答案
# 50. mTLS（双向 TLS）在后端服务到服务通信与 Service Mesh 的现代工程价值 A mTLS 双向认证，Service Mesh 自动化 mTLS 实现服务间身份与加密 ✓ 正确答案 B mTLS 是单向认证 C mTLS 只保护浏览器 D Service Mesh 不用 mTLS
# 51. HTTPS 的 HSTS preload list 在 Chrome/Safari/Firefox 强制 HTTPS 的现代部署边界 A HSTS preload 硬编码域名强制 HTTPS，跨浏览器但需满足条件且不可逆 ✓ 正确答案 B preload 只在首次访问生效 C preload 无需提交即可生效 D preload 允许 HTTP
# 52. Same-Site=Strict Cookie 在 OAuth 回调重定向与第三方 OAuth 嵌入的工程取舍 A SameSite=Strict 阻止跨站导航 Cookie，会影响 OAuth 回调，Lax 更适合回调重定向 ✓ 正确答案 B Strict 允许 OAuth 回调携带 Cookie C OAuth 回调不受 SameSite 影响 D Strict 最利于 OAuth
# 53. PKCE（Proof Key for Code Exchange） A PKCE 与授权码无关 B PKCE 用 code_verifier/challenge 绑定授权码，防 authorization code 拦截 ✓ 正确答案 C PKCE 是可选的历史功能 D PKCE 无法防劫持
# 54. Refresh Token Rotation 与 Reuse Detection 在长期会话安全的工程实践 A Refresh Token Rotation 每次刷新轮换 token，Reuse Detection 检测复用即撤销 ✓ 正确答案 B 轮换会降低安全 C 复用检测无需撤销 D 两者与长期会话无关
# 55. Web Crypto API 的 crypto.subtle.sign 与 verify 在前后端签名验证的现代工程价值 A crypto.subtle.sign/verify 提供前端签名与验签，用于防篡改与验证 ✓ 正确答案 B sign 用于验签，verify 用于签名 C 两者只能用于服务端 D 无需 Secure Context
# 56. TLS 1.3 与 0-RTT replay 防护的 early-data 与 anti-replay nonce 策略 A 0-RTT 无需防护 B 0-RTT 用于所有请求 C early-data 不可重放 D 服务端用 anti-replay nonce/一次性票据检测 0-RTT 重放，仅幂等请求用 0-RTT ✓ 正确答案
# 57. JWT 的 JWE 与 JWS 双层（嵌套 token）在 OAuth 2.0 隐私数据交换的协作 A 嵌套 JWT（JWE 包 JWS）实现加密+签名，用于隐私数据交换 ✓ 正确答案 B 嵌套只能加密不能签名 C 嵌套与隐私无关 D JWS 包裹 JWE 是标准
# 58. CSP 的 frame-ancestors 指令与 X-Frame-Options（DENY/SAMEORIGIN）在点击劫持防护中的差异、浏览器优先级与 iframe 嵌入场景的取舍？ A 两者优先级相同 B X-Frame-Options 支持白名单嵌入 C frame-ancestors 比 X-Frame-Options 更灵活，现代浏览器优先 frame-ancestors ✓ 正确答案 D frame-ancestors 只能 DENY
# 59. Chrome 的 Protected Audience API（FLEDGE/Interest Group）在 Privacy Sandbox 广告竞拍的工程边界 A 竞拍在广告服务器公开执行 B 它依赖第三方 Cookie C 竞拍在设备端 Worklet 执行，数据不出设备，隐私友好 ✓ 正确答案 D 它无法广告竞拍
# 60. Attribution Reporting API 在转化归因与隐私约束（噪声、跨站限制）下的前端埋点设计与浏览器支持现状 A 它用噪声/延迟/跨站限制保护隐私，浏览器归因转化，无需第三方 Cookie ✓ 正确答案 B 它依赖第三方 Cookie 归因 C 归因无任何隐私约束 D 所有浏览器都支持
# 61. Fenced Frames 在 Privacy Sandbox 中的广告渲染隔离，与 iframe sandbox 的差异及对前端嵌入方案的影响 A Fenced Frames 数据可被父页面读取 B Fenced Frames 与 iframe sandbox 相同 C iframe sandbox 隔离更强 D Fenced Frames 隔离更强，父页面无法读取内容，与 iframe sandbox 不同 ✓ 正确答案
# 62. Privacy Sandbox 的 Topics API 与 Protected Audience 在第三方 Cookie 淘汰后的广告链路重构，信号获取、竞拍与归因的前端工程边界 A Topics 提供信号、Protected Audience 设备端竞拍、Attribution 归因，均在隐私沙箱内 ✓ 正确答案 B 仍依赖第三方 Cookie C 竞拍在服务端公开 D 归因无隐私约束
# 63. Shared Storage API 的键值存储与 selectURL 在隐私沙箱中的应用边界，Worklet 内不可见数据与跨站广告的工程价值 A Shared Storage 在 Worklet 内不可见处理键值，selectURL 选择 URL，用于跨站广告 ✓ 正确答案 B Shared Storage 数据可被父页面读取 C Shared Storage 依赖第三方 Cookie D Shared Storage 无法跨站
# 64. AI 以流式 Markdown 输出不可信内容时，如何把 CSP Level 3、DOMPurify 与 Trusted Types 串成唯一 DOM 写入链路，并防御半截标签、javascript: URL、SVG/MathML 和 mutation XSS A 只需其中一个防护即可 B AI 输出天然安全 C 用 Trusted Types 强制唯一写入路径 + DOMPurify 净化 + CSP，防御半截标签/javascript:/SVG/mXSS ✓ 正确答案 D 流式内容无法净化
# 65. 启用 strict-dynamic 与 nonce 后，AI 插件和第三方工具脚本仍需动态加载时，如何设计 CSP 信任链、Trusted Types policy 与 Report-Only 灰度，避免通配域名重新扩大执行面 A 第三方脚本无法安全加载 B 应添加通配域名放宽 C 用 nonce/strict-dynamic 传递信任、Trusted Types 校验 URL、Report-Only 灰度，避免通配域名 ✓ 正确答案 D 无需 Report-Only
# 66. HPKP（HTTP Public Key Pinning） A HPKP 无风险 B HPKP 是当前推荐机制 C HPKP 固定证书公钥但误配置会导致 DoS，已废弃 ✓ 正确答案 D HPKP 替代 CT
# 67. WebCrypto 的 ECDH 密钥协商在端到端加密（E2EE） A ECDH 无法协商 B ECDH 用于签名 C E2EE 密钥存服务器 D ECDH 协商共享密钥，用于 E2EE 加密，密钥只在两端 ✓ 正确答案
# 68. JWT 的 clock skew（时钟偏移）在 exp/nbf/iat 校验的边界 A 容差越大越安全 B 时钟偏移不影响校验 C 校验 exp/nbf/iat 需考虑 clock skew，设置合理容差避免误判 ✓ 正确答案 D 无需时间同步
# 69. Passkey/WebAuthn 替代传统密码与现代令牌认证的工程价值 A Passkey 用公钥密码学替代密码/令牌，抗钓鱼 ✓ 正确答案 B Passkey 与密码相同 C Passkey 无法替代 OTP D Passkey 依赖密码
# 70. JWT 在 microfrontend 跨子域传递的安全策略（SameSite/Path/HttpOnly） A 用 Cookie（Domain 父域）共享，HttpOnly+Secure+SameSite 保护 ✓ 正确答案 B 跨子域共享无风险 C HttpOnly 无法防 XSS D SameSite 与跨子域无关
# 71. Passkey 当前依赖认证器支持的签名算法，而 ML-KEM 是密钥封装、ML-DSA 是后量子签名；在 WebAuthn 尚未普遍提供 PQ 算法时，如何设计经典算法 + PQ 的混合迁移、能力协商与凭据轮换，而不把 ML-KEM 误当成 Passkey 签名 A ML-KEM 是签名、ML-DSA 是封装 B ML-KEM 可作为 Passkey 签名 C Passkey 签名用签名算法，PQ 迁移用能力协商、混合凭据与凭据轮换，不把 ML-KEM 当签名 ✓ 正确答案 D 无需能力协商
# 72. CSP 违规报告，report-to/report-uri 端点、CSP Level 3 的 Reporting API 与 violation 上报的聚合去重、采样与灰度策略？ A 全量上报无成本 B report-uri 是新的 Reporting API C 违规上报无需去重 D report-to 上报违规，需聚合去重、采样与 report-only 灰度管理 ✓ 正确答案
