安全架构面试题

本题库共收录 73 道面试题（基础 16 / 进阶 29 / 深入 18 / 架构 10）。本文件收录安全架构相关面试题，目标题量 150 道。题型覆盖：概念题、场景设计题、系统设计题、工程化题、安全题、软技能题、综合开放题。难度覆盖：基础、进阶、深入、架构。每道题除标准参考答案外，另附口头回答版，便于面试时快速组织语言。

基础题（8 道）

FB-31-CO-B-001：XSS 有哪几种类型？前端分别如何防御？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：XSS、安全防御、输入输出编码、CSP 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明 XSS 的主要类型、攻击原理，以及前端在日常开发中可采取的防御措施。

参考答案：

XSS（跨站脚本攻击）是攻击者向页面注入可执行脚本，使其在受害者浏览器中运行。

主要类型：

反射型 XSS：恶意脚本通过 URL 参数传入，服务端直接回显到页面，需要诱导用户点击链接。
存储型 XSS：恶意内容被持久化到数据库/后端存储，所有浏览该内容的用户都会触发。
DOM 型 XSS：不经过服务端，前端通过 innerHTML、eval、location.href 等操作把不可信数据写入 DOM 或执行。

前端防御：

输出编码：把用户输入展示到页面时，使用框架自带插值（如 Vue {{ }}、React 文本节点）自动转义 HTML。
避免危险 API：慎用 innerHTML、document.write、eval；如必须使用，先经过 DOMPurify 等库净化。
CSP：配置内容安全策略，限制脚本来源，禁止内联脚本或启用 nonce/hash。
Cookie 安全：设置 HttpOnly、Secure、SameSite，降低脚本窃取 Cookie 的影响。
输入校验：在表单/搜索框限制字符类型和长度，但仅作为辅助，不能替代输出编码。

评分维度：

类型区分（40%）：能否清晰区分反射、存储、DOM 三种 XSS
防御措施（40%）：输出编码、CSP、危险 API、Cookie 安全
风险意识（20%）：是否理解输入校验不能替代输出编码

常见错误：

认为只要过滤 <script> 就能防 XSS，忽略了事件处理器、伪协议等绕过方式。
混淆 DOM XSS 与反射 XSS，认为 DOM XSS 也需要服务端参与。

延伸追问：

如果项目使用富文本编辑器，如何平衡功能与 XSS 防御？
CSP 设置为 default-src 'self' 可能带来哪些业务影响？

相关题目：

FB-31-CO-A-005 CSP nonce 与 hash 的区别是什么
FB-31-CO-P-003 如何设计前端安全 SDK 防御 XSS

参考资源：

口头回答版：

XSS 分为反射型、存储型和 DOM 型。反射型通过 URL 参数触发，存储型把恶意脚本存到服务端，DOM 型则完全在前端由不可信数据触发。防御上，最重要的是输出编码，使用框架插值自动转义；少用 innerHTML 和 eval；配置 CSP 限制脚本来源；Cookie 加 HttpOnly 和 SameSite；输入校验只能做辅助。

FB-31-CO-B-002：CSRF 的攻击原理是什么？前端如何配合防御？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：CSRF、SameSite、Token、Cookie 安全 出现频率：高频 预计回答时长：3-5 分钟

题目描述：解释 CSRF 的攻击流程，并说明前端与后端协作时常用的防御方案。

参考答案：

CSRF（跨站请求伪造）利用用户已登录的会话，诱导浏览器自动携带 Cookie 向目标站点发起非预期请求。

攻击流程：

用户登录银行站点 A，Cookie 中保存了会话凭证。
用户在未退出 A 的情况下访问恶意站点 B。
B 中的表单/图片自动向 A 发起转账请求，浏览器自动带上 A 的 Cookie。
A 验证 Cookie 通过，执行操作。

防御方案：

SameSite Cookie：将 Cookie 设为 SameSite=Lax 或 Strict，阻止跨站请求自动携带。
CSRF Token：后端生成一次性 Token，前端在表单或请求头中携带，攻击者无法获取。
双重 Cookie：把 Token 同时写入 Cookie 和请求头，后端比对。
验证 Origin/Referer：后端检查请求来源。
用户交互确认：敏感操作要求二次确认或验证码。

前端配合：

确保 AJAX 库（如 axios）在请求头中携带 CSRF Token。
不绕过浏览器的同源策略或 Cookie 安全属性。

评分维度：

攻击流程（40%）：能否说明自动携带 Cookie 和诱导访问的关键
防御方案（40%）：SameSite、Token、Referer/Origin
前后端分工（20%）：前端主要配合 Token 与 Cookie 策略

常见错误：

认为 CSRF 是 XSS 的一种，或把防御 XSS 的方案用于 CSRF。
前端只依赖 SameSite 而忽略 Token，导致旧浏览器或跨站子请求场景失守。

延伸追问：

SameSite=None; Secure 的使用场景是什么？
如果前端使用 JWT 存储在 localStorage，是否还存在 CSRF 风险？

相关题目：

FB-31-CO-B-001 XSS 有哪几种类型
FB-31-CO-A-002 JWT 安全使用与风险

参考资源：

OWASP CSRF Prevention Cheat Sheet

口头回答版：

CSRF 是攻击者诱导已登录用户访问恶意页面，让浏览器自动携带目标站点的 Cookie 发起请求。防御上后端主要靠 SameSite Cookie、CSRF Token、Referer/Origin 校验；前端则要正确携带 Token，并配合 Cookie 安全属性。SameSite=Lax 能挡住大部分跨站 POST。

FB-31-CO-B-003：CSP 的作用是什么？如何在前端项目中落地？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：CSP、内容安全策略、XSS、安全响应头 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请介绍 CSP 的核心能力，并说明在项目中引入 CSP 时的配置思路与注意事项。

参考答案：

CSP（Content Security Policy）通过 HTTP 响应头告诉浏览器哪些来源的资源可以执行/加载，从而限制 XSS、数据注入等攻击。

核心指令：

default-src：默认资源来源。
script-src：脚本来源，可配合 'nonce-xxx' 或 'sha256-xxx' 允许内联脚本。
style-src：样式来源。
img-src、font-src、connect-src：分别控制图片、字体、网络请求。
frame-ancestors：控制哪些页面可以嵌入当前页。
report-uri / report-to：上报违规日志。

落地步骤：

先以 Content-Security-Policy-Report-Only 收集违规报告。
根据报告调整白名单，处理内联脚本和动态插入的资源。
正式启用 Content-Security-Policy，建议从 default-src 'self' 开始逐步放宽。
与 CI 结合，禁止新增内联脚本或外部域名未加入白名单。

注意事项：

'unsafe-inline' 会显著削弱防护效果，应尽量避免。
第三方 SDK、埋点、客服脚本需要单独加白名单。
上报端要做防刷和限流。

评分维度：

核心指令理解（40%）：能列举关键指令并说明用途
落地步骤（40%）：Report-Only、收集、启用、CI 集成
注意事项（20%）：unsafe-inline、第三方脚本、上报治理

常见错误：

直接启用严格策略导致业务大面积报错，未先 Report-Only。
使用 'unsafe-inline' 而不使用 nonce/hash，使 CSP 形同虚设。

延伸追问：

如果业务必须内联脚本，有哪些 CSP 兼容方案？
如何防止 CSP 上报接口被恶意刷量？

相关题目：

FB-31-CO-A-005 CSP nonce 与 hash 的区别是什么
FB-31-SE-P-002 CSP 绕过与深度防御

参考资源：

MDN CSP

口头回答版：

CSP 是内容安全策略，通过响应头限制浏览器只能加载指定来源的资源，从而防御 XSS。核心指令有 script-src、default-src、frame-ancestors 等。落地时先开 Report-Only 收集违规，再逐步收紧；避免 unsafe-inline，可以用 nonce 或 hash 兼容内联脚本；第三方 SDK 要单独加白名单。

FB-31-CO-B-004：HTTPS/TLS 在前端安全中起到什么作用？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：HTTPS、TLS、中间人攻击、证书 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请简述 HTTPS/TLS 的工作原理，以及它如何保护前端应用和用户数据。

参考答案：

HTTPS = HTTP + TLS/SSL，通过加密和身份认证防止数据在传输过程中被窃听、篡改或伪造。

核心作用：

加密：TLS 握手后生成会话密钥，后续通信使用对称加密，防止中间人窃听。
完整性：MAC（消息认证码）确保数据未被篡改。
身份认证：服务端证书由受信 CA 签发，客户端验证域名与证书链，防止钓鱼站点。

TLS 握手简化流程：

客户端发送支持的加密套件和随机数。
服务端返回证书、选定的加密套件和随机数。
客户端验证证书，生成 Pre-Master Secret 并用公钥加密发送。
双方通过随机数和 Pre-Master Secret 派生会话密钥。

前端注意：

全站强制 HTTPS，HSTS 头防止降级攻击。
资源（图片、脚本、API）避免混合内容（mixed content）。
使用 HTTP/2 或 HTTP/3 提升性能与安全。

评分维度：

原理说明（40%）：加密、完整性、身份认证
握手流程（30%）：随机数、证书验证、会话密钥派生
前端实践（30%）：HSTS、混合内容、全站 HTTPS

常见错误：

认为 HTTPS 只是加密，忽略了防篡改和身份认证。
站点 HTTPS 但引用了 HTTP 资源，造成混合内容警告或被拦截。

延伸追问：

TLS 1.2 与 TLS 1.3 的主要区别是什么？
如果证书过期，前端应该如何优雅降级？

相关题目：

FB-31-CO-A-006 前端敏感数据存储有哪些风险

参考资源：

MDN HTTPS

口头回答版：

HTTPS 通过 TLS 提供加密、完整性和身份认证。它防止中间人窃听和篡改，并通过证书验证服务端身份。前端要全站 HTTPS，加 HSTS，避免混合内容。

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：敏感数据、localStorage、sessionStorage、Cookie、存储安全 出现频率：高频 预计回答时长：3-5 分钟

题目描述：比较 localStorage、sessionStorage、Cookie 在安全上的差异，并说明敏感数据在前端存储的原则。

参考答案：

存储	容量	生命周期	随请求发送	安全性
Cookie	~4KB	可设置过期	是	可设 HttpOnly/Secure/SameSite
localStorage	~5MB	持久	否	同源 XSS 可读取
sessionStorage	~5MB	标签页关闭	否	同源 XSS 可读取

风险：

XSS 脚本可读取 localStorage/sessionStorage 中的 Token、个人数据。
Cookie 若未设 HttpOnly，脚本也能窃取。
敏感数据持久化到本地，可能被恶意插件、同步备份或共享设备泄露。

选择原则：

尽量不在前端存敏感数据：如用户身份证号、密码明文等。
Token：优先使用 HttpOnly Cookie + SameSite，避免前端 JS 接触。
临时状态：使用 sessionStorage 或内存，页面关闭即失效。
非敏感配置：localStorage 可缓存，但需校验完整性（签名）。
加密不是万能：前端加密密钥也会暴露给攻击者，只能增加读取门槛。

评分维度：

存储对比（40%）：容量、生命周期、是否随请求发送
风险识别（30%）：XSS、持久化、备份泄露
选择原则（30%）：敏感数据最小化、HttpOnly Cookie、内存优先

常见错误：

把 JWT 放在 localStorage 认为比 Cookie 安全，实际上 XSS 可一键窃取。
对前端加密过度信任，忽略密钥管理问题。

延伸追问：

如果业务要求 Token 在多个子域共享，如何安全实现？
移动端 WebView 的 Cookie 与浏览器 Cookie 有何差异？

相关题目：

FB-31-CO-A-002 JWT 安全使用与风险
FB-31-CO-A-006 会话管理应该注意哪些安全点

参考资源：

OWASP HTML5 Security Cheat Sheet

口头回答版：

localStorage 和 sessionStorage 容量大但可被 XSS 读取；Cookie 会随请求发送，可设 HttpOnly、Secure、SameSite。敏感数据尽量不放前端，Token 优先用 HttpOnly Cookie，临时状态放内存或 sessionStorage。

FB-31-CO-B-006：CORS 预检请求的作用是什么？前端如何正确配置？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：CORS、预检请求、同源策略、跨域 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 CORS 预检请求（Preflight）的触发条件和作用，并说明前端在开发/生产环境中应如何配合。

参考答案：

CORS（跨域资源共享）是浏览器在非同源请求时实施的安全机制。预检请求用于询问服务器是否允许某些“非简单”跨域请求。

触发预检的条件：

方法不是 GET/HEAD/POST，或 Content-Type 不是 application/x-www-form-urlencoded、multipart/form-data、text/plain。
请求头包含自定义头（如 Authorization、X-Requested-With）。

预检流程：

浏览器自动发送 OPTIONS 请求到目标地址，携带 Origin、Access-Control-Request-Method、Access-Control-Request-Headers。
服务端返回 Access-Control-Allow-Origin、允许的方法、头、缓存时间 Access-Control-Max-Age。
通过后才发送真实请求。

前端配合：

不要在代码里手动发 OPTIONS，交给浏览器自动处理。
自定义头需在后端白名单中声明。
生产环境避免 Access-Control-Allow-Origin: * 配合凭据，应指定精确域名。
缓存预检结果，减少重复 OPTIONS。

评分维度：

预检触发条件（40%）：方法、Content-Type、自定义头
预检作用（30%）：安全协商、浏览器自动机制
前端配置（30%）：自定义头、凭据、缓存

常见错误：

把 CORS 当作前端错误，试图在前端“关闭”跨域。
生产环境使用 * 且允许 withCredentials，导致凭据泄露风险。

延伸追问：

简单请求为什么不需要预检？
如果后端只返回了 Access-Control-Allow-Origin: *，前端携带 Cookie 会怎样？

相关题目：

FB-31-CO-A-003 第三方脚本风险与沙箱

参考资源：

MDN CORS

口头回答版：

CORS 预检是浏览器对非简单跨域请求先发一个 OPTIONS 询问服务器是否允许。触发条件包括非 GET/HEAD/POST 方法、自定义请求头等。前端不需要手动发 OPTIONS，只要保证自定义头在后端白名单，生产环境不要把 Origin 设为 * 同时还允许携带 Cookie。

FB-31-CO-B-007：什么是点击劫持？前端有哪些防御手段？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：点击劫持、X-Frame-Options、frame-ancestors、UI 安全 出现频率：中频 预计回答时长：3-5 分钟

题目描述：解释点击劫持的攻击方式，并列举前端/服务端可配置的防御响应头。

参考答案：

点击劫持（Clickjacking）是攻击者把目标网站通过 iframe 嵌入到恶意页面，并覆盖透明层，诱导用户点击目标站点的按钮。

防御手段：

X-Frame-Options：DENY（禁止任何框架嵌入）、SAMEORIGIN（仅同域可嵌入）、ALLOW-FROM uri（已废弃）。
CSP frame-ancestors：更现代的方案，如 frame-ancestors 'self' https://partner.com;。
JavaScript 破帧：页面顶部脚本检查 window.top === window.self，若不是则跳转。但可被禁用 JS 绕过，仅作补充。
敏感操作二次确认：转账、删除等关键操作需要二次弹窗或验证码，降低被诱导点击的影响。

