浏览器安全与 BFF 集成

• Provider 密钥为何不能放前端
• BFF 层安全职责的分层
• 认证、授权、限额、审计的结合

Provider 密钥（API key）必须由 BFF 持有，绝不能放前端——前端代码可被查看、篡改、提取，泄露会导致额度滥用与成本失控。BFF 作为唯一出口，分层承担安全职责：认证（验证浏览器用户身份，如 OIDC Cookie）、授权（该用户是否允许调用某模型/工具）、限额（按用户/项目配额与成本熔断）、审计（记录每次调用、token、成本、requestId）。浏览器只与 BFF 交互，BFF 代理上游 Provider 并持有密钥。

安全边界是"前端不可信"：密钥只能留在服务端。BFF 把认证、授权、限额、审计集中，既保护密钥又统一治理。前端只发送"用户请求"，BFF 决定"能否执行"。

• 转义（文本层）与净化（结构化层）的区别
• CSP 与 Trusted Types 的纵深防御
• 各机制的分工

转义是对纯文本/插值内容把特殊字符转成安全实体，防止在文本节点被解析为标签；净化（sanitize）是对 Markdown 解析出的 HTML 用白名单（DOMPurify）过滤不可信标签与属性；CSP 是浏览器级策略，限制可加载的脚本/样式来源，即使 XSS 被注入也难以执行；Trusted Types 强制 DOM 写入只能接受可信的 policy 对象，从根本上阻止字符串串入 innerHTML 这类危险 sink。三者的分工：转义管"纯文本插值"，净化管"富文本白名单"，CSP/Trusted Types 是纵深防御兜底。

单层防御不足。模型输出经 Markdown 渲染会产生 HTML，必须净化；即使净化有漏洞，CSP 和 Trusted Types 也能兜底。转义、净化、CSP/Trusted Types 是不同层级的防御，需组合使用。

• 沙箱 iframe 隔离不受信内容
• MIME 嗅探防护（防绕过）
• 对象 URL 的生命周期

文件预览加载不可信内容（HTML/SVG/PDF）：沙箱 iframe 用 sandbox 属性隔离脚本执行与导航，防止恶意文件在父页面执行；MIME 嗅探防护：服务端返回严格 Content-Type 且设置 X-Content-Type-Options: nosniff，禁止浏览器按内容嗅探类型，防止 HTML 伪装成图片执行；下载策略：对危险类型强制下载而非预览；对象 URL（blob URL）生命周期管理：预览后及时 revokeObjectURL 释放内存，避免泄漏。

文件预览是注入面。沙箱 iframe 隔离执行，nosniff 防嗅探绕过，下载策略兜底，blob URL 生命周期管理防内存泄漏。四者构成文件安全预览的完整防线。

• BFF 对 AI 的适配性（密钥、流式、长连接）
• 凭证、限流、审计的集中化
• 与上游 Provider 的职责划分

BFF 特别适合 AI 应用：它集中持有 Provider 密钥（前端不可信）、适配流式（SSE/WebSocket）与长连接、统一做凭证管理、限流、成本熔断、审计与配额，还能封装不同 Provider 的差异。凭证、限流、审计应集中在 BFF，而非分散到上游——上游 Provider 是第三方，无法统一治理；集中在 BFF 才能按用户/项目限额、熔断与审计。上游只负责执行模型调用，安全治理在 BFF。

BFF 是 AI 应用的安全与治理边界。密钥、限流、审计集中到 BFF 才能统一控制成本与合规，分散到上游无法按业务用户治理。这是"前端不信任、上游不治理、BFF 集中治理"的架构。

• OAuth/OIDC 授权码流程
• Cookie vs JWT 的选择
• 会话管理与刷新

浏览器到 BFF 的认证用 OIDC 授权码流程（Authorization Code + PKCE），浏览器拿到授权码后由 BFF 换取令牌，BFF 用 HttpOnly + Secure + SameSite Cookie 维护会话，避免令牌暴露给前端 JS。JWT 可作 BFF 内部会话令牌，但不放前端可读处。Cookie 方案更适合浏览器（自动携带、防 XSS 窃取 token），JWT 适合跨域/服务间。刷新用 refresh token 静默续期，Cookie 过期时引导重新登录。