配置建议：

全站默认 X-Frame-Options: DENY 或 SAMEORIGIN。
需要被第三方嵌入的页面用 CSP frame-ancestors 精确授权。

评分维度：

攻击原理（40%）：iframe 嵌入、透明层诱导
防御头（40%）：X-Frame-Options、frame-ancestors
补充措施（20%）：破帧脚本、二次确认

常见错误：

只配置前端 JS 破帧，忽略响应头，导致无 JS 环境被绕过。
把 X-Frame-Options 与 CSP 混用规则，导致冲突。

延伸追问：

如果业务需要把页面嵌入到多个合作方域名，如何优雅管理白名单？
微信公众号 H5 被嵌入 WebView，是否需要防御点击劫持？

相关题目：

FB-31-CO-B-003 CSP 的作用是什么

参考资源：

OWASP Clickjacking Defense Cheat Sheet

口头回答版：

点击劫持是把目标页面嵌到 iframe 里，上面盖透明层诱导用户点击。防御主要靠 X-Frame-Options 和 CSP 的 frame-ancestors，指定谁能嵌入；也可以用 JS 破帧和敏感操作二次确认做补充。

FB-31-CO-B-008：为什么输入校验不能替代输出编码？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：输入校验、输出编码、XSS、SQL 注入 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请从安全架构角度解释输入校验与输出编码的关系，以及为什么不能只依赖输入校验。

参考答案：

输入校验和输出编码是不同层级的防御，互为补充。

输入校验：在数据进入系统时检查格式、类型、长度、白名单，目的是拒绝坏数据、保护业务逻辑。
输出编码：在数据被展示/执行时按目标上下文转义，目的是防止可信上下文被污染。

为什么不能替代：

上下文多样：同一段用户输入可能展示在 HTML、JavaScript、CSS、URL、SQL 等不同上下文，每种编码规则不同，输入阶段无法预知。
绕过手段多：攻击者可能通过编码、大小写、注释绕过输入过滤。
数据持久化：今天合法的数据，明天在新的展示方式下可能变成攻击载荷。
边界模糊：系统内不同模块可能互相传递数据，输出编码是最后一道防线。

最佳实践：

输入做白名单校验和标准化。
输出按上下文编码（HTML 实体、JS 字符串、URL 编码、CSS 转义）。
使用框架默认转义，避免手写过滤规则。

评分维度：

概念区分（40%）：输入校验 vs 输出编码
不可替代原因（40%）：上下文、绕过、持久化
最佳实践（20%）：白名单 + 上下文编码

常见错误：

在输入阶段过滤 <script> 后认为输出时无需转义。
用正则替换做 HTML 过滤，导致绕过或误杀。

延伸追问：

在前后端分离架构中，输入校验应该放在哪一层？
输出编码在不同上下文有哪些具体做法？

相关题目：

FB-31-CO-B-001 XSS 有哪几种类型

参考资源：

OWASP XSS Prevention Cheat Sheet

口头回答版：

输入校验是拒绝坏数据，输出编码是按目标上下文转义。不能替代是因为数据最终出现在 HTML、JS、CSS、URL 等不同上下文，输入时不知道；而且过滤规则容易被绕过。正确做法是两道防线都做：输入白名单校验，输出按上下文编码。

进阶题（8 道）

FB-31-CO-A-001：OAuth 2.0 授权码流程中，前端扮演什么角色？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：OAuth 2.0、OIDC、授权码模式、Token、身份认证 出现频率：高频 预计回答时长：5-7 分钟

题目描述：请描述 OAuth 2.0 授权码模式的完整流程，并说明前端在其中的安全职责。

参考答案：

OAuth 2.0 授权码模式是授权第三方应用访问用户资源的标准流程，前端通常是用户代理（User-Agent）。

流程：

用户在前端点击“用 XX 登录”。
前端将用户重定向到授权服务器，携带 client_id、redirect_uri、scope、state。
用户登录并授权后，授权服务器重定向回 redirect_uri，携带授权码和 state。
前端把授权码交给后端。
后端用 client_id + client_secret + 授权码向授权服务器换取 Access Token/Refresh Token。
后端建立会话或把 Token 以安全方式返回给前端。

前端安全职责：

state 参数：生成并校验随机 state，防止 CSRF 攻击。
redirect_uri 一致性：确保回调地址与注册地址一致，防止授权码被截获。
不暴露 client_secret：前端不应直接用授权码换 Token，否则 secret 泄露。
PKCE：在纯前端/移动端场景使用 PKCE（Proof Key for Code Exchange），防止授权码被拦截后滥用。
安全存储 Token：遵循最小权限原则，优先使用 HttpOnly Cookie 或短期内存存储。

评分维度：

流程完整性（40%）：授权码、后端换 Token
前端职责（40%）：state、redirect_uri、PKCE、secret 保护
安全意识（20%）：Token 存储、最小权限

常见错误：

前端直接拿 client_secret 换 Token。
忽略 state 校验，导致登录态被 CSRF 劫持。
把 Access Token 长期存 localStorage。

延伸追问：

OIDC 与 OAuth 2.0 的关系是什么？
在 SPA 无后端的场景，Implicit 流程为什么不推荐？

相关题目：

FB-31-CO-A-002 JWT 安全使用与风险
FB-31-CO-B-005 前端敏感数据存储有哪些风险

参考资源：

OAuth 2.0 for Browser-Based Apps

口头回答版：

OAuth 2.0 授权码模式里，前端负责把用户重定向到授权服务器，拿到授权码后再交给后端换 Token。前端要确保 state 随机且校验，redirect_uri 一致，不泄露 client_secret；如果是纯前端应用，要用 PKCE。Token 优先用短期内存或 HttpOnly Cookie，不要长期放 localStorage。

FB-31-CO-A-002：JWT 在前端有哪些安全使用方式与常见风险？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：JWT、Token、签名、刷新令牌、安全存储 出现频率：高频 预计回答时长：5-7 分钟

题目描述：说明 JWT 的组成部分，以及前端在存储、传输、刷新 JWT 时的安全注意事项。

参考答案：

JWT 由 Header.Payload.Signature 组成，Payload 只是 Base64Url 编码，不是加密，任何人可解码。

安全使用方式：

存储：优先使用 HttpOnly Cookie + SameSite；避免 localStorage，防止 XSS 窃取。
传输：始终通过 HTTPS 发送；避免在 URL 中传递 JWT。
有效期：Access Token 设置较短有效期（分钟级），用 Refresh Token 续期。
刷新机制：Refresh Token 可轮转（rotation），每次刷新后下发新的 Refresh Token，旧的失效。
签名算法：服务端必须校验算法，禁止 alg: none 或弱算法。
撤销：敏感操作后使旧 Token 失效，必要时结合黑名单或短有效期。

常见风险：

XSS 窃取 localStorage 中的 JWT。
签名密钥泄露导致伪造。
Token 长期有效， stolen 后影响大。
客户端解析 Payload 做权限判断，被篡改后前端逻辑被绕过（应以后端校验为准）。

评分维度：

JWT 结构（20%）：Header、Payload、Signature
存储传输（30%）：HttpOnly Cookie、HTTPS、不在 URL 传递
刷新与撤销（30%）：短有效期、Refresh Token 轮转
风险意识（20%）：XSS、签名密钥、前端不依赖 Payload

常见错误：

认为 JWT 加密了 Payload。
前端根据 JWT Payload 中的 role 做关键权限控制。
Refresh Token 也长期存 localStorage 且无轮转。

延伸追问：

如果业务必须让前端持有 JWT，如何降低风险？
JWT 与 Session Cookie 各适用于什么场景？

相关题目：

FB-31-CO-B-005 前端敏感数据存储有哪些风险
FB-31-CO-A-001 OAuth 2.0 授权码流程

参考资源：

OWASP JWT Security Cheat Sheet

口头回答版：

JWT 由 Header、Payload、Signature 组成，Payload 只是编码不是加密。前端尽量用 HttpOnly Cookie 存储，不要用 localStorage；通过 HTTPS 传输；Access Token 设短有效期，用 Refresh Token 轮转续期；服务端要校验签名算法，禁止 alg none。前端不要根据 Payload 自己做权限判断。

FB-31-CO-A-003：第三方脚本（埋点、客服、广告）有哪些安全风险？如何隔离？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：第三方脚本、供应链、沙箱、CSP、子资源完整性 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请分析前端引入第三方脚本可能带来的安全与隐私风险，并说明常用的隔离与管控方案。

参考答案：

风险：

数据窃取：第三方脚本可读取页面 DOM、Cookie、localStorage、表单输入。
供应链攻击：第三方服务被入侵或恶意发布，导致前端加载恶意代码。
页面篡改：可修改按钮、钓鱼、注入广告或挖矿脚本。
隐私合规：未经同意采集用户数据，违反 GDPR/个人信息保护法。
性能与可用性：脚本故障或变慢影响主站。

隔离与管控：

CSP 白名单：只允许特定域名的脚本执行。
SRI（Subresource Integrity）：为 CDN 脚本添加 integrity 属性，校验哈希。
iframe 沙箱：把第三方内容放到 sandbox iframe，限制其能力。
代理与域名隔离：通过自己域名加载第三方脚本，减少 Cookie 暴露。
权限最小化：使用 PostMessage 通信，不直接暴露全局对象。
审计与版本锁定：定期审计第三方依赖，锁定版本，监控网络请求。
Consent 管理：加载前获取用户同意，提供关闭选项。

评分维度：

风险识别（40%）：数据窃取、供应链、篡改、合规
隔离方案（40%）：CSP、SRI、iframe、代理
治理措施（20%）：审计、版本锁定、Consent

常见错误：

无条件信任知名第三方服务商，忽略供应链风险。
使用 unsafe-inline 或 * 方便加载第三方，削弱 CSP。

延伸追问：

SRI 与 CSP 的 require-sri-for 如何配合使用？
如果第三方脚本必须访问 DOM，如何最小化暴露面？

相关题目：

FB-31-CO-A-004 前端供应链安全如何保障

参考资源：

OWASP Third Party JavaScript Management

口头回答版：

第三方脚本可能窃取数据、篡改页面、带来供应链攻击和隐私合规风险。管控方式包括 CSP 白名单、SRI 校验脚本哈希、iframe 沙箱、自己域名代理、PostMessage 通信、版本锁定和用户同意管理。

FB-31-CO-A-004：前端供应链安全如何保障？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：供应链安全、npm、依赖审计、SRI、SBOM 出现频率：高频 预计回答时长：5-7 分钟

题目描述：请从依赖管理、构建、部署、运行时等阶段说明如何保障前端供应链安全。

参考答案：

前端供应链包括 npm 包、构建工具、CI 镜像、CDN、第三方脚本等。

保障措施：

依赖治理：
- 使用 lockfile（package-lock.json / pnpm-lock.yaml）锁定版本。
- 定期运行 npm audit、pnpm audit、Snyk 扫描。
- 限制包来源（private registry、.npmrc 配置）。
- 评估依赖活跃度、维护者、体积、权限（如 postinstall 脚本）。
构建安全：
- 固定 CI 镜像和 Node 版本，使用 reproducible build。
- 禁用或审计依赖的 postinstall 脚本。
- 校验下载的二进制/原生依赖签名。
部署安全：
- 产物签名/SRI，CDN 回源 HTTPS。
- 使用私有 bucket，限制上传权限。
运行时监控：
- CSP + SRI 防止加载被篡改的脚本。
- 异常行为监控：未知域名请求、eval、document.write。
- 维护 SBOM（软件物料清单），便于漏洞响应。

评分维度：

阶段覆盖（40%）：依赖、构建、部署、运行时
具体措施（40%）：lockfile、audit、SRI、CSP、SBOM
治理意识（20%）：权限最小化、应急响应

常见错误：

只关注代码漏洞，忽略构建环境和 CDN 被篡改。
使用 latest 版本或不审查新引入依赖。

延伸追问：

如何防范依赖包的 postinstall 脚本执行恶意代码？
如果 npm 账号被盗发布恶意版本，如何快速止血？

相关题目：

FB-31-CO-A-003 第三方脚本风险与隔离
FB-31-CP-R-002 构建组织级前端安全能力平台

参考资源：

OWASP Software Supply Chain Security

口头回答版：

前端供应链安全要在依赖、构建、部署、运行时全链路治理。依赖用 lockfile 和 audit；构建固定镜像、审计 postinstall；部署产物签名、CDN HTTPS；运行时用 CSP、SRI、SBOM 和异常监控。还要控制权限、准备应急响应。

FB-31-CO-A-005：CSP nonce 与 hash 有什么区别？如何选择？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：CSP、nonce、hash、内联脚本 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请比较 CSP 中 nonce 和 hash 两种允许内联脚本的方式，并给出选型建议。

参考答案：

CSP 默认禁止内联脚本（unsafe-inline）。nonce 和 hash 是两种安全放行方式。

nonce：服务端每次请求生成随机字符串，通过响应头和 script 标签的 nonce 属性匹配。
- 适合动态生成的内联脚本。
- 必须保证不可预测且每次不同，否则失去意义。
hash：计算内联脚本的哈希值（如 SHA-256），写入 CSP 头。
- 适合内容固定的内联脚本。
- 脚本内容一旦有变化，必须重新计算 hash。

对比：

维度	nonce	hash
灵活性	高，动态脚本可用	低，内容变动需更新
维护成本	服务端每次生成	需要计算和同步 hash
适用场景	SSR、动态渲染	静态内联配置、manifest
安全性	依赖随机性	依赖脚本内容不可变

选型建议：

SSR 应用优先用 nonce。
纯静态站点或固定启动脚本可用 hash。
尽量避免 unsafe-inline。

评分维度：

原理区别（40%）：nonce 随机匹配 vs hash 内容校验
适用场景（40%）：动态/固定脚本、SSR/静态
安全意识（20%）：避免 unsafe-inline

常见错误：

nonce 复用或写死，导致可被预测。
hash 脚本内容变化后未更新，导致页面功能失效。

延伸追问：

如果使用了 nonce，还需要 'strict-dynamic' 吗？
如何在 CI 中自动计算并更新 CSP hash？

相关题目：

FB-31-CO-B-003 CSP 的作用是什么
FB-31-SE-P-002 CSP 绕过与深度防御

参考资源：

MDN CSP script-src

口头回答版：

CSP nonce 是服务端每次生成随机串，和 script 标签的 nonce 匹配，适合动态脚本；hash 是计算脚本内容哈希，适合固定内联脚本。SSR 常用 nonce，静态站点可用 hash。关键是不要用 unsafe-inline。

FB-31-CO-A-006：会话管理应该注意哪些安全点？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：会话管理、Session、Cookie、Refresh Token、超时 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请从前端视角说明会话管理中的安全要素，包括 Cookie、Token、超时、登出等。

参考答案：

会话安全要素：

Cookie 属性：
- HttpOnly：禁止 JS 读取，降低 XSS 窃取。
- Secure：仅 HTTPS 传输。
- SameSite=Lax/Strict：降低 CSRF 风险。
- Expires/Max-Age：控制生命周期。
Token 设计：
- Access Token 短效，Refresh Token 长效但需安全存储。
- Refresh Token 轮转：每次刷新后下发新 Refresh Token。
- Token 绑定设备/指纹，检测异常位置。
超时与续期：
- 设置绝对超时（如 24 小时）和空闲超时（如 30 分钟无操作）。
- 敏感操作重新认证。
登出：
- 后端使会话/Token 失效，前端清除内存和 Cookie。
- 同一账号多设备登出通知。
并发控制：限制单用户同时在线设备数，防止账号共享。

前端注意：

不主动把 Session ID 打印到日志或 localStorage。
监听用户切换账号、锁屏、关闭页面时清理敏感状态。

评分维度：

Cookie 安全（30%）：HttpOnly、Secure、SameSite
Token 管理（30%）：短效、轮转、绑定
生命周期（20%）：超时、续期、登出
前端实践（20%）：状态清理、多设备处理

常见错误：

Refresh Token 无有效期、无轮转， stolen 后长期有效。
登出仅在客户端删除 Token，后端未失效。

延伸追问：

如何实现“单点登录”与“单点登出”？
在分布式系统中如何共享会话状态？

相关题目：

FB-31-CO-A-002 JWT 安全使用与风险
FB-31-CO-B-005 前端敏感数据存储有哪些风险

参考资源：

OWASP Session Management Cheat Sheet

口头回答版：

会话管理要注意 Cookie 的 HttpOnly、Secure、SameSite，Token 短效加 Refresh Token 轮转，设置绝对和空闲超时，登出时后端失效。前端要清理内存和 Cookie，处理多设备通知，不把 Session ID 泄露到日志。

FB-31-SE-A-001：前端加密与后端加密有什么区别？前端加密能否替代 HTTPS？

题型：安全题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：加密、HTTPS、密钥管理、前端安全 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请分析前端加密的局限性，并说明为什么它不能替代 HTTPS，以及在什么场景下前端加密有意义。

参考答案：

前端加密的局限性：

密钥暴露：前端代码和密钥可被用户/攻击者获取，加密算法再强也失去意义。
无法验证服务端身份：没有 PKI 证书体系，易被中间人攻击。
无法保证完整性：单独加密不防篡改，需配合 MAC/签名。
性能与标准问题：浏览器端加密库性能有限，随机数、密钥派生等实现易出错。

不能替代 HTTPS：

HTTPS/TLS 提供加密、完整性、身份认证三重保护，是传输层标准。
前端加密无法解决证书、中间人、重放攻击等问题。

前端加密有意义的场景：

端到端加密（E2EE）：如即时通讯，消息在发送端加密，服务端无法解密。
本地数据保护：加密 localStorage/IndexedDB 中的敏感数据，配合用户密码派生密钥。
合规显示：如密码框在客户端做初步哈希，降低服务端看到明文的风险，但需配合 HTTPS。
零知识架构：数据以加密形式上传，服务端只存密文。

评分维度：

局限性（40%）：密钥暴露、身份验证、完整性
与 HTTPS 对比（30%）：传输层三重保护不可替代
适用场景（30%）：E2EE、本地加密、零知识

常见错误：

认为前端对密码加密后就安全，忽略密钥和 HTTPS 问题。
用前端加密替代后端校验，导致逻辑绕过。

延伸追问：

Web Crypto API 提供了哪些能力？
端到端加密中密钥如何分发和存储？

相关题目：

FB-31-CO-B-004 HTTPS/TLS 在前端安全中的作用
FB-31-CO-P-002 前端密钥管理

参考资源：

Web Crypto API MDN

口头回答版：

前端加密密钥会暴露，不能验证服务端身份，也不能保证完整性，所以无法替代 HTTPS。它适合端到端加密、本地数据保护和零知识架构。HTTPS 提供加密、完整性和身份认证，是传输安全的基础。

FB-31-CO-A-007：安全漏洞修复的标准流程是什么？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：漏洞管理、SDL、应急响应、修复流程 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请描述从发现安全漏洞到修复上线的完整流程，以及前端团队在每个阶段的工作。

参考答案：

标准流程：

发现与报告：安全扫描、渗透测试、Bug Bounty、内部报告。
确认与定级：复现漏洞，评估影响范围、利用难度、数据敏感度，确定 CVSS 等级。
临时止血：WAF 规则、回滚、降级功能、封禁 IP、限制访问。
根因分析：定位代码缺陷、配置问题或流程缺失。
修复：
- 输出编码/CSP 加固。
- 更新依赖、修复配置。
- 增加校验、限制权限。
验证：复测漏洞是否修复，回归相关功能，确认无新漏洞。
上线与通知：灰度发布，通知用户和监管机构（如涉及数据泄露）。
复盘与改进：更新安全规范、增加自动化检测、培训团队。

前端团队工作：

配合复现、提供代码上下文。
快速修复输出编码、CSP、依赖更新。
在 CI 中增加安全扫描，防止复发。
参与复盘，输出 Case Study。

评分维度：

流程完整性（40%）：发现、定级、止血、修复、验证、复盘
前端职责（30%）：修复、CI 扫描、复盘
应急响应（30%）：止血、灰度、通知

常见错误：

直接修复上线，未先止血，导致漏洞被继续利用。
修复后不复测，引入二次漏洞或功能回归。

延伸追问：

如何建立漏洞赏金计划或内部报告通道？
修复窗口期如何平衡安全与业务连续性？

相关题目：

FB-31-CP-R-003 安全事件应急响应流程

参考资源：

OWASP Vulnerability Management

口头回答版：

漏洞修复流程包括发现报告、确认定级、临时止血、根因分析、修复、验证、上线通知和复盘。前端要配合复现、修复输出编码和 CSP、更新依赖，并在 CI 加扫描防止复发。关键是先止血再修复，修复后必须复测。

深入题（7 道）

FB-31-CO-P-001：什么是安全左移（Shift Left Security）？前端如何落地？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：31 安全架构标签：安全左移、SDL、DevSecOps、代码审计 出现频率：高频 预计回答时长：7-10 分钟

题目描述：请解释安全左移的理念，并给出前端在需求、设计、开发、测试、发布各阶段的具体实践。

参考答案：

安全左移是把安全工作尽早融入软件开发生命周期，降低后期修复成本。

前端落地实践：

需求阶段：识别合规要求（GDPR、个保法）、敏感数据范围、第三方依赖清单。
设计阶段：
- 威胁建模（STRIDE），识别 XSS、CSRF、数据泄露等风险。
- 定义安全基线：CSP、HTTPS、Cookie 策略、权限模型。
开发阶段：
- 使用 TypeScript、ESLint 安全规则（如 no-eval、no-implied-eval）。
- 统一输出编码、表单校验、API 调用封装。
- 代码评审加入安全 Checklist。
测试阶段：
- 引入 SAST（静态应用安全测试）、依赖扫描、密钥扫描。
- 自动化 XSS/CSRF 用例、渗透测试。
发布阶段：
- 配置安全响应头（CSP、HSTS、X-Frame-Options）。
- 启用 SRI、HTTPS、最小权限。
- 灰度发布，监控异常行为。
运营阶段：
- 漏洞响应流程、安全培训、复盘改进。

组织保障：

安全 Champions 制度。
安全指标纳入团队 OKR。
安全工具集成到 CI/CD，失败则阻断。

评分维度：

理念理解（20%）：左移与后期修复成本
阶段覆盖（40%）：需求、设计、开发、测试、发布、运营
前端实践（30%）：ESLint、CSP、SAST、代码评审
组织保障（10%）：Champions、指标、CI 阻断

常见错误：

把安全左移等同于买安全扫描工具，忽略流程和文化。
只在上线前做一次扫描，未集成到日常开发。

延伸追问：

如何在快节奏迭代中平衡安全左移与交付速度？
安全扫描误报率高时怎么办？

相关题目：

FB-31-CP-R-001 大型企业前端安全架构设计
FB-31-CP-R-002 构建组织级前端安全能力平台

参考资源：

OWASP DevSecOps

口头回答版：

安全左移就是把安全提前到需求、设计、开发、测试、发布各阶段。前端要在设计时做威胁建模，开发用 TypeScript 和 ESLint 安全规则、统一输出编码，测试加 SAST 和依赖扫描，发布配 CSP、HSTS、SRI，运营建立漏洞响应和培训。关键是把安全工具集成到 CI，失败阻断。

FB-31-CO-P-002：前端密钥管理有哪些方案？各自的适用场景是什么？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：31 安全架构标签：密钥管理、Web Crypto、KMS、TEE、环境变量 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请说明前端应用中常见的密钥类型和管理方案，并分析每种方案的安全边界。

参考答案：

前端不应长期保存高敏感密钥，但某些场景需要短期或低敏感凭证。

常见方案：

环境变量（构建时注入）：
- 适合非敏感配置（如 API 基础地址、公共 CDN）。
- 不适合密钥，因为会打包进 bundle，可被反编译获取。
服务端下发（短期 Token）：
- 用户登录后后端返回短期 Access Token，前端仅存内存。
- 适合鉴权凭证，降低泄露影响面。
Web Crypto API + 用户密码派生：
- 使用 PBKDF2 从用户密码派生密钥，加密本地数据。
- 适合端到端加密、本地隐私数据。
硬件/系统级安全：
- iOS Keychain、Android Keystore、WebAuthn、TPM/TEE。
- 适合高安全场景，如支付、数字身份。
KMS/HSM（云端密钥管理）：
- 密钥存储在云端 HSM，前端通过临时凭证调用加密接口。
- 适合需要服务端协同的加解密。

安全边界：

任何纯前端的“加密”只能防君子，无法防拥有设备控制权的攻击者。
真正需要保护的密钥应放在服务端或硬件安全模块。

评分维度：

方案覆盖（40%）：环境变量、服务端下发、Web Crypto、硬件、KMS
适用场景（30%）：非敏感配置、鉴权、本地加密、高安全场景
安全边界（30%）：前端不可信、密钥不落地

常见错误：

把支付密钥、云 API Key 直接写进前端代码。
认为 localStorage 加密后就可以放密钥。

延伸追问：

小程序/APP 中如何安全存储密钥？
WebAuthn 的公私钥对如何管理？

相关题目：

FB-31-SE-A-001 前端加密与后端加密的区别
FB-31-SD-R-001 大型企业前端安全架构设计

参考资源：

OWASP Key Management Cheat Sheet

口头回答版：

前端密钥管理要根据敏感度选择方案。非敏感配置用环境变量，鉴权 Token 由服务端下发短期存内存；本地隐私数据可用 Web Crypto 加用户密码派生；高安全场景用系统 Keychain 或云端 KMS/HSM。核心原则是高敏感密钥不落地、不打包进前端。

FB-31-SE-P-001：前端零信任架构的核心原则是什么？

题型：安全题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：31 安全架构标签：零信任、最小权限、持续验证、身份认证 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请解释零信任架构的基本理念，并说明它在前端应用、API 网关、微服务中的具体体现。

参考答案：

零信任（Zero Trust）核心原则：永不信任，始终验证（Never Trust, Always Verify）。

三大支柱：

身份验证：每次访问都验证用户/设备身份（MFA、证书、设备指纹）。
最小权限：只授予完成任务所需的最小权限，按资源细粒度授权。
持续验证：不信任一次认证管全程，根据行为、位置、风险动态调整信任度。

前端体现：

登录必须 MFA，敏感操作二次认证。
Token 短效，权限按路由/按钮/接口粒度控制。
前端不依赖本地角色判断，关键权限由后端/网关校验。
设备指纹、行为风控（异常登录、IP、操作频率）。

API 网关/微服务体现：

mTLS 服务间认证。
每个服务独立鉴权，不因为来自内网就信任。
请求链路上下文传递用户身份与权限。
审计日志全覆盖。

评分维度：

核心原则（30%）：永不信任、始终验证
三大支柱（30%）：身份验证、最小权限、持续验证
前端体现（20%）：MFA、短效 Token、细粒度权限
后端/网关体现（20%）：mTLS、服务鉴权、审计

常见错误：

认为零信任就是“内网也不信任”，忽略了身份和权限的动态管理。
前端存储完整权限树做控制，后端不二次校验。

延伸追问：

零信任与 RBAC/ABAC 的关系是什么？
如何在 SPA 中实现细粒度按钮级权限？

相关题目：

FB-31-SD-R-001 大型企业前端安全架构设计

参考资源：

NIST Zero Trust Architecture

口头回答版：

零信任就是永不信任、始终验证。核心是身份验证、最小权限和持续验证。前端要 MFA、Token 短效、权限由后端校验；API 网关和服务间用 mTLS 和独立鉴权，全链路审计。不能前端自己判断权限就完事。

FB-31-SE-P-002：CSP 有哪些常见绕过方式？如何构建深度防御？

题型：安全题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：31 安全架构标签：CSP、绕过、深度防御、XSS 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请分析 CSP 在实际应用中可能被绕过的场景，并提出多层防御的建设思路。

参考答案：

CSP 绕过方式：

unsafe-inline/unsafe-eval：允许内联脚本或 eval，直接破坏 CSP。
JSONP/Angular 模板注入：某些白名单域名提供动态脚本执行能力（如 JSONP 接口、AngularJS 模板）。
script-src 白名单过大：允许 CDN 或子域名，而这些域名下有可被利用的接口。
base-uri 未限制：攻击者修改 <base> 标签，改变相对路径脚本来源。
CSP 报告模式绕过：某些浏览器解析差异或 Header 优先级问题。
meta 标签覆盖：通过 <meta http-equiv> 设置较弱 CSP（若服务端策略已存在则不会覆盖，但早期浏览器可能有问题）。

深度防御：

严格 CSP：default-src 'self'、不用 unsafe-inline、用 nonce/hash。
限制 base-uri、form-action、frame-ancestors。
输出编码仍是最重要防线。
使用 Trusted Types 限制 DOM XSS 入口。
依赖扫描，防止引入生成内联脚本的库。
监控 CSP 违规报告，发现绕过尝试。
多层校验：输入校验、输出编码、CSP、SRI、HTTPS、Cookie 安全。

评分维度：

绕过场景（40%）：unsafe-inline、JSONP、base-uri、白名单过大
防御措施（40%）：严格 CSP、Trusted Types、输出编码、SRI
监控治理（20%）：CSP 报告、依赖扫描、多层校验

常见错误：

配置 CSP 后认为万事大吉，忽略输出编码。
白名单中加入 *.googleapis.com 等过于宽泛的域名。

延伸追问：

Trusted Types 如何与 CSP 配合使用？
如何评估 CSP 的强度并持续优化？

相关题目：

FB-31-CO-B-003 CSP 的作用是什么
FB-31-CO-A-005 CSP nonce 与 hash

参考资源：

Google CSP Evaluator

口头回答版：

CSP 常见绕过包括 unsafe-inline、unsafe-eval、JSONP 接口、白名单域名过大、base-uri 未限制等。深度防御要配严格 CSP、限制 base-uri、继续做好输出编码、引入 Trusted Types、依赖扫描和 CSP 报告监控。记住 CSP 是补充，不是替代输出编码。

FB-31-CD-P-001：如何设计一个前端安全 SDK？

题型：场景设计题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：31 安全架构标签：安全 SDK、XSS、CSRF、中间件、防御 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请设计一个可复用的前端安全 SDK，覆盖 XSS、CSRF、敏感数据保护等能力，并说明接入方式与扩展点。