浏览器端认证最安全的是"授权码 + PKCE + HttpOnly Cookie"，前端不接触令牌，降低 XSS 窃取风险。选择 Cookie 还是 JWT 取决于是否跨域与前端安全模型。

• 按用户配额（并发连接数、时长、token 速率）
• 成本熔断机制
• 防止单用户耗尽预算

BFF 对长流做按用户配额与成本熔断：限制每个用户的并发连接数（如同时最多 2 个流）、单连接的最长时长、以及 token 输出速率（如每秒/每分钟 token 上限）。通过令牌桶对 token 计数，达到配额上限时熔断（拒绝新连接或强制终止），防止单用户长连接耗尽整体预算。熔断时返回明确错误码，前端可展示。配额按用户/项目计费账户结算，超限告警并暂停。

长连接是成本放大器，单用户可并发耗大量 token。BFF 必须按用户做多维度配额（连接数、时长、速率）+ 熔断，才能控制成本与公平性。这是 AI 成本治理的关键。

• 扩展名与真实 MIME 的校验
• 大小限制与恶意载荷检测
• 用户授权校验

多模态上传校验分层：扩展名只能作为提示，真实 MIME 用文件头（magic bytes）检测，二者不一致即拒绝；大小限制在服务端强制（前端限制只作体验，服务端为准）；恶意载荷用病毒扫描 + 内容检查（如解压炸弹、含脚本的 SVGs/HTML 拒绝或转存）；用户授权校验该用户是否有权上传该类型/大小/存储位置。校验必须在服务端执行，前端校验只是 UX 辅助。

上传校验的原则是"服务端为准、多层校验"。扩展名可伪造，必须用 magic bytes 检测真实类型；恶意内容过病毒扫描；授权校验防越权上传。前端校验提升体验，服务端校验保证安全。

• 泄露渠道（错误页、Source Map、响应、状态仓库）
• 系统 Prompt 与工具信息的脱敏
• 发布与配置防护

系统 Prompt 与内部工具细节绝不能出现在前端产物中：错误页只展示脱敏的通用错误信息，不包含内部堆栈与 Prompt；Source Map 在生产环境不发布或加访问控制，避免反编译出内部逻辑与 Prompt；网络响应只下发必要字段，Prompt/工具定义过滤，甚至只下发"会话级"引用而非原始 Prompt；状态仓库（Redux 等）不存系统 Prompt，只存渲染所需的最小数据。发布检查用脚本扫描产物，确认无 Prompt 资产与内部配置。

前端是"不完全可信"的暴露面，任何进入前端的数据都可能被提取。因此系统 Prompt、工具内部实现、密钥绝不能进前端，要靠"最小化下发 + 不发布 Source Map + 脱敏错误 + 发布扫描"来收敛。

• 同源策略、CORS、CSRF 的各自作用
• CORS 的本质（浏览器的跨域控制）
• 为什么 CORS 不是授权

同源策略是浏览器默认限制跨域读取的机制；CORS 是服务端声明允许哪些源跨域访问的机制，它控制的是"浏览器是否允许读取响应"，用于 API 的跨域访问控制；CSRF 防护针对"攻击者利用用户已认证的会话发起恶意请求"，BFF 用 SameSite Cookie、CSRF token、双重提交校验等防护。CORS 不是授权机制：它只控制浏览器侧能否跨域读取，不验证请求者身份与权限，任何人都可直接用 curl 绕过 CORS 访问——真正的授权必须由服务端验证身份与权限。

CORS 是浏览器层面的"跨域读取策略"，不是安全授权。它挡不住非浏览器客户端。授权必须由 BFF 基于认证与权限判断，CSRF 是另一类攻击需单独防护。三者角色不同。

• 本地模型 vs 云端 API 的差异
• 凭证、数据落地、模型供应链风险
• 风险权衡

本地模型（如 WebGPU/WASM 跑模型）与云端 API 风险不同：凭证方面，本地模型无需网络凭证，但可能需下载模型文件；云端 API 需持有密钥（由 BFF 管理）。数据落地：本地模型数据不出设备，隐私好，但设备内存/性能受限；云端 API 数据上云，需考虑传输加密与合规。模型供应链：本地模型文件需校验来源与完整性（Hash、签名），防投毒/篡改；云端 API 由 Provider 托管，但依赖第三方供应商的供应链安全。两者权衡：本地模型重隐私与离线，云端 API 重能力与易用，各自要管理不同的供应链与数据风险。