参考答案：

目标：为各业务线提供统一、可配置、低侵入的安全能力。

核心模块：

XSS 防御：
- 提供 escapeHTML、escapeJS、escapeURL 工具函数。
- 对 innerHTML、setAttribute 等危险操作做拦截或告警。
CSRF 防御：
- 自动从 Cookie 或 meta 标签读取 CSRF Token，注入请求头。
- 检测 SameSite 缺失并告警。
请求安全：
- 封装 fetch/axios，强制 HTTPS、校验响应 Content-Type。
- 敏感字段自动脱敏/不打印日志。
敏感数据处理：
- 提供内存加密/解密工具，禁止持久化敏感字段。
- 检测 localStorage 中敏感 key 并告警。
CSP/响应头辅助：
- 提供 nonce 生成/注入 helper（配合 SSR）。
- 检测页面是否缺失关键安全头。
运行时监控：
- 监听 eval、document.write、可疑外链脚本，上报安全事件。

接入方式：

npm 包 + 初始化调用。
提供 Webpack/Vite 插件做静态检查。
与框架（React/Vue）集成，提供安全组件（如 SafeHTML）。

扩展点：

策略配置中心，按业务调整规则。
插件机制接入自定义检测。
与 Sentry、日志平台打通。

评分维度：

模块设计（40%）：XSS、CSRF、请求、敏感数据、监控
接入方式（20%）：npm、插件、框架组件
可扩展性（20%）：配置中心、插件、平台打通
安全深度（20%）：不仅是工具，还要能告警和阻断

常见错误：

SDK 只提供转义函数，没有运行时监控和告警。
接入方式侵入性强，业务不愿使用。

延伸追问：

如何在不修改业务代码的情况下拦截危险 API？
SDK 本身被绕过怎么办？

相关题目：

FB-31-CO-B-001 XSS 有哪几种类型
FB-31-CO-A-004 前端供应链安全

参考资源：

OWASP Proactive Controls

口头回答版：

前端安全 SDK 要统一提供 XSS 转义、CSRF Token 注入、请求 HTTPS 校验、敏感数据内存处理、CSP nonce 辅助和运行时监控。通过 npm 包、构建插件、框架组件接入，支持配置中心和插件扩展。关键是低侵入、能告警、能阻断。

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：31 安全架构标签：隐私合规、GDPR、个人信息保护法、Consent、数据最小化 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请说明 GDPR 和国内个人信息保护法对前端数据采集、存储、传输、删除的技术要求。

参考答案：

核心法律要求映射到前端：

告知同意：
- 在采集前通过弹窗/横幅告知用户目的、范围、存储期限。
- 用户未同意前不加载非必要埋点/广告脚本。
数据最小化：
- 只采集业务必需字段，避免过度获取通讯录、定位、剪贴板等敏感权限。
- 前端表单做字段级脱敏，不提交明文身份证/银行卡全号。
目的限制：
- 采集数据仅用于声明目的，不擅自共享给第三方。
存储期限：
- 本地缓存设置 TTL，超期自动清理。
- 提供用户删除入口（账号注销、清空本地数据）。
数据安全：
- 传输加密（TLS 1.2+）、敏感字段加密、访问控制。
- 日志中不打用户敏感信息。
用户权利：
- 提供导出、更正、删除个人数据的入口。
- 未成年人需额外保护（年龄校验、监护人同意）。
跨境传输：
- 数据出境需符合法律评估和合同约束。

前端实践：

Consent Management Platform（CMP）控制脚本加载。
埋点 SDK 支持同意状态开关。
本地数据加密 + TTL。
隐私协议链接常驻页脚。

评分维度：

法律要求（40%）：告知同意、最小化、目的限制、存储期限
技术措施（40%）：Consent、脱敏、加密、TTL、日志脱敏
用户权利（20%）：导出、删除、未成年人保护

常见错误：

默认加载所有埋点，再让用户关闭，违反“默认最小化”。
把用户同意当作一次性动作，不同意就无法使用核心功能（强制同意）。

延伸追问：

如何实现按用户同意状态动态加载第三方脚本？
数据出境时前端需要做哪些配合？

相关题目：

FB-31-CO-A-003 第三方脚本风险与隔离
FB-31-SD-R-001 大型企业前端安全架构设计

参考资源：

口头回答版：

隐私合规要求前端在采集前告知并获取同意、只采最小必要数据、限制用途、设存储期限、加密传输、支持用户导出和删除。实践上要用 CMP 控制脚本加载、埋点 SDK 按同意状态开关、本地数据加密加 TTL、日志脱敏。

FB-31-SE-P-003：什么是前端运行时应用自保护（RASP）？

题型：安全题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：31 安全架构标签：RASP、运行时保护、监控、攻击检测 出现频率：低频 预计回答时长：7-10 分钟

题目描述：请解释前端 RASP 的概念、实现方式、优缺点，以及适用场景。

参考答案：

RASP（Runtime Application Self-Protection）是在应用运行时检测并阻断攻击的安全机制。前端 RASP 通过在 JS 运行时 Hook 关键 API，识别异常行为。

实现方式：

Hook 危险 API：
- eval、Function、setTimeout、setInterval、document.write、innerHTML、fetch。
监控异常输入输出：
- 检测用户输入是否进入 DOM/执行上下文。
- 检测敏感数据是否被外发。
行为基线：
- 建立正常调用栈、域名、参数模式基线，偏离即告警。
主动阻断：
- 对疑似攻击调用抛出异常、清空输入、上报事件。

优点：

对未知攻击也有一定检测能力。
不依赖静态规则，能发现绕过。

缺点：

性能开销，需要精确 Hook。
可能被攻击者先执行代码后卸载 Hook。
误报可能影响正常功能。

适用场景：

金融、支付、政务等高安全要求页面。
作为 WAF/CSP 之后的纵深防御层。

评分维度：

概念理解（30%）：运行时自保护
实现方式（30%）：Hook、监控、基线、阻断
优缺点（20%）：未知攻击、性能、误报、绕过
适用场景（20%）：金融支付、纵深防御

常见错误：

把 RASP 当作唯一防线，忽略输入校验和 CSP。
Hook 过多导致页面性能显著下降。

延伸追问：

如何防止攻击者通过原型链污染绕过 RASP？
RASP 与 WAF 的区别和协同方式？

相关题目：

FB-31-CD-P-001 如何设计前端安全 SDK

参考资源：

OWASP RASP

口头回答版：

前端 RASP 是在运行时 Hook eval、innerHTML、fetch 等危险 API，监控异常输入输出和行为基线，主动阻断攻击。优点是可能检测未知攻击，缺点是性能开销和可能被绕过。适合金融、支付等高安全场景，作为纵深防御层。

架构题（50 道）

FB-31-SD-R-001：如何为大型企业设计前端安全架构？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：31 安全架构标签：企业安全架构、SDL、零信任、CSP、纵深防御 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请从组织、流程、技术三个维度，为大型企业设计一套前端安全架构，覆盖开发、测试、上线、运营全生命周期。

参考答案：

企业前端安全架构应形成“人、流程、技术”三位一体的纵深防御体系。

组织维度：

设立安全团队/架构师，制定前端安全基线。
每个业务团队设安全 Champion，负责落地与培训。
建立漏洞响应小组（CSIRT）和 on-call 机制。

流程维度：

需求/设计：威胁建模、隐私影响评估、安全评审。
开发：安全编码规范、代码评审 Checklist、Secret 扫描。
测试：SAST、DAST、依赖扫描、渗透测试。
发布：安全头配置、SRI、灰度、金丝雀。
运营：监控告警、事件响应、复盘改进、红蓝对抗。

技术维度：

基础层：全站 HTTPS、HSTS、DNSSEC、WAF。
应用层：输出编码、CSP、CSRF Token、身份认证（SSO/MFA）。
数据层：敏感数据最小化、加密、脱敏、访问日志。
运行层：RASP、异常行为检测、CSP 报告、错误监控。
治理层：SBOM、资产测绘、统一安全 SDK、安全度量 Dashboard。

关键指标：

漏洞平均修复时间（MTTR）。
高危漏洞数量趋势。
安全扫描覆盖率与阻断率。
安全培训覆盖率。

评分维度：

维度完整性（30%）：组织、流程、技术
生命周期覆盖（30%）：需求、开发、测试、发布、运营
技术深度（30%）：纵深防御、零信任、监控、治理
可落地性（10%）：指标、责任、工具链

常见错误：

只堆砌安全工具，没有流程和人员保障。
安全要求脱离业务实际，导致团队抵触。

延伸追问：

如何在多 BU、多技术栈企业中统一安全基线？
安全投入如何量化 ROI？

相关题目：

FB-31-CP-R-002 构建组织级前端安全能力平台
FB-31-CP-R-004 安全架构评审清单与 ADR

参考资源：

OWASP SAMM

口头回答版：

大企业前端安全要从组织、流程、技术三方面建体系。组织上设安全团队和安全 Champion；流程上做威胁建模、安全编码、SAST/DAST、灰度发布和事件响应；技术上 HTTPS、CSP、输出编码、零信任、RASP、SBOM、统一安全 SDK 多层防御。还要有 MTTR、漏洞趋势等指标衡量效果。

FB-31-CP-R-002：如何构建组织级前端安全能力平台？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：31 安全架构标签：安全平台、安全能力、治理、DevSecOps、SDL 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个可供全公司前端团队复用的安全能力平台，说明其模块、接入方式与运营模式。

参考答案：

平台目标：降低业务团队安全建设成本，统一标准、工具、数据和响应。

核心模块：

安全规范与模板：
- 前端安全编码规范、Checklist、安全 ADR 模板。
- 项目初始化模板内置安全依赖与配置。
安全工具链：
- 依赖扫描（npm audit、Snyk）。
- 静态扫描（ESLint 安全规则、Semgrep、CodeQL）。
- Secret 扫描（gitleaks、truffleHog）。
- 镜像/产物扫描。
安全 SDK/组件库：
- XSS 转义、CSRF Token、请求封装、敏感数据处理。
- Vue/React 安全组件（SafeHTML、AuthGuard）。
配置中心：
- 统一 CSP、安全头、Cookie 策略、白名单管理。
- 按环境/业务下发策略。
监控与响应：
- CSP 违规、异常行为、漏洞情报接入。
- 一键创建漏洞工单、自动通知责任人。
度量与培训：
- 安全 Dashboard、团队安全评分、漏洞趋势。
- 在线课程、攻防演练。

接入方式：

CLI/Scaffold 初始化项目即集成。
CI 插件，失败阻断。
npm 包 + 框架插件。

运营模式：

平台团队负责维护工具链与规则库。
业务团队负责接入与修复。
安全团队制定基线、审计结果、推动改进。
定期红蓝对抗和复盘。

评分维度：

模块完整性（40%）：规范、工具链、SDK、配置、监控、培训
接入方式（20%）：脚手架、CI、npm、插件
运营模式（20%）：平台/业务/安全团队分工
可扩展性（20%）：规则库、策略下发、数据打通

常见错误：

平台只建工具，不解决业务接入痛点。
缺乏度量，无法持续改进。

延伸追问：

如何处理业务团队对安全扫描误报的抵触？
平台安全规则如何版本化与灰度？

相关题目：

FB-31-SD-R-001 大型企业前端安全架构设计
FB-31-CP-R-004 安全架构评审清单与 ADR

参考资源：

OWASP DevSecOps

口头回答版：

组织级安全平台要统一规范、工具链、SDK、配置中心、监控和培训。通过脚手架、CI 插件、npm 包接入，平台团队维护，业务团队使用，安全团队定基线。关键是降低接入成本、量化度量、持续红蓝对抗。

FB-31-CP-R-003：安全事件应急响应流程应该如何设计？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：31 安全架构标签：应急响应、安全事件、流程、止血、复盘 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请设计一套前端安全事件应急响应流程，包括发现、定级、止血、修复、复盘等环节，并说明沟通机制。

参考答案：

应急响应流程（PDCA 变体）：

发现与上报：
- 来源：监控告警、用户反馈、白帽报告、监管通报、扫描。
- 建立统一入口（邮件、IM 机器人、工单）。
确认与定级：
- 复现漏洞，评估影响面、数据敏感度、利用难度。
- 定级：P0（线上重大数据泄露/资金损失）、P1（高危可主动利用）、P2（中危需配合）、P3（低危）。
止血：
- 封禁 IP/账号、WAF 规则、回滚版本、关闭功能、强制登出、撤销 Token。
- 保留日志和现场，不破坏证据。
修复与验证：
- 制定修复方案，开发验证，灰度发布。
- 复测确认漏洞闭合，回归相关功能。
通报与合规：
- 内部通报影响范围、根因、修复计划。
- 如涉及用户数据泄露，按法律要求向监管和用户披露。
复盘与改进：
- 5 Whys 分析根因。
- 更新规范、工具规则、培训案例。
- 衡量 MTTR、复发率。

沟通机制：

设立应急群/会议室，固定角色：指挥官、技术负责人、沟通负责人、法务/合规。
对外口径统一，避免信息不一致。

评分维度：

流程完整性（40%）：发现、定级、止血、修复、通报、复盘
定级与止血（30%）：分级标准、快速止血
沟通机制（20%）：角色、统一口径
复盘改进（10%）：根因、规范更新、度量

常见错误：

未止血直接修复上线，导致持续被利用。
应急群信息过载，缺乏统一指挥。

延伸追问：

如何在凌晨低人力情况下实现自动止血？
数据泄露事件中如何评估是否需向监管报告？

相关题目：

FB-31-CO-A-007 安全漏洞修复的标准流程
FB-31-SD-R-001 大型企业前端安全架构设计

参考资源：

NIST Computer Security Incident Handling Guide

口头回答版：

应急响应流程包括发现上报、确认定级、快速止血、修复验证、通报合规、复盘改进。止血最关键，要保留日志。设立指挥官、技术、沟通、法务角色，统一口径。复盘用 5 Whys 找根因，更新规范和工具规则。

FB-31-CP-R-004：安全架构评审清单与 ADR 应该怎么写？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：31 安全架构标签：安全评审、ADR、架构决策、Checklist、威胁建模 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请给出一份前端安全架构评审 Checklist，并说明如何用 ADR 记录关键安全决策。

参考答案：

安全架构评审 Checklist（前端视角）：

身份与访问：是否使用 SSO/MFA？Token 如何存储与刷新？权限是否后端校验？
数据传输：是否全站 HTTPS？HSTS？敏感接口是否加密/签名？
输入输出：是否统一输出编码？富文本如何处理？是否使用 DOMPurify？
会话安全：Cookie 是否 HttpOnly/Secure/SameSite？会话超时与登出设计？
内容安全：CSP 策略？SRI？X-Frame-Options？第三方脚本白名单？
数据保护：敏感数据是否最小化采集？本地存储是否加密/TTL？日志是否脱敏？
供应链：依赖是否锁定版本？是否定期 audit？构建镜像是否可信？
可观测性：是否有 CSP 报告、异常行为监控、错误上报？
合规：GDPR/个保法是否满足？Consent 机制？数据出境评估？
应急响应：是否有止血预案、联系人、复盘流程？

ADR（Architecture Decision Record）写法：

标题：如“采用 CSP nonce 策略允许 SSR 内联脚本”。
背景：问题与约束。
决策：选择方案及理由。
影响：对性能、开发、安全的影响。
替代方案：为什么不选其他方案。
风险与缓解：如 nonce 泄露风险及 rotation 策略。
状态：proposed/accepted/deprecated。

评分维度：

Checklist 覆盖（40%）：身份、传输、输入输出、会话、内容、数据、供应链、可观测、合规、应急
ADR 结构（30%）：背景、决策、影响、替代、风险
落地意识（30%）：与 CI、培训、度量的结合

常见错误：

Checklist 流于形式，评审时未结合具体业务风险。
ADR 只写结论，不写拒绝方案的理由。

延伸追问：

如何让评审 Checklist 不被业务团队视为负担？
ADR 应该由谁维护、何时更新？

相关题目：

FB-31-SD-R-001 大型企业前端安全架构设计
FB-31-CP-R-002 构建组织级前端安全能力平台

参考资源：

Michael Nygard ADR

口头回答版：

安全评审清单要覆盖身份访问、HTTPS、输入输出编码、Cookie、CSP、SRI、敏感数据、供应链、监控、合规、应急。ADR 要记录背景、决策、影响、替代方案和风险缓解。关键是让评审结合业务威胁，而不是走形式。

FB-31-SD-R-002：微前端场景下如何做好安全隔离？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：31 安全架构标签：微前端、安全隔离、沙箱、CSP、子应用 出现频率：中频 预计回答时长：10-15 分钟

题目描述：在微前端架构中，主子应用、子应用之间可能存在安全边界。请设计安全隔离方案。

参考答案：

微前端安全风险：

子应用 XSS 可能污染主应用全局对象、路由、DOM。
子应用间共享依赖可能被恶意注入。
子应用越权访问父应用或兄弟应用数据。
子应用加载来源不可控，存在供应链风险。

隔离方案：

JS 沙箱：
- Proxy 沙箱：隔离 window 对象变更，子应用卸载后还原。
- snapshot 沙箱：保存/恢复快照，适合不支持 Proxy 的环境。
样式隔离：Shadow DOM、CSS Scope、命名空间前缀。
路由隔离：主应用统一路由守卫，子应用只能注册自己的路径。
通信隔离：通过规定的事件总线/Props 通信，禁止直接访问子应用内部状态。
加载隔离：
- 子应用资源使用独立域名/子路径，CSP 单独配置。
- SRI 校验子应用入口 JS。
- 对不可信子应用使用 iframe + PostMessage。
权限隔离：
- 主应用统一鉴权，按子应用分发最小权限 Token。
- 子应用内按钮级权限由主应用下发，后端二次校验。

监控与治理：

子应用加载来源白名单。
运行时检测全局变量污染、异常网络请求。
子应用安全评分纳入发布门禁。

评分维度：

风险识别（30%）：XSS、越权、供应链、全局污染
隔离方案（40%）：JS 沙箱、样式、路由、通信、加载、权限
治理措施（30%）：白名单、SRI、CSP、评分门禁

常见错误：

认为微前端天然隔离，忽略全局对象共享风险。
子应用随意访问主应用全局状态。

延伸追问：

iframe 微前端与 JS 沙箱微前端各适合什么场景？
子应用独立部署后，如何防止版本回滚引入旧漏洞？

相关题目：

FB-31-SD-R-001 大型企业前端安全架构设计
FB-26-SD-R-001 微前端安全隔离

参考资源：

qiankun 沙箱实现

口头回答版：

微前端安全要用 JS 沙箱隔离 window、Shadow DOM 隔离样式、主应用统一路由和鉴权、子应用间通过事件总线通信。加载子应用用白名单、SRI、独立域名或 iframe，CSP 也要单独配。还要监控全局污染和异常请求。

FB-31-SD-R-003：前后端安全边界应该如何划分？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：31 安全架构标签：前后端边界、安全责任、鉴权、输入校验、纵深防御 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请说明前端和后端在安全防护上的职责边界，并解释为什么某些防御必须两端同时做。

参考答案：

职责边界：

安全领域	前端职责	后端职责
输入校验	用户体验层校验（格式、长度、即时反馈）	服务端最终校验（白名单、业务规则）
输出编码	展示时按上下文转义	API 返回数据结构安全
身份认证	引导登录、安全存储凭证、MFA 交互	签发/校验 Token、会话管理
权限控制	UI 层面隐藏无权限入口	接口/数据权限校验
CSRF	配合 SameSite、Token 注入	SameSite、Token 生成与校验
XSS	输出编码、CSP、避免危险 API	过滤/转义返回数据、CSP 头
敏感数据	最小化采集、不持久化	加密存储、访问控制、审计
日志审计	不上传敏感日志	服务端完整审计

必须两端同时做的原因：

前端代码可被绕过、禁用、反编译，不能作为安全最终防线。
后端无法完全阻止用户发送恶意请求，需要前端减少误提交和暴露面。
纵深防御：单点失守仍有其他防线。

协作机制：

统一安全接口规范（Token 位置、错误码、限流策略）。
共享威胁模型和漏洞情报。
共同制定安全基线和 SLA。

评分维度：

边界清晰（40%）：能区分前后端各自职责
两端协同（30%）：为什么必须都做
纵深防御（30%）：多道防线、协作机制

常见错误：

前端做权限判断后后端不再校验。
后端认为输入校验是前端的事，导致 API 被直接攻击。

延伸追问：

在 BFF 架构中，安全边界如何变化？
如何防止前端绕过权限隐藏直接调用后端接口？

相关题目：

FB-31-SD-R-001 大型企业前端安全架构设计
FB-31-SD-R-002 微前端场景下如何做好安全隔离

参考资源：

OWASP Proactive Controls

口头回答版：

前端负责用户体验层校验、输出编码、凭证安全存储、MFA 交互和 UI 权限；后端负责最终校验、鉴权、会话、数据权限和审计。两者必须都做，因为前端可被绕过，后端无法阻止恶意请求。要建立统一规范、共享威胁模型，形成纵深防御。

FB-31-SS-R-001：如何推动团队提升安全意识？

题型：软技能题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：31 安全架构标签：安全意识、培训、文化建设、推动落地 出现频率：中频 预计回答时长：10-15 分钟

题目描述：作为安全负责人或架构师，你如何推动开发团队把安全要求落到日常工作中？

参考答案：

推动思路：让安全变得可感知、可衡量、低门槛。

具体措施：

建立共同语言：
- 用真实 Case 讲解漏洞危害（如 XSS 盗取 Cookie、npm 恶意包）。
- 定期发布内部安全月报。
工具左移：
- 把安全扫描集成到 IDE/Pre-commit/CI，即时反馈，不增加额外流程。
- 提供自动修复建议（如 Dependabot、 Renovate）。
量化指标：
- 将漏洞数量、修复时长、扫描覆盖率纳入团队 OKR。
- 设立安全排行榜和奖励。
降低接入成本：
- 提供安全 SDK、脚手架模板、ADR 模板。
- 文档和 FAQ 覆盖常见场景。
培训与演练：
- 新员工安全培训、定期攻防演练、CTF。
- 邀请白帽做内部渗透测试并公开复盘。
文化建设：
- 领导层背书，明确安全是质量的一部分。
- 不惩罚发现漏洞的人，奖励主动报告和修复。

应对抵触：

先解决业务痛点（如扫描误报高则优化规则）。
从高频、低风险问题入手，逐步建立信任。
用数据说话，展示安全漏洞带来的真实损失。

评分维度：

方法多样性（40%）：培训、工具、指标、文化
降低门槛（30%）：工具左移、模板、自动修复
推动策略（30%）：领导背书、数据说话、循序渐进

常见错误：

仅发规范文档，不配套工具和培训。
对漏洞责任人处罚过重，导致隐瞒问题。

延伸追问：

如何平衡安全要求与交付速度？
如果团队 leader 不重视安全怎么办？

相关题目：

FB-31-CP-R-002 构建组织级前端安全能力平台
FB-31-CP-R-003 安全事件应急响应流程

参考资源：

OWASP Security Culture

口头回答版：

推动安全意识要让安全可感知、可衡量、低门槛。具体做法有真实案例培训、把扫描集成到 CI/IDE、量化指标进 OKR、提供 SDK 和模板、定期攻防演练、领导背书。遇到抵触先解决误报等痛点，用数据说话，不惩罚报告者。

FB-31-CO-B-009：什么是威胁建模？前端为什么需要威胁建模？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：CSP、XSS、SDL、Token、CSRF 出现频率：中频 预计回答时长：3-5 分钟

题目描述：什么是威胁建模？前端为什么需要威胁建模。

参考答案：

威胁建模是一种结构化方法，用于识别系统面临的潜在威胁并设计缓解措施。前端需要威胁建模是因为现代前端涉及大量用户交互、第三方依赖、敏感数据和 API 调用，存在复杂的攻击面。

补充说明：

在实际落地威胁建模前端为什么需要威胁建模时，建议结合 CSP、XSS、SDL 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

定义准确（40%）
说明前端场景（40%）
举例说明（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

威胁建模是一种结构化方法，用于识别系统面临的潜在威胁并设计缓解措施。前端需要威胁建模是因为现代前端涉及大量用户交互、第三方依赖、敏感数据和 API 调用，存在复杂的攻击面。

FB-31-CO-B-010：解释 STRIDE 模型。

题目描述：解释 STRIDE 模型。。

参考答案：

STRIDE 是六种威胁类型的缩写：

Spoofing：伪装
Tampering：篡改
Repudiation：抵赖
Information Disclosure：信息泄露
Denial of Service：拒绝服务
Elevation of Privilege：权限提升

评分维度：

完整解释六项（60%）
前端示例（30%）
表达清晰（10%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

STRIDE 是六种威胁类型的缩写： - Spoofing：伪装 - Tampering：篡改 - Repudiation：抵赖 - Information Disclosure：信息泄露 - Denial of Service：拒绝服务 - Elevation of Privilege：权限提升

FB-31-CO-B-011：CSP 能解决什么问题？给出一个基本配置示例。

题目描述： CSP 能解决什么问题？给出一个基本配置示例。。

参考答案：

CSP（Content Security Policy）用于防御 XSS 和数据注入，限制页面可以加载的资源来源。

http

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'

评分维度：

说明作用（40%）
写出配置（40%）
解释指令（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

CSP（Content Security Policy）用于防御 XSS 和数据注入，限制页面可以加载的资源来源。

FB-31-SE-B-001：什么是供应链安全？前端如何防护？

题型：安全题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：CSP、XSS、SDL、Token、CSRF 出现频率：中频 预计回答时长：3-5 分钟

题目描述：什么是供应链安全？前端如何防护。

参考答案：

供应链安全指防止第三方依赖、工具、CDN 资源被篡改或植入恶意代码。前端防护措施包括：依赖审计、lockfile、SRI、私有 registry、定期更新、关键依赖源码审查。

补充说明：

在实际落地供应链安全前端如何防护时，建议结合 CSP、XSS、SDL 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

解释概念（30%）
列举防护措施（50%）
结合自身经验（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

供应链安全指防止第三方依赖、工具、CDN 资源被篡改或植入恶意代码。前端防护措施包括：依赖审计、lockfile、SRI、私有 registry、定期更新、关键依赖源码审查。

FB-31-SE-B-002：前端如何处理用户身份认证安全？

题目描述：前端如何处理用户身份认证安全。

参考答案：

Access Token 短期有效，尽量存内存。
Refresh Token 存 HttpOnly Cookie。
使用 OAuth 2.0 + PKCE 流程。
服务端做最终权限校验。
注销时清除 Token 和客户端状态。

补充说明：

在实际落地前端如何处理用户身份认证安全时，建议结合 CSP、XSS、SDL 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

Token 存储（40%）
认证流程（30%）
权限控制（30%）

二、进阶题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

Access Token 短期有效，尽量存内存。 - Refresh Token 存 HttpOnly Cookie。 - 使用 OAuth 2.0 + PKCE 流程。 - 服务端做最终权限校验。

FB-31-SE-A-002：什么是安全左移？前端如何实践？

题型：安全题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：CSP、XSS、SDL、Token、CSRF 出现频率：中频 预计回答时长：5-8 分钟

题目描述：什么是安全左移？前端如何实践。

参考答案：

安全左移指将安全实践融入软件开发生命周期的早期阶段。前端实践包括：需求阶段识别敏感数据、设计阶段威胁建模、编码阶段安全规范、CI 阶段 SAST/依赖审计、发布前渗透测试。

补充说明：

在实际落地安全左移前端如何实践时，建议结合 CSP、XSS、SDL 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

解释概念（30%）
分阶段说明（50%）
工具举例（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

安全左移指将安全实践融入软件开发生命周期的早期阶段。前端实践包括：需求阶段识别敏感数据、设计阶段威胁建模、编码阶段安全规范、CI 阶段 SAST/依赖审计、发布前渗透测试。

FB-31-SD-A-001：如何设计一个隐私合规的前端应用？

题型：系统设计题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：CSP、XSS、SDL、Token、CSRF 出现频率：中频 预计回答时长：5-8 分钟

题目描述：如何设计一个隐私合规的前端应用。

参考答案：

数据最小化：只收集必要数据。
告知同意：明确告知用户数据用途并获得同意。
敏感数据不存本地：避免 localStorage 存 Token、PII。
可撤回：提供撤回同意入口。
埋点脱敏：避免上报敏感信息。
支持 DNT/GPC。

补充说明：

在实际落地设计一个隐私合规的前端应用时，建议结合 CSP、XSS、SDL 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 补充说明：

在实际落地设计一个隐私合规的前端应用时，建议结合 CSP、XSS、SDL 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

原则说明（40%）
前端实践（40%）
合规意识（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

数据最小化：只收集必要数据。 - 告知同意：明确告知用户数据用途并获得同意。 - 敏感数据不存本地：避免 localStorage 存 Token、PII。 - 可撤回：提供撤回同意入口。

FB-31-CO-A-008：第三方脚本有哪些风险？如何治理？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：CSP、XSS、SDL、Token、CSRF 出现频率：中频 预计回答时长：5-8 分钟

题目描述：第三方脚本有哪些风险？如何治理。

参考答案：

风险：窃取数据、篡改页面、引入漏洞、影响性能。

治理：

CSP 限制脚本来源。
使用 SRI 校验。
iframe/Shadow DOM 隔离。
Partytown 移到 Web Worker。
定期审计第三方脚本。

补充说明：

在实际落地第三方脚本有哪些风险如何治理时，建议结合 CSP、XSS、SDL 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

风险识别（30%）
治理措施（50%）
实际案例（20%）

三、高级题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

风险：窃取数据、篡改页面、引入漏洞、影响性能。治理： - CSP 限制脚本来源。 - 使用 SRI 校验。 - iframe/Shadow DOM 隔离。

FB-31-CO-B-012：前端常见安全威胁有哪些

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：XSS、CSRF、安全、前端威胁、注入 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请列举前端常见的安全威胁及基本防护思路。

参考答案：

核心思路如下：