关键差异是"数据是否出设备"与"模型文件从哪来"。本地模型要防模型文件投毒与设备安全，云端 API 要防凭证泄露与数据合规。选择取决于隐私、能力与成本需求。

• MIME 与扩展名校验
• 大小限制
• 病毒扫描与内容安全

BFF 服务端校验：真实 MIME 用 magic bytes 检测，与扩展名比对，不一致拒绝；文件大小限制（按类型），超限拒绝；病毒扫描（对可执行/文档类型）；恶意内容检查（SVG/HTML 中的脚本、解压炸弹、超深嵌套）；文件类型白名单；存储前对文件重命名（防路径穿越）并校验授权。所有校验在服务端，前端限制仅作体验。

服务端校验是上传安全的核心。真实类型检测、大小限制、病毒扫描、内容安全、路径安全五者缺一不可。前端校验可被绕过，必须以服务端为准。

• 完整堆栈泄露的风险
• 用户友好错误提示的设计
• 内部错误日志与用户提示的分离

完整错误堆栈会泄露内部实现（文件路径、框架、依赖版本、内部服务信息），可能被攻击者利用。前端只展示脱敏的用户友好提示（如"网络请求失败，请重试"、"模型服务暂时不可用"），并给出可执行建议（重试、联系支持）。完整堆栈由服务端日志记录（带 requestId），前端只上传 requestId 与错误码用于关联诊断，不展示堆栈。

错误信息要"内外分离"：用户看到友好提示，工程师通过 requestId 查内部日志。堆栈是内部信息，暴露即泄露攻击面。错误码 + requestId 关联是标准做法。

• 直连模式的最小安全要求
• 短期凭证、Referer 限制、配额
• 直连模式的局限

若必须浏览器直连 Provider（直连模式），最小安全要求：使用短期、限定的凭证（如短期一次性 token，限定来源域、会话、能力和有效期），开启 Referer/Origin 限制让 Provider 只接受你的域名请求，设置配额与速率限制防止滥用，内容安全（不用完整 API key，用短期签名）。但直连模式本质不可完全安全（凭证必然暴露给前端），应尽量收敛到 BFF 代理。直连仅用于低风险、可重建的场景。

直连模式把凭证暴露给前端，这是根本缺陷。最小化方案是短期 + 限定 + 配额 + 来源限制，把风险降到最低，但无法消除。最佳实践仍是 BFF 代理。

• Prompt 资产的分级
• 可放前端的 vs 必须放服务端的
• 收敛泄露面

Prompt 资产按敏感度分级：可公开的提示文案、UI 文案可放前端；但业务规则、few-shot 示例、内部工具定义、评分标准、审核策略等敏感内容必须移至服务端，因为它们从前端可被提取、可被攻击者利用或存在商业机密。分级原则：凡是由此泄露会产生安全/合规/商业风险的 Prompt 内容，一律只在服务端拼装，前端只接收渲染所需的最小结果。通过发布扫描确认前端产物不含敏感 Prompt。

前端是暴露面，Prompt 中嵌入业务规则与 few-shot 是"可提取资产"。分级治理：UI 文案可公开，业务逻辑与敏感数据移服务端。收敛泄露面是 AI 安全设计的一部分。

• 打包产物与 Source Map 的扫描
• 错误页的脱敏验证
• 发布流程的自动化检查

在 CI/CD 发布流程加入自动化检查：扫描打包产物与 Source Map，检测是否包含敏感 Prompt 片段、密钥、内部工具定义（用正则/关键字/哈希匹配）；验证错误页不包含完整堆栈与内部信息；用危险字符串黑名单（如系统提示词关键词、API key 模式）做正向与反向检查。可在构建时用 Source Map 混淆/剥离，生产不发布 Source Map。检查失败则阻断发布。

发布扫描是"泄露防线"的最后关卡。在 CI 中自动扫描产物与 Source Map，把敏感资产检测纳入发布门禁，防止泄露进入生产。这比事后发现更主动。

• Trusted Types 的原理
• 为 AI 输出定义 policy
• 合法渲染与阻断的平衡