XSS：跨站脚本，通过输入注入恶意脚本
CSRF：跨站请求伪造，诱导用户发起非预期请求
点击劫持：通过 iframe 覆盖诱导点击
敏感信息泄露：密钥、token 写在前端
供应链攻击：恶意 npm 包
不安全依赖与过期库

需要避免的典型误区：

认为安全只是后端的事
只做输入校验不做输出转义
把密钥写死在代码里

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：XSS、CSRF 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

认为安全只是后端的事
只做输入校验不做输出转义
把密钥写死在代码里

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

XSS；CSRF；点击劫持；敏感信息泄露；供应链攻击；不安全依赖与过期库。同时要避免认为安全只是后端的事。

FB-31-CO-A-009：XSS 的类型与防护措施

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：XSS、反射型、存储型、DOM 型、CSP 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 XSS 的分类及前端如何防御。

参考答案：

核心思路如下：

反射型：恶意参数在 URL 中，服务端返回后执行
存储型：恶意脚本存入数据库，持久化危害
DOM 型：前端 JS 不当下DOM 操作引入
防御：输入校验、输出转义、CSP、HttpOnly Cookie
避免 v-html/innerHTML 处理不可信内容
使用现代框架默认转义

需要避免的典型误区：

只依赖输入过滤
允许用户输入直接 innerHTML
CSP 配置过宽

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：反射型、存储型等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只依赖输入过滤
允许用户输入直接 innerHTML
CSP 配置过宽

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

反射型；存储型；DOM 型；防御；避免 v-html/innerHTML 处理不可信内容；使用现代框架默认转义。同时要避免只依赖输入过滤。

FB-31-CO-A-010：CSRF 的原理与防御

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：CSRF、Token、SameSite、Cookie、防御 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请解释 CSRF 攻击原理及前端配合防御的方法。

参考答案：

核心思路如下：

原理：攻击者诱导已登录用户访问恶意站点发起请求
防御：SameSite Cookie、CSRF Token、Referer 校验
SameSite=Strict/Lax 限制第三方 Cookie 携带
敏感操作加二次验证
前端避免 GET 请求做写操作

需要避免的典型误区：

只靠前端校验
Cookie 不设置 SameSite
CSRF Token 存在 Cookie 中

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：原理、防御等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只靠前端校验
Cookie 不设置 SameSite
CSRF Token 存在 Cookie 中

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

原理；防御；SameSite=Strict/Lax 限制第三方 Cookie 携带；敏感操作加二次验证；前端避免 GET 请求做写操作。同时要避免只靠前端校验。

FB-31-SE-P-004：内容安全策略 CSP 如何配置

题型：安全题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：CSP、XSS、策略、指令、报告 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 CSP 的作用、常用指令及部署建议。

参考答案：

核心思路如下：

CSP 限制页面可加载的资源来源，减少 XSS 危害
default-src、script-src、style-src、img-src、connect-src
避免 unsafe-inline 和 unsafe-eval
report-uri/report-to 收集违规报告
先 report-only 模式验证，再 enforcing

需要避免的典型误区：

CSP 过宽等于没配
直接 enforcing 导致功能大面积异常
unsafe-inline 滥用

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：CSP 限制页面可加载的资源来源，减少 XSS 危害、default-src、script-src、style-src、img-src、connect-src 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

CSP 过宽等于没配
直接 enforcing 导致功能大面积异常
unsafe-inline 滥用

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

CSP 限制页面可加载的资源来源，减少 XSS 危害；default-src、script-src、style-src、img-src、connect-src；避免 unsafe-inline 和 unsafe-eval；report-uri/report-to 收集违规报告；先 report-only 模式验证，再 enforcing。同时要避免CSP 过宽等于没配。

FB-31-SE-A-003：前端如何安全存储 Token

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：Token、localStorage、Cookie、HttpOnly、安全 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请比较 Token 存储方式的安全性。

参考答案：

核心思路如下：

HttpOnly Cookie：防 XSS 读取，但需防 CSRF
localStorage：易受 XSS 窃取，但天然防 CSRF
sessionStorage：标签页级，关闭即清
Access Token 短有效期，Refresh Token 用 HttpOnly
敏感操作加绑定设备/IP/指纹验证

需要避免的典型误区：

所有 Token 放 localStorage
Token 长期不过期
Refresh Token 也暴露给 JS

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：HttpOnly Cookie、localStorage 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有 Token 放 localStorage
Token 长期不过期
Refresh Token 也暴露给 JS

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

HttpOnly Cookie；localStorage；sessionStorage；Access Token 短有效期，Refresh Token 用 HttpOnly；敏感操作加绑定设备/IP/指纹验证。同时要避免所有 Token 放 localStorage。

FB-31-SE-P-005：前端供应链安全治理

题型：安全题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：供应链、npm、审计、SBOM、依赖 出现频率：高频 预计回答时长：8-15 分钟

题目描述：请说明前端如何防范供应链攻击。

参考答案：

核心思路如下：

依赖审计：npm audit、Snyk、Trivy
锁定版本：lockfile、私有仓库
最小权限：只安装必要依赖
SBOM：记录依赖清单
代码审查：关注新引入依赖和权限请求
运行时隔离：iframe、CSP、Subresource Integrity

需要避免的典型误区：

盲目升级最新版本
不检查依赖源码
npm install 任意包

补充说明：

在实际落地前端供应链安全治理时，建议结合供应链、npm、审计的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：依赖审计、锁定版本等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

盲目升级最新版本
不检查依赖源码
npm install 任意包

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

依赖审计；锁定版本；最小权限；SBOM；代码审查；运行时隔离。同时要避免盲目升级最新版本。

FB-31-SE-R-001：设计一个企业级前端安全体系

题型：安全题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：31 安全架构标签：安全体系、XSS、CSRF、CSP、SDL、治理 出现频率：中频 预计回答时长：15-30 分钟

题目描述：请为公司前端设计覆盖开发、发布、运行的安全体系。

参考答案：

核心思路如下：

SDL：需求、设计、编码、测试、发布各阶段安全活动
开发：安全编码规范、依赖审计、密钥管理
测试：SAST、DAST、渗透测试
发布：构建签名、Source Map 保护、HTTPS
运行：CSP、WAF、错误监控、漏洞响应
组织：安全培训、应急响应、复盘

需要避免的典型误区：

只在上线前做一次安全检查
安全与业务对立
无应急响应流程

补充说明：

在实际落地设计一个企业级前端安全体系时，建议结合安全体系、XSS、CSRF 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：SDL、开发等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只在上线前做一次安全检查
安全与业务对立
无应急响应流程

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

SDL；开发；测试；发布；运行；组织。同时要避免只在上线前做一次安全检查。

FB-31-CO-A-011：什么是点击劫持及防御

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：点击劫持、X-Frame-Options、CSP、iframe 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释点击劫持攻击和前端防御方法。

参考答案：

核心思路如下：

攻击：恶意页面用 iframe 覆盖目标页面诱导点击
防御：X-Frame-Options: DENY/SAMEORIGIN
CSP frame-ancestors 控制嵌入来源
敏感操作加二次确认
UI 设计：关键按钮位置变化

需要避免的典型误区：

允许任意网站 iframe 嵌入
只依赖 JS 判断顶层窗口
忽略 X-Frame-Options

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：攻击、防御等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

允许任意网站 iframe 嵌入
只依赖 JS 判断顶层窗口
忽略 X-Frame-Options

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

攻击；防御；CSP frame-ancestors 控制嵌入来源；敏感操作加二次确认；UI 设计。同时要避免允许任意网站 iframe 嵌入。

FB-31-SE-P-006：前端如何处理富文本安全

题型：安全题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：富文本、XSS、DOMPurify、HTML、白名单 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计一个安全的富文本渲染方案。

参考答案：

核心思路如下：

不信任用户提交的 HTML
使用 DOMPurify 等库按白名单过滤标签和属性
禁止 script、onerror、javascript: 等危险内容
后端再次清洗，前端只做兜底
渲染时使用 v-pre 或转义非富文本部分

需要避免的典型误区：

直接 innerHTML 用户输入
白名单过宽
只在前端过滤

补充说明：

在实际落地前端如何处理富文本安全时，建议结合富文本、XSS、DOMPurify 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：不信任用户提交的 HTML、使用 DOMPurify 等库按白名单过滤标签和属性等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

直接 innerHTML 用户输入
白名单过宽
只在前端过滤

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

不信任用户提交的 HTML；使用 DOMPurify 等库按白名单过滤标签和属性；禁止 script、onerror、javascript；后端再次清洗，前端只做兜底；渲染时使用 v-pre 或转义非富文本部分。同时要避免直接 innerHTML 用户输入。

FB-31-SE-A-004：HTTPS 在前端安全中的作用

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：HTTPS、TLS、中间人、加密、HSTS 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明 HTTPS 的必要性及前端相关配置。

参考答案：

核心思路如下：

HTTPS 防止中间人窃听和篡改
前端资源全部使用 HTTPS，避免混合内容
HSTS 强制浏览器使用 HTTPS
证书固定和 OCSP Stapling
敏感接口拒绝 HTTP

需要避免的典型误区：

主站 HTTPS 但资源 HTTP
忽略 HSTS
证书过期未监控

补充说明：

在实际落地 HTTPS 在前端安全中的作用时，建议结合 HTTPS、TLS、中间人的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：HTTPS 防止中间人窃听和篡改、前端资源全部使用 HTTPS，避免混合内容等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

主站 HTTPS 但资源 HTTP
忽略 HSTS
证书过期未监控

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

HTTPS 防止中间人窃听和篡改；前端资源全部使用 HTTPS，避免混合内容；HSTS 强制浏览器使用 HTTPS；证书固定和 OCSP Stapling；敏感接口拒绝 HTTP。同时要避免主站 HTTPS 但资源 HTTP。

FB-31-CO-A-012：什么是 Subresource Integrity

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：SRI、哈希、CDN、篡改、完整性 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释 SRI 的作用和用法。

参考答案：

核心思路如下：

SRI 让浏览器验证加载的脚本/样式是否被篡改
通过 integrity 属性提供哈希值
与 CDN 结合防止供应链投毒
哈希算法推荐 sha384
失败时浏览器不执行资源

需要避免的典型误区：

不使用 SRI 加载第三方脚本
integrity 值与文件不匹配
版本更新后未更新 integrity

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：SRI 让浏览器验证加载的脚本/样式是否被篡改、通过 integrity 属性提供哈希值等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

不使用 SRI 加载第三方脚本
integrity 值与文件不匹配
版本更新后未更新 integrity

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

SRI 让浏览器验证加载的脚本/样式是否被篡改；通过 integrity 属性提供哈希值；与 CDN 结合防止供应链投毒；哈希算法推荐 sha384；失败时浏览器不执行资源。同时要避免不使用 SRI 加载第三方脚本。

FB-31-SE-P-007：前端如何防止敏感信息泄露

题型：安全题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：敏感信息、密钥、环境变量、源码、泄露 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明前端项目中如何管理敏感信息。

参考答案：

核心思路如下：

不在前端代码中硬编码密钥、密码
构建时通过环境变量注入的非敏感配置
API 密钥放在服务端或 BFF
使用 git hooks 扫描提交中的密钥
Source Map 不上传公网

需要避免的典型误区：

把私钥放 .env 再打包
在 GitHub 公开仓库提交密钥
认为压缩后代码不可读

补充说明：

在实际落地前端如何防止敏感信息泄露时，建议结合敏感信息、密钥、环境变量的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：不在前端代码中硬编码密钥、密码、构建时通过环境变量注入的非敏感配置等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

把私钥放 .env 再打包
在 GitHub 公开仓库提交密钥
认为压缩后代码不可读

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

不在前端代码中硬编码密钥、密码；构建时通过环境变量注入的非敏感配置；API 密钥放在服务端或 BFF；使用 git hooks 扫描提交中的密钥；Source Map 不上传公网。同时要避免把私钥放 .env 再打包。

FB-31-SE-A-005：前端如何处理文件上传安全

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：文件上传、XSS、类型校验、大小限制、沙箱 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明前端文件上传的安全注意事项。

参考答案：

核心思路如下：

校验文件类型：白名单 MIME 和扩展名
限制文件大小，防止拒绝服务
图片文件做服务端重新编码防图片木马
下载文件使用 Content-Disposition
上传路径不可执行

需要避免的典型误区：

只依赖前端校验
允许上传任意可执行文件
文件名直接使用

补充说明：

在实际落地前端如何处理文件上传安全时，建议结合文件上传、XSS、类型校验的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：校验文件类型、限制文件大小，防止拒绝服务等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只依赖前端校验
允许上传任意可执行文件
文件名直接使用

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

校验文件类型；限制文件大小，防止拒绝服务；图片文件做服务端重新编码防图片木马；下载文件使用 Content-Disposition；上传路径不可执行。同时要避免只依赖前端校验。

FB-31-CO-P-004：CORS 与前端安全的关系

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：CORS、同源、安全、跨域、预检 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 CORS 机制及前端如何安全地进行跨域请求。

参考答案：

核心思路如下：

CORS 是浏览器的安全机制，服务端通过头控制
简单请求与预检请求区别
前端不能绕过 CORS，需服务端正确配置
敏感接口限制 Origin 和 Credentials
避免通配符 * 配合 credentials

需要避免的典型误区：

前端用代理绕过 CORS 当解决方案
服务端允许任意 Origin
Credentials 与 * 混用

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：CORS 是浏览器的安全机制，服务端通过头控制、简单请求与预检请求区别等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

前端用代理绕过 CORS 当解决方案
服务端允许任意 Origin
Credentials 与 * 混用

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

CORS 是浏览器的安全机制，服务端通过头控制；简单请求与预检请求区别；前端不能绕过 CORS，需服务端正确配置；敏感接口限制 Origin 和 Credentials；避免通配符 * 配合 credentials。同时要避免前端用代理绕过 CORS 当解决方案。

FB-31-SE-P-008：前端如何防御 DOM Clobbering

题型：安全题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：DOM Clobbering、XSS、HTML、id、安全 出现频率：低频 预计回答时长：5-8 分钟

题目描述：请解释 DOM Clobbering 攻击原理及防御。

参考答案：

核心思路如下：

攻击：HTML 元素 id/name 与 JS 变量冲突，覆盖对象
防御：避免通过全局变量读取 DOM 元素
使用 const/let 声明，减少全局污染
不可信内容先 DOMPurify 过滤
避免依赖全局命名空间

需要避免的典型误区：

不知道 DOM Clobbering
用 var 声明全局变量
直接访问 id 名变量

补充说明：

在实际落地前端如何防御 DOM Clobbering 时，建议结合 DOM Clobbering、XSS、HTML 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：攻击、防御等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

不知道 DOM Clobbering
用 var 声明全局变量
直接访问 id 名变量

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

攻击；防御；使用 const/let 声明，减少全局污染；不可信内容先 DOMPurify 过滤；避免依赖全局命名空间。同时要避免不知道 DOM Clobbering。

FB-31-SE-A-006：如何安全使用第三方脚本

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：第三方脚本、XSS、SRI、CSP、沙箱 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明引入第三方 SDK/脚本时的安全措施。

参考答案：

核心思路如下：

评估第三方来源和权限
使用 SRI 校验完整性
CSP 限制脚本来源
延迟加载非关键脚本
定期审计第三方脚本变更
使用 iframe 或 Worker 隔离高敏感脚本

需要避免的典型误区：

任意引入第三方脚本
第三方脚本拥有全局权限
不监控第三方更新

补充说明：

在实际落地安全使用第三方脚本时，建议结合第三方脚本、XSS、SRI 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：评估第三方来源和权限、使用 SRI 校验完整性等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

任意引入第三方脚本
第三方脚本拥有全局权限
不监控第三方更新

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

评估第三方来源和权限；使用 SRI 校验完整性；CSP 限制脚本来源；延迟加载非关键脚本；定期审计第三方脚本变更；使用 iframe 或 Worker 隔离高敏感脚本。同时要避免任意引入第三方脚本。

FB-31-CO-A-013：什么是开放重定向漏洞

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：开放重定向、URL、钓鱼、校验 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释开放重定向漏洞及前端如何防范。

参考答案：

核心思路如下：

漏洞：攻击者构造跳转 URL 诱导用户到恶意站点
前端跳转目标必须是白名单
不要直接取 URL 参数作为跳转地址
服务端也做白名单校验
登录后跳转固定路径

需要避免的典型误区：

直接 location.href = urlParams.next
只在前端校验
使用黑名单

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：漏洞、前端跳转目标必须是白名单等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

直接 location.href = urlParams.next
只在前端校验
使用黑名单

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

漏洞；前端跳转目标必须是白名单；不要直接取 URL 参数作为跳转地址；服务端也做白名单校验；登录后跳转固定路径。同时要避免直接 location.href = urlParams.next。

FB-31-SE-P-009：前端如何做权限校验才安全

题型：安全题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：权限、前端校验、后端校验、RBAC、绕过 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明前端权限校验的定位与边界。

参考答案：

核心思路如下：

前端权限用于体验控制，不能替代后端鉴权
敏感操作和数据必须服务端校验
权限数据应由服务端下发，前端缓存只读
防止前端代码被绕过修改权限判断
权限变更时实时刷新

需要避免的典型误区：

所有权限判断写死在前端
前端隐藏按钮就认为安全
不信任服务端返回数据

补充说明：

在实际落地前端如何做权限校验才安全时，建议结合权限、前端校验、后端校验的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：前端权限用于体验控制，不能替代后端鉴权、敏感操作和数据必须服务端校验等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有权限判断写死在前端
前端隐藏按钮就认为安全
不信任服务端返回数据

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

前端权限用于体验控制，不能替代后端鉴权；敏感操作和数据必须服务端校验；权限数据应由服务端下发，前端缓存只读；防止前端代码被绕过修改权限判断；权限变更时实时刷新。同时要避免所有权限判断写死在前端。

FB-31-SE-R-002：设计前端安全开发生命周期

题型：安全题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：31 安全架构标签：SDL、安全、开发、测试、发布 出现频率：中频 预计回答时长：8-15 分钟

题目描述：请设计前端 SDL，覆盖需求到运营的完整流程。

参考答案：

核心思路如下：

需求：识别安全风险和合规要求
设计：威胁建模、数据流图、信任边界
编码：安全规范、依赖审计、代码评审
测试：SAST、DAST、渗透、模糊测试
发布：签名、回滚、监控
运营：漏洞响应、日志审计、复盘

需要避免的典型误区：

安全只在测试阶段做
无威胁建模
漏洞修复无 SLA

补充说明：

在实际落地设计前端安全开发生命周期时，建议结合 SDL、安全、开发的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：需求、设计等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

安全只在测试阶段做
无威胁建模
漏洞修复无 SLA

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

需求；设计；编码；测试；发布；运营。同时要避免安全只在测试阶段做。

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：Cookie、SameSite、CSRF、安全 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明 SameSite 的三个取值及作用。

参考答案：

核心思路如下：

Strict：完全禁止第三方 Cookie，最安全但影响部分体验
Lax：允许 top-level 导航 GET 请求携带，平衡安全与体验
None：允许第三方，但必须配合 Secure
有效防止 CSRF
现代浏览器默认 Lax

需要避免的典型误区：

SameSite=None 未设置 Secure
Strict 导致正常跳转丢失登录态
不设置 SameSite

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：Strict、Lax 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

SameSite=None 未设置 Secure
Strict 导致正常跳转丢失登录态
不设置 SameSite

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

Strict；Lax；None；有效防止 CSRF；现代浏览器默认 Lax。同时要避免SameSite=None 未设置 Secure。

FB-31-SE-A-007：前端如何防止原型链污染

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：原型链污染、Object.assign、JSON、安全 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释原型链污染漏洞及前端防御。

参考答案：

核心思路如下：

漏洞：通过修改 Object.prototype 影响所有对象
来源：合并不可信对象、递归赋值
防御：使用 Object.create(null)、Map/Set
避免递归合并用户输入到对象
使用结构化克隆或 schema 校验

需要避免的典型误区：

直接 Object.assign 用户输入
深拷贝函数未过滤 proto
不信任 JSON.parse 结果

补充说明：

在实际落地前端如何防止原型链污染时，建议结合原型链污染、Object.assign、JSON 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：漏洞、来源等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

直接 Object.assign 用户输入
深拷贝函数未过滤 proto
不信任 JSON.parse 结果

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

漏洞；来源；防御；避免递归合并用户输入到对象；使用结构化克隆或 schema 校验。同时要避免直接 Object.assign 用户输入。

FB-31-SE-P-010：Web Storage 安全使用指南

题型：安全题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：localStorage、sessionStorage、安全、XSS、敏感数据 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 Web Storage 的安全风险和使用建议。

参考答案：

核心思路如下：

localStorage 可被 XSS 读取，不放敏感数据
sessionStorage 标签页级，适合临时状态
避免存储密码、token、PII
对存储数据做序列化和校验
清理策略：登出清除

需要避免的典型误区：

localStorage 存 JWT
不清理过期数据
存储数据不经校验直接使用

补充说明：

在实际落地 Web Storage 安全使用指南时，建议结合 localStorage、sessionStorage、安全的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：localStorage 可被 XSS 读取，不放敏感数据、sessionStorage 标签页级，适合临时状态等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

localStorage 存 JWT
不清理过期数据
存储数据不经校验直接使用

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

localStorage 可被 XSS 读取，不放敏感数据；sessionStorage 标签页级，适合临时状态；避免存储密码、token、PII；对存储数据做序列化和校验；清理策略。同时要避免localStorage 存 JWT。

FB-31-CO-A-014：什么是内容嗅探与 MIME 嗅探防御

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：MIME、内容嗅探、X-Content-Type-Options、安全 出现频率：低频 预计回答时长：3-5 分钟

题目描述：请解释 MIME 嗅探攻击及防御。

参考答案：

核心思路如下：

浏览器可能忽略 Content-Type 自行判断文件类型
攻击者上传伪装文件执行脚本
防御：X-Content-Type-Options: nosniff
正确设置 Content-Type
不允许用户上传可执行内容

需要避免的典型误区：

未设置 nosniff
允许上传 .html 等可执行文件
依赖文件扩展名判断

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：浏览器可能忽略 Content-Type 自行判断文件类型、攻击者上传伪装文件执行脚本等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

未设置 nosniff
允许上传 .html 等可执行文件
依赖文件扩展名判断

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

浏览器可能忽略 Content-Type 自行判断文件类型；攻击者上传伪装文件执行脚本；防御；正确设置 Content-Type；不允许用户上传可执行内容。同时要避免未设置 nosniff。

FB-31-SE-A-008：前端如何处理 URL 参数安全

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：URL、参数、XSS、开放重定向、校验 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明前端使用 URL 参数时的安全注意事项。

参考答案：

核心思路如下：

不要直接将 URL 参数渲染到页面，需转义
跳转目标校验白名单
参数做类型和长度校验
避免把敏感信息放在 URL
分享链接注意信息泄露

需要避免的典型误区：

document.write(location.search)
URL 参数直接作为跳转地址
URL 中暴露 token

补充说明：

在实际落地前端如何处理 URL 参数安全时，建议结合 URL、参数、XSS 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：不要直接将 URL 参数渲染到页面，需转义、跳转目标校验白名单等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

document.write(location.search)
URL 参数直接作为跳转地址
URL 中暴露 token

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

不要直接将 URL 参数渲染到页面，需转义；跳转目标校验白名单；参数做类型和长度校验；避免把敏感信息放在 URL；分享链接注意信息泄露。同时要避免document.write(location.search)。

FB-31-SE-P-011：如何防御 JSONP 相关安全风险

题型：安全题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：JSONP、XSS、CSP、Callback、安全 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 JSONP 的安全问题及现代替代方案。

参考答案：

核心思路如下：

JSONP 允许任意回调执行，存在 XSS 和数据泄露
回调函数名可能被污染
替代：CORS + fetch
如果必须使用，校验回调名白名单、CSP 限制
避免传输敏感数据

需要避免的典型误区：

无限制使用 JSONP
回调名来自用户输入
把 JSONP 当跨域万能方案

补充说明：

在实际落地防御 JSONP 相关安全风险时，建议结合 JSONP、XSS、CSP 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：JSONP 允许任意回调执行，存在 XSS 和数据泄露、回调函数名可能被污染等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

无限制使用 JSONP
回调名来自用户输入
把 JSONP 当跨域万能方案

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

JSONP 允许任意回调执行，存在 XSS 和数据泄露；回调函数名可能被污染；替代；如果必须使用，校验回调名白名单、CSP 限制；避免传输敏感数据。同时要避免无限制使用 JSONP。

FB-31-CO-R-001：前端零信任安全架构实践

题型：概念题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：31 安全架构标签：零信任、前端、身份、验证、最小权限 出现频率：低频 预计回答时长：8-15 分钟

题目描述：请说明零信任理念如何应用到前端架构。

参考答案：

核心思路如下：

永不信任，始终验证
前端默认不可信，后端做最终鉴权
最小权限：只暴露必要接口和数据
持续验证：行为异常检测、设备指纹
微分段：按业务域隔离权限
假设前端代码可被逆向，不存放机密

需要避免的典型误区：

前端做最终安全决策
内网应用默认信任
过度依赖前端混淆

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：永不信任，始终验证、前端默认不可信，后端做最终鉴权等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

前端做最终安全决策
内网应用默认信任
过度依赖前端混淆

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

永不信任，始终验证；前端默认不可信，后端做最终鉴权；最小权限；持续验证；微分段；假设前端代码可被逆向，不存放机密。同时要避免前端做最终安全决策。

FB-31-SE-A-009：前端如何应对供应链投毒事件

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：供应链、投毒、npm、响应、回滚 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明发现依赖包被投毒后的应急响应。

参考答案：

核心思路如下：

立即锁定或移除恶意依赖版本
回滚到上一安全版本并发布
审计受影响代码和构建产物
检查是否有密钥泄露或异常网络请求
建立依赖白名单和审批流程
事后复盘更新 SCA 策略

需要避免的典型误区：

继续等待官方修复
不检查已发布产物
无依赖审批流程

补充说明：

在实际落地前端如何应对供应链投毒事件时，建议结合供应链、投毒、npm 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：立即锁定或移除恶意依赖版本、回滚到上一安全版本并发布等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

继续等待官方修复
不检查已发布产物
无依赖审批流程

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

立即锁定或移除恶意依赖版本；回滚到上一安全版本并发布；审计受影响代码和构建产物；检查是否有密钥泄露或异常网络请求；建立依赖白名单和审批流程；事后复盘更新 SCA 策略。同时要避免继续等待官方修复。

FB-31-CO-P-005：什么是安全标头及其前端价值

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：安全标头、HSTS、CSP、X-Frame、XSS-Protection 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请列举常见的 HTTP 安全响应头及作用。

参考答案：

核心思路如下：

HSTS：强制 HTTPS
CSP：限制资源加载和脚本执行
X-Frame-Options / CSP frame-ancestors：防止点击劫持
X-Content-Type-Options: nosniff
Referrer-Policy：控制 referrer 泄露
Permissions-Policy：限制浏览器 API

需要避免的典型误区：

安全头配置错误导致功能异常
只配部分头
认为前端无法影响响应头

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：HSTS、CSP 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

安全头配置错误导致功能异常
只配部分头
认为前端无法影响响应头

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

HSTS；CSP；X-Frame-Options / CSP frame-ancestors；X-Content-Type-Options；Referrer-Policy；Permissions-Policy。同时要避免安全头配置错误导致功能异常。

FB-31-SE-A-010：前端日志中的隐私合规

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：隐私、GDPR、个人信息、日志、脱敏 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明前端日志采集如何避免隐私合规风险。

参考答案：

核心思路如下：

不上传姓名、手机号、身份证、地址等 PII
用户 ID 做哈希或假名化
地理位置等敏感信息需授权和最小化
遵守 GDPR、CCPA、个保法等法规
提供用户删除和导出数据的机制

需要避免的典型误区：

日志明文记录用户输入
采集所有用户行为无告知
数据保留期限过长

补充说明：

在实际落地前端日志中的隐私合规时，建议结合隐私、GDPR、个人信息的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：不上传姓名、手机号、身份证、地址等 PII、用户 ID 做哈希或假名化等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

日志明文记录用户输入
采集所有用户行为无告知
数据保留期限过长

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

不上传姓名、手机号、身份证、地址等 PII；用户 ID 做哈希或假名化；地理位置等敏感信息需授权和最小化；遵守 GDPR、CCPA、个保法等法规；提供用户删除和导出数据的机制。同时要避免日志明文记录用户输入。

FB-31-CO-B-014：HTTPS 与混合内容安全

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：31 安全架构标签：HTTPS、混合内容、安全、资源 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释什么是混合内容及其风险。

参考答案：

核心思路如下：

HTTPS 页面加载 HTTP 资源称为混合内容
被动混合内容：图片/视频，风险较低
主动混合内容：脚本/样式，可被中间人篡改
现代浏览器会阻止主动混合内容
前端应确保所有资源 HTTPS

需要避免的典型误区：

主站 HTTPS 但资源 HTTP
忽略 passive mixed content
不监控资源协议

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：HTTPS 页面加载 HTTP 资源称为混合内容、被动混合内容等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

主站 HTTPS 但资源 HTTP
忽略 passive mixed content
不监控资源协议

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

HTTPS 页面加载 HTTP 资源称为混合内容；被动混合内容；主动混合内容；现代浏览器会阻止主动混合内容；前端应确保所有资源 HTTPS。同时要避免主站 HTTPS 但资源 HTTP。

FB-31-SE-A-011：前端密钥管理

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：密钥、安全、环境变量、构建、泄露 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明前端如何管理 API 密钥等敏感配置。

参考答案：

核心思路如下：

敏感密钥不应写在前端代码
通过 BFF 代理需要密钥的请求
使用短有效期 token
构建时注入非敏感配置
扫描提交防止密钥泄露

需要避免的典型误区：

API key 硬编码
把私钥放 .env 打包
密钥长期不过期

补充说明：

在实际落地前端密钥管理时，建议结合密钥、安全、环境变量的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：敏感密钥不应写在前端代码、通过 BFF 代理需要密钥的请求等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

API key 硬编码
把私钥放 .env 打包
密钥长期不过期

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