Trusted Types 强制所有 DOM 写入（innerHTML、href、src 等危险 sink）必须接收 TrustedHTML 对象，而非任意字符串。前端为 AI 输出的 Markdown 定义 policy：在 policy 中先做净化（DOMPurify），再把净化后的 HTML 包装为 TrustedHTML。这样未净化字符串无法直接写入 DOM，同时净化后的合法渲染正常进行。对强制类型之外的 sink（如 attribute 赋值）也需 policy 覆盖或改用安全 API。

Trusted Types 的"阻"与"保"：阻止任意字符串写入，同时通过 policy 允许"已净化的内容"。AI 输出的安全法则是"净化 + Trusted Types"，既防 XSS 又保留合法 Markdown 渲染。

• 反向代理缓冲对流式的影响
• 超时配置
• 流式与代理的配合

SSE/WebSocket 经过反向代理时，需关闭缓冲（X-Accel-Buffering: no、proxy_buffering off）让 token 实时到达前端，否则代理会缓冲整段再发送，破坏流式体验；同时设置合理的超时（读超时、空闲超时、代理空闲连接超时），避免长连接被过早断开。心跳/keepalive 保持连接活跃。代理层需透传 SSE 头与 Upgrade 头（WebSocket）。

反向代理的缓冲与超时是流式体验的常见瓶颈。关闭缓冲保证实时、配置超时与心跳保证长连接稳定，透传升级头保证 WebSocket 正常。

• 隐藏 Provider 域名
• BFF 代理流式
• 域名解耦与安全

通过 BFF 代理流式响应，前端只与 BFF 域名通信，BFF 转发到 Provider 并把 SSE 返回给前端。这样前端不暴露 Provider 域名，也无法直接访问 Provider API（避免绕过限额与密钥）。BFF 可做域名解耦、加密、配置切换，前端请求路径统一。CORS 也只需对 BFF 配置。

隐藏 Provider 域名是安全与架构需求：前端不接触 Provider，无法绕过 BFF 的限额与审计。BFF 代理让 Provider 对前端透明，域名集中到 BFF。

• 缓存容量与清理策略
• 安全边界与加密
• 离线会话与临时文件管理

本地缓存设计：设置容量上限（IndexedDB 常<100MB，按需设上限），用 LRU/按时间清理旧会话与临时文件；Cache Storage 用于静态资源与离线。安全边界：IndexedDB 明文，敏感数据（Prompt、生成历史）应用层加密；临时文件（blob URL、下载缓存）及时清理并 revokeObjectURL；按用户/项目隔离存储。离线会话仅缓存必要数据，恢复后与服务端同步校验。

本地缓存要管理"容量、清理、安全"三方面：容量上限防占满，清理防陈旧，安全边界防敏感数据明文泄漏。离线能力与安全需平衡。

• AI 特有的前端安全检查
• DOMPurify 配置审查
• CSP nonce 与 Trusted Types 验证

AI 前端安全审计特有检查项：DOMPurify 配置是否开启严格白名单（禁用危险标签/属性、关闭允许脚本的配置）、是否覆盖所有 AI 输出渲染路径；CSP 是否配置 nonce/哈希并禁止 unsafe-inline、是否覆盖所有页面；Trusted Types 是否启用并覆盖所有危险 sink；SSE/JSON 渲染路径是否都走净化；上传/MIME 校验；错误脱敏；Prompt 资产不泄露。审计应纳入自动化扫描与人工代码审查。

AI 应用安全审计要聚焦"模型输出渲染"这一特殊注入面：净化、CSP、Trusted Types 三者配置是否严密，以及 Prompt 资产是否泄露。这些是 AI 前端相对传统前端的特有风险点。

• 短期凭证的来源限定
• 会话与能力限定
• 有效期控制

浏览器直连 Realtime 服务时，短期凭证应限定：来源（仅允许你的域名/Origin，Provider 校验）、会话（凭证绑定单一会话/requestId，不可复用）、能力（仅允许所需操作，如仅该会话的音频/文本，不开放管理权限）、有效期（短 TTL，如几分钟，到期自动失效）。凭证由 BFF 签发（服务端签名），用 JWT 或签名 URL 承载这些限制，Provider 签发时校验。过期后需重新通过 BFF 获取。

直连 Realtime 的凭证必须"最小化 + 短命"：来源、会话、能力、有效期四重限定，把暴露窗口降到最小。凭证由 BFF 签发保证可信，前端只拿短期票据。