敏感密钥不应写在前端代码；通过 BFF 代理需要密钥的请求；使用短有效期 token；构建时注入非敏感配置；扫描提交防止密钥泄露。同时要避免API key 硬编码。

FB-31-CO-A-015：XSS 与 CSP 的关系

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：XSS、CSP、内容安全策略、防御 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明 CSP 在 XSS 防御中的作用。

参考答案：

核心思路如下：

CSP 限制页面可执行脚本的来源
即使存在 XSS 注入，CSP 可阻止执行
default-src、script-src 是关键指令
report-only 模式先观察
CSP 是纵深防御，不是唯一手段

需要避免的典型误区：

CSP 配置 unsafe-inline
认为 CSP 可替代输入校验
不监控违规报告

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：CSP 限制页面可执行脚本的来源、即使存在 XSS 注入，CSP 可阻止执行等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

CSP 配置 unsafe-inline
认为 CSP 可替代输入校验
不监控违规报告

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

CSP 限制页面可执行脚本的来源；即使存在 XSS 注入，CSP 可阻止执行；default-src、script-src 是关键指令；report-only 模式先观察；CSP 是纵深防御，不是唯一手段。同时要避免CSP 配置 unsafe-inline。

FB-31-SE-A-012：CSP report-only 模式的价值

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：CSP、report-only、安全、部署 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释为什么 CSP 要先 report-only。

参考答案：

核心思路如下：

避免直接 enforcing 导致功能异常
收集违规报告，发现内联脚本等
逐步修复后再启用 enforcing
降低上线风险
可监控第三方脚本违规

需要避免的典型误区：

直接 enforcing
report-only 阶段不处理报告
忽略 report-uri 配置

补充说明：

在实际落地 CSP report-only 模式的价值时，建议结合 CSP、report-only、安全的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：避免直接 enforcing 导致功能异常、收集违规报告，发现内联脚本等等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

直接 enforcing
report-only 阶段不处理报告
忽略 report-uri 配置

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

避免直接 enforcing 导致功能异常；收集违规报告，发现内联脚本等；逐步修复后再启用 enforcing；降低上线风险；可监控第三方脚本违规。同时要避免直接 enforcing。

FB-31-SC-A-001：前端上传文件安全

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：31 安全架构标签：文件上传、安全、类型、病毒、沙箱 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明前端文件上传的安全注意事项。

参考答案：

核心思路如下：

校验扩展名和 MIME 类型白名单
限制文件大小
图片做服务端重新编码
避免直接展示用户上传文件
敏感文件类型禁止上传

需要避免的典型误区：

只依赖前端校验
允许上传可执行文件
文件名直接用于存储

补充说明：

在实际落地前端上传文件安全时，建议结合文件上传、安全、类型的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：校验扩展名和 MIME 类型白名单、限制文件大小等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只依赖前端校验
允许上传可执行文件
文件名直接用于存储

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

校验扩展名和 MIME 类型白名单；限制文件大小；图片做服务端重新编码；避免直接展示用户上传文件；敏感文件类型禁止上传。同时要避免只依赖前端校验。

FB-31-CO-P-006：HSTS 与前端安全

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：31 安全架构标签：HSTS、HTTPS、安全、预加载 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 HSTS 的作用和配置注意事项。

参考答案：

核心思路如下：

HSTS 强制浏览器使用 HTTPS
max-age 设置有效期
includeSubDomains 保护子域
preload 加入浏览器预加载列表
首次访问仍需 301 跳转

需要避免的典型误区：

max-age 过短
子域未 include
未启用 HTTPS 就加 preload

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：HSTS 强制浏览器使用 HTTPS、max-age 设置有效期等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

max-age 过短
子域未 include
未启用 HTTPS 就加 preload

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

HSTS 强制浏览器使用 HTTPS；max-age 设置有效期；includeSubDomains 保护子域；preload 加入浏览器预加载列表；首次访问仍需 301 跳转。同时要避免max-age 过短。

安全架构面试题 ​

目录 ​

基础题（8 道） ​

FB-31-CO-B-001：XSS 有哪几种类型？前端分别如何防御？ ​

FB-31-CO-B-002：CSRF 的攻击原理是什么？前端如何配合防御？ ​

FB-31-CO-B-003：CSP 的作用是什么？如何在前端项目中落地？ ​

FB-31-CO-B-004：HTTPS/TLS 在前端安全中起到什么作用？ ​

FB-31-CO-B-005：前端敏感数据存储有哪些风险？localStorage、sessionStorage、Cookie 该如何选择？ ​

FB-31-CO-B-006：CORS 预检请求的作用是什么？前端如何正确配置？ ​

FB-31-CO-B-007：什么是点击劫持？前端有哪些防御手段？ ​

FB-31-CO-B-008：为什么输入校验不能替代输出编码？ ​

进阶题（8 道） ​

FB-31-CO-A-001：OAuth 2.0 授权码流程中，前端扮演什么角色？ ​

FB-31-CO-A-002：JWT 在前端有哪些安全使用方式与常见风险？ ​

FB-31-CO-A-003：第三方脚本（埋点、客服、广告）有哪些安全风险？如何隔离？ ​

FB-31-CO-A-004：前端供应链安全如何保障？ ​

FB-31-CO-A-005：CSP nonce 与 hash 有什么区别？如何选择？ ​

FB-31-CO-A-006：会话管理应该注意哪些安全点？ ​

FB-31-SE-A-001：前端加密与后端加密有什么区别？前端加密能否替代 HTTPS？ ​

FB-31-CO-A-007：安全漏洞修复的标准流程是什么？ ​

深入题（7 道） ​

FB-31-CO-P-001：什么是安全左移（Shift Left Security）？前端如何落地？ ​

FB-31-CO-P-002：前端密钥管理有哪些方案？各自的适用场景是什么？ ​

FB-31-SE-P-001：前端零信任架构的核心原则是什么？ ​

FB-31-SE-P-002：CSP 有哪些常见绕过方式？如何构建深度防御？ ​

FB-31-CD-P-001：如何设计一个前端安全 SDK？ ​

FB-31-CO-P-003：隐私合规（GDPR/个人信息保护法）对前端有哪些技术要求？ ​

FB-31-SE-P-003：什么是前端运行时应用自保护（RASP）？ ​

架构题（50 道） ​

FB-31-SD-R-001：如何为大型企业设计前端安全架构？ ​

FB-31-CP-R-002：如何构建组织级前端安全能力平台？ ​

FB-31-CP-R-003：安全事件应急响应流程应该如何设计？ ​

FB-31-CP-R-004：安全架构评审清单与 ADR 应该怎么写？ ​

FB-31-SD-R-002：微前端场景下如何做好安全隔离？ ​

FB-31-SD-R-003：前后端安全边界应该如何划分？ ​

FB-31-SS-R-001：如何推动团队提升安全意识？ ​

FB-31-CO-B-009：什么是威胁建模？前端为什么需要威胁建模？ ​

FB-31-CO-B-010：解释 STRIDE 模型。 ​

FB-31-CO-B-011：CSP 能解决什么问题？给出一个基本配置示例。 ​

FB-31-SE-B-001：什么是供应链安全？前端如何防护？ ​

FB-31-SE-B-002：前端如何处理用户身份认证安全？ ​

二、进阶题 ​

FB-31-SE-A-002：什么是安全左移？前端如何实践？ ​

FB-31-SD-A-001：如何设计一个隐私合规的前端应用？ ​

FB-31-CO-A-008：第三方脚本有哪些风险？如何治理？ ​

三、高级题 ​

FB-31-CO-B-012：前端常见安全威胁有哪些 ​

FB-31-CO-A-009：XSS 的类型与防护措施 ​

FB-31-CO-A-010：CSRF 的原理与防御 ​

FB-31-SE-P-004：内容安全策略 CSP 如何配置 ​

FB-31-SE-A-003：前端如何安全存储 Token ​

FB-31-SE-P-005：前端供应链安全治理 ​

FB-31-SE-R-001：设计一个企业级前端安全体系 ​

FB-31-CO-A-011：什么是点击劫持及防御 ​

FB-31-SE-P-006：前端如何处理富文本安全 ​

FB-31-SE-A-004：HTTPS 在前端安全中的作用 ​

FB-31-CO-A-012：什么是 Subresource Integrity ​

FB-31-SE-P-007：前端如何防止敏感信息泄露 ​

FB-31-SE-A-005：前端如何处理文件上传安全 ​

FB-31-CO-P-004：CORS 与前端安全的关系 ​

FB-31-SE-P-008：前端如何防御 DOM Clobbering ​

FB-31-SE-A-006：如何安全使用第三方脚本 ​

FB-31-CO-A-013：什么是开放重定向漏洞 ​

FB-31-SE-P-009：前端如何做权限校验才安全 ​

FB-31-SE-R-002：设计前端安全开发生命周期 ​

FB-31-CO-B-013：Cookie 的 SameSite 属性 ​

FB-31-SE-A-007：前端如何防止原型链污染 ​

FB-31-SE-P-010：Web Storage 安全使用指南 ​

FB-31-CO-A-014：什么是内容嗅探与 MIME 嗅探防御 ​

FB-31-SE-A-008：前端如何处理 URL 参数安全 ​

FB-31-SE-P-011：如何防御 JSONP 相关安全风险 ​

FB-31-CO-R-001：前端零信任安全架构实践 ​

FB-31-SE-A-009：前端如何应对供应链投毒事件 ​

FB-31-CO-P-005：什么是安全标头及其前端价值 ​

FB-31-SE-A-010：前端日志中的隐私合规 ​

FB-31-CO-B-014：HTTPS 与混合内容安全 ​

FB-31-SE-A-011：前端密钥管理 ​

FB-31-CO-A-015：XSS 与 CSP 的关系 ​

FB-31-SE-A-012：CSP report-only 模式的价值 ​

FB-31-SC-A-001：前端上传文件安全 ​

安全架构面试题

目录

基础题（8 道）

FB-31-CO-B-001：XSS 有哪几种类型？前端分别如何防御？

FB-31-CO-B-002：CSRF 的攻击原理是什么？前端如何配合防御？

FB-31-CO-B-003：CSP 的作用是什么？如何在前端项目中落地？

FB-31-CO-B-004：HTTPS/TLS 在前端安全中起到什么作用？

FB-31-CO-B-005：前端敏感数据存储有哪些风险？localStorage、sessionStorage、Cookie 该如何选择？

FB-31-CO-B-006：CORS 预检请求的作用是什么？前端如何正确配置？

FB-31-CO-B-007：什么是点击劫持？前端有哪些防御手段？

FB-31-CO-B-008：为什么输入校验不能替代输出编码？

进阶题（8 道）

FB-31-CO-A-001：OAuth 2.0 授权码流程中，前端扮演什么角色？

FB-31-CO-A-002：JWT 在前端有哪些安全使用方式与常见风险？

FB-31-CO-A-003：第三方脚本（埋点、客服、广告）有哪些安全风险？如何隔离？

FB-31-CO-A-004：前端供应链安全如何保障？

FB-31-CO-A-005：CSP nonce 与 hash 有什么区别？如何选择？

FB-31-CO-A-006：会话管理应该注意哪些安全点？

FB-31-SE-A-001：前端加密与后端加密有什么区别？前端加密能否替代 HTTPS？

FB-31-CO-A-007：安全漏洞修复的标准流程是什么？

深入题（7 道）

FB-31-CO-P-001：什么是安全左移（Shift Left Security）？前端如何落地？

FB-31-CO-P-002：前端密钥管理有哪些方案？各自的适用场景是什么？

FB-31-SE-P-001：前端零信任架构的核心原则是什么？

FB-31-SE-P-002：CSP 有哪些常见绕过方式？如何构建深度防御？

FB-31-CD-P-001：如何设计一个前端安全 SDK？

FB-31-CO-P-003：隐私合规（GDPR/个人信息保护法）对前端有哪些技术要求？

FB-31-SE-P-003：什么是前端运行时应用自保护（RASP）？

架构题（50 道）

FB-31-SD-R-001：如何为大型企业设计前端安全架构？

FB-31-CP-R-002：如何构建组织级前端安全能力平台？

FB-31-CP-R-003：安全事件应急响应流程应该如何设计？

FB-31-CP-R-004：安全架构评审清单与 ADR 应该怎么写？

FB-31-SD-R-002：微前端场景下如何做好安全隔离？

FB-31-SD-R-003：前后端安全边界应该如何划分？

FB-31-SS-R-001：如何推动团队提升安全意识？

FB-31-CO-B-009：什么是威胁建模？前端为什么需要威胁建模？

FB-31-CO-B-010：解释 STRIDE 模型。

FB-31-CO-B-011：CSP 能解决什么问题？给出一个基本配置示例。

FB-31-SE-B-001：什么是供应链安全？前端如何防护？

FB-31-SE-B-002：前端如何处理用户身份认证安全？

二、进阶题

FB-31-SE-A-002：什么是安全左移？前端如何实践？

FB-31-SD-A-001：如何设计一个隐私合规的前端应用？

FB-31-CO-A-008：第三方脚本有哪些风险？如何治理？

三、高级题

FB-31-CO-B-012：前端常见安全威胁有哪些

FB-31-CO-A-009：XSS 的类型与防护措施

FB-31-CO-A-010：CSRF 的原理与防御

FB-31-SE-P-004：内容安全策略 CSP 如何配置

FB-31-SE-A-003：前端如何安全存储 Token

FB-31-SE-P-005：前端供应链安全治理

FB-31-SE-R-001：设计一个企业级前端安全体系

FB-31-CO-A-011：什么是点击劫持及防御

FB-31-SE-P-006：前端如何处理富文本安全

FB-31-SE-A-004：HTTPS 在前端安全中的作用

FB-31-CO-A-012：什么是 Subresource Integrity

FB-31-SE-P-007：前端如何防止敏感信息泄露

FB-31-SE-A-005：前端如何处理文件上传安全

FB-31-CO-P-004：CORS 与前端安全的关系

FB-31-SE-P-008：前端如何防御 DOM Clobbering

FB-31-SE-A-006：如何安全使用第三方脚本

FB-31-CO-A-013：什么是开放重定向漏洞

FB-31-SE-P-009：前端如何做权限校验才安全

FB-31-SE-R-002：设计前端安全开发生命周期

FB-31-CO-B-013：Cookie 的 SameSite 属性

FB-31-SE-A-007：前端如何防止原型链污染

FB-31-SE-P-010：Web Storage 安全使用指南

FB-31-CO-A-014：什么是内容嗅探与 MIME 嗅探防御

FB-31-SE-A-008：前端如何处理 URL 参数安全

FB-31-SE-P-011：如何防御 JSONP 相关安全风险

FB-31-CO-R-001：前端零信任安全架构实践

FB-31-SE-A-009：前端如何应对供应链投毒事件

FB-31-CO-P-005：什么是安全标头及其前端价值

FB-31-SE-A-010：前端日志中的隐私合规

FB-31-CO-B-014：HTTPS 与混合内容安全

FB-31-SE-A-011：前端密钥管理

FB-31-CO-A-015：XSS 与 CSP 的关系

FB-31-SE-A-012：CSP report-only 模式的价值

FB-31-SC-A-001：前端上传文件安全