OAuth 与供应链安全

• Token Introspection（RFC 7662）
• UserInfo 端点
• 前端权限校验

Token Introspection（RFC 7662）让资源服务器用 token 向授权服务器查询 token 的有效性、scope、过期时间（POST /introspect，需认证）。UserInfo 端点（OIDC 的 /userinfo）返回用户信息（claims）。工程价值：前端/BFF 校验 token 有效性（introspection）与获取用户信息（userinfo），用于权限校验与用户展示。取舍：introspection 是服务端校验（带 token 查询），userinfo 是获取用户数据。前端通常通过 BFF 调用，避免直接暴露 token。工程价值：权限校验与用户信息获取。

Token Introspection 查 token 有效性，UserInfo 获用户信息。前端经 BFF 调用，用于权限校验。取舍是服务端校验（introspection）vs 数据获取（userinfo）。

• ID Token（身份）+ access_token（授权）+ refresh_token（刷新）
• 前后端分离
• 存储与使用

OIDC 的三种 token：ID Token（JWT，声明用户身份，供前端展示 claims）、access_token（授权访问资源，供 API 调用）、refresh_token（刷新 access_token）。前后端分离：ID Token 用于前端获取用户身份（解析 claims），access_token 用于调用 API（由 BFF/前端携带），refresh_token 用于无感刷新（安全存储）。工程价值：身份与授权分离。取舍：ID Token 前端可解析（但需验签），access_token 用于后端鉴权，refresh_token 需安全存储（HttpOnly Cookie 或 BFF）。工程上 BFF 模式管理 token。

ID Token 是身份、access_token 是授权、refresh_token 是刷新。前后端分离中，前端用 ID Token 展示身份，API 用 access_token，刷新用 refresh_token。BFF 管理更安全。

• WebAuthn Level 3 特性
• 团队规范
• 安全审计

WebAuthn Level 3 是 WebAuthn 规范的最新版本，增加/改进（如 conditional mediation、扩展、跨设备凭据）。团队规范：制定 WebAuthn 使用规范（算法、认证器策略、恢复流程），统一实现。安全审计：审计凭据管理（注册/认证、密钥轮换、恢复）、审计认证器/算法（用安全算法）、审计存储。工程价值：WebAuthn 规范落地 + 团队约束 + 审计保障。取舍：WebAuthn 安全但需规范与审计配合。工程上建立 WebAuthn 规范与审计。

WebAuthn Level 3 规范与团队规范、安全审计协作：规范落地、审计凭据/算法/恢复。工程价值是安全使用 WebAuthn。取舍是规范与审计成本。

• OAuth 2.1 改进
• PKCE 强制
• 安全取舍

OAuth 2.1 整合安全最佳实践：强制 PKCE（所有授权码流程）、移除 Implicit 与 ROPC、精确 redirect_uri 校验、state 强制等。PKCE 强制：所有授权码流程（包括 SPA/原生）必须用 PKCE，防授权码拦截。工程价值：OAuth 2.1 提升安全性、简化规范。取舍：PKCE 强制提升安全但需客户端实现。工程上按 OAuth 2.1 规范实现（PKCE + state + 精确 redirect_uri）。工程价值：符合现代安全标准。

OAuth 2.1 强制 PKCE、移除 Implicit/ROPC、精确 redirect_uri。工程价值是安全最佳实践。工程上按 2.1 实现。

• Implicit 模式缺陷
• ROPC 缺陷
• 移除与替代

OAuth 2.1 草案移除 Implicit 模式与 ROPC：Implicit 模式把 token 放在 URL 片段（易泄露、无法清理、无 refresh），SPA 应用应改用 Authorization Code + PKCE；ROPC 直接收密码（客户端接触密码、不适用于第三方、安全风险），应改用授权码或设备流程。移除原因：安全缺陷。替代：Authorization Code + PKCE（SPA/原生）、Client Credentials（服务端）。工程价值：改用安全流程。工程上弃用 Implicit/ROPC。

Implicit（token 在 URL 泄露）与 ROPC（客户端拿密码）不安全，OAuth 2.1 移除。替代是授权码 + PKCE。工程价值是安全流程。

• CTAP 2.2
• CDA（Client-to-Authenticator）
• 认证器交互

CTAP（Client-to-Authenticator Protocol）是浏览器/客户端与认证器（如安全密钥）之间的协议。CTAP 2.2 的 CDA（Client-to-Authenticator）是扩展，允许客户端与认证器之间更丰富的交互（如传递上下文、条件交互、扩展命令）。工程价值：增强认证器能力（如传递依赖方上下文、条件 UI），支持更灵活的 WebAuthn 流程。工程边界：需认证器支持 CTAP 2.2。工程价值：提升无密码认证的交互与能力。

CTAP 2.2 的 CDA 增强客户端-认证器交互，支持更丰富流程。工程价值是提升认证器能力，需认证器支持。

• SRI（Subresource Integrity）
• 第三方脚本防篡改
• SRI + CSP + Trusted Types 纵深防御

SRI（Subresource Integrity）用哈希校验第三方脚本：<script src=".." integrity="sha384-...">，浏览器加载后校验哈希，不匹配则拒绝执行，防 CDN 脚本被篡改。纵深防御设计：SRI 校验脚本完整性（防篡改）+ CSP strict-dynamic（脚本来源由 nonce 传递信任，防任意脚本）+ Trusted Types（限制 DOM 注入与脚本 URL）。组合：SRI 防"脚本被换"，CSP 防"注入脚本"，Trusted Types 防"DOM 注入"。工程价值：第三方脚本供应链防护。工程上第三方脚本用 SRI + CSP 白名单 + Trusted Types。

SRI 校验第三方脚本哈希防篡改，CSP strict-dynamic 防注入，Trusted Types 防 DOM 注入。纵深防御覆盖供应链与注入面。工程价值是第三方脚本安全。

• postMessage 入口防护
• 第三方依赖
• SBOM（物料清单）

postMessage 入口防护：接收 postMessage 时校验 origin 白名单、校验消息结构，防止第三方入口注入。Telegram 入口等第三方依赖：引入第三方 SDK/入口需评估并防护（校验来源、最小化）。SBOM（Software Bill of Materials）是软件物料清单，列出软件的所有依赖（组件、版本、来源），用于供应链透明与漏洞管理。工程价值：postMessage 入口（origin 校验）防注入；SBOM 追踪依赖，识别漏洞。工程上建立 SBOM 并治理入口。

postMessage 入口需 origin 校验防注入，SBOM 追踪依赖防供应链风险。工程价值是入口安全与依赖透明。取舍是 SBOM 维护成本。

• Dependency Confusion 原理
• npm registry 优先级
• scope 与 .npmrc 防御

依赖混淆（Dependency Confusion）攻击：攻击者在公共 npm 注册表发布与内部包同名的包（如 @user/private-pkg 或内部包名），当 npm 解析依赖时，若公共源优先级高于私有源，会安装公共的恶意包，导致代码执行。防御：1) 用 scope——内部包用 @scope/ 命名，私有源托管 scope；2) 配置 .npmrc——@scope:registry=https://private.example.com 指定 scope 的私有源，禁止公共源解析内部包；3) 控制 registry 优先级——确保私有源优先，公共源不用于内部包。工程价值：防依赖混淆供应链攻击。工程上 .npmrc 配置 scope 私有源。

依赖混淆是"公共源同名包劫持"。防御用 scope 隔离内部包 + .npmrc 指定私有源。工程价值是防供应链攻击。取舍是源码管理。

• 环境变量前缀（NEXT_PUBLIC_/VITE_）
• 构建产物内嵌 secret
• 防护与检测

前端环境变量：NEXT_PUBLIC_*（Next.js）、VITE_*（Vite）前缀的变量会被编译进客户端 bundle，公开可见。误用：把敏感密钥（API key、secret）用这些前缀，导致泄漏到构建产物。防护：1) 敏感密钥不放前端环境变量（放服务端/BFF）；2) 只公开非敏感配置；3) 构建后扫描产物中的 secret 检测。检测：用 secret 扫描工具（gitleaks、trufflehog）在 CI 扫描源码与产物；git 历史检查。工程价值：防密钥泄漏。工程上敏感密钥走服务端，前端只暴露必要配置。

NEXT_PUBLIC_/VITE_ 前缀会进入客户端 bundle，敏感密钥不可用。防护是敏感密钥走服务端、扫描检测。工程价值是防密钥泄漏。

• state 防 CSRF
• nonce 防重放
• PKCE 防授权码拦截

OAuth 2.0 三件套：state 参数防 CSRF（客户端生成随机 state，授权回调时校验，防止攻击者伪造授权回调）；nonce（OIDC）防 ID token 重放（客户端校验 nonce 匹配）；PKCE（code_verifier/challenge）防授权码拦截（code 被截获也无法换 token）。三者协作：state 防 CSRF 回调、nonce 防 ID token 重放、PKCE 防授权码劫持。工程价值：授权流程的完整安全。工程上三者都实现。

state 防 CSRF、nonce 防重放、PKCE 防拦截。三者覆盖 OAuth 授权流程的主要攻击。工程价值是完整防护。

• Authorization Code + PKCE
• SPA/原生应用
• 安全取舍

SPA/原生应用无法安全保存 client secret，用 Authorization Code + PKCE：客户端生成 code_verifier/challenge，用授权码 + code_verifier 换 token（无需 secret）。工程价值：SPA/原生应用安全授权（防授权码拦截、无需泄露 secret）。取舍：PKCE 无 secret 但依赖客户端正确实现；token 存前端有风险（XSS）。工程取舍：SPA 用 PKCE 授权码，token 尽量存内存/HttpOnly Cookie（BFF），避免 localStorage。工程价值：SPA 安全授权。

Authorization Code + PKCE 适合无法保密的 SPA/原生。取舍是 token 前端存储风险。工程上 BFF 管理 token 更安全。

• Refresh Token Rotation
• Token Revocation
• BFF 架构

BFF（Backend-for-Frontend）架构中，token 登录态由 BFF 管理（前端不直接持有 token）。Refresh Token Rotation：BFF 每次刷新轮换 refresh token（旧 token 失效），防 token 泄露。Token Revocation：登出/换绑时撤销 token（调用 revocation 端点或 BFF 删除）。工程实现：BFF 存储 refresh token（HttpOnly Cookie），刷新时轮换；登出时撤销并清理。工程价值：BFF 隔离 token，前端不接触敏感 token，轮换与撤销提升安全。取舍：BFF 增加一跳，但安全。

BFF 管理 token，前端不接触。Refresh Rotation 轮换 + Revocation 撤销。工程价值是 token 隔离与安全。取舍是 BFF 架构复杂度。

• Device Authorization Grant
• 电视/IoT 设备
• 流程

Device Authorization Grant（RFC 8628）用于无浏览器/受限输入的设备（电视、IoT、智能穿戴）：1) 设备请求 device_code 与 user_code；2) 设备显示 user_code 与 URL；3) 用户在另一设备浏览器输入 URL 与 user_code 授权；4) 设备轮询 token 端点换取 token。工程价值：无浏览器设备授权。取舍：需用户交互（第二设备）、轮询延迟。工程上用于电视/IoT 登录（如电视上的服务登录）。

Device Grant 让无浏览器设备用 user_code 在另一设备授权。工程价值是电视/IoT 授权。取舍是用户交互与轮询。

• Passkey 跨设备同步
• SSO/IdP
• 工程价值

Passkey 的跨设备同步（平台凭据通过云同步，如 iCloud Keychain、Google Password Manager）让用户在多设备间使用同一 Passkey。工程价值：SSO/IdP 中，Passkey 作为无密码认证因素，跨设备同步提升用户体验（Anywhere 登录），且抗钓鱼（私钥绑定 origin）。工程取舍：跨设备同步依赖平台（云同步），需恢复流程；企业可要求仅本机（non-discoverable）。工程价值：SSO 的无密码统一认证。工程上 IdP 集成 Passkey。

Passkey 跨设备同步提升 SSO 体验，抗钓鱼。取舍是平台依赖与恢复。工程价值是 IdP 无密码认证。

• CORP 声明资源
• COEP 限制嵌入
• 工程价值

CORP（Cross-Origin-Resource-Policy）声明资源是否可被跨源嵌入，COEP（Cross-Origin-Embedder-Policy）要求页面加载的跨源资源声明 CORP/CORS。工程价值：现代前端项目部署 CORP/COEP 实现跨域隔离，提供 SharedArrayBuffer 等能力，增强安全（防跨源数据泄露、防恶意资源嵌入）。工程取舍：require-corp 严格但需所有跨源资源配合，credentialless 更易部署。工程价值：跨域隔离 + 安全。工程上按需部署 CORP/COEP。

CORP/COEP 实现跨域隔离，防数据泄露与恶意嵌入，提供强能力。工程取舍是 strict vs credentialless。价值是安全与能力。

• Token 生命周期（access/refresh）
• BFF 模式
• 边界

Token 生命周期：access_token 短（分钟级）、refresh_token 长（天级）、轮换与撤销。BFF 模式：前端不直接持有 token，由 BFF 管理（存 HttpOnly Cookie），前端通过 BFF 访问 API。边界：BFF 处理 token 的获取、刷新、轮换、撤销，前端无感；BFF 隔离 token 防 XSS 泄露。取舍：BFF 增加一跳但安全。工程价值：token 生命周期管理 + 前端安全。工程上 BFF 管理 token 生命周期。

BFF 管理 token 生命周期（获取/刷新/轮换/撤销），前端不接触 token。边界是 BFF 隔离与安全。取舍是架构复杂度。

• ID Token（JWT）
• UserInfo 端点
• claims（身份声明）

OIDC 在 OAuth 2.0 上提供身份认证：ID Token 是 JWT，包含用户身份 claims（sub、name、email 等），客户端验签获取用户身份；UserInfo 端点返回更多用户 claims。claims 是身份声明（标准 claims 如 sub、name、email、preferred_username 等）。工程价值：ID Token 用于前端身份展示，UserInfo 获取完整用户信息。取舍：ID Token 适合快速身份（验签即可），UserInfo 适合完整数据。工程上验签 ID Token + 按需 UserInfo。

ID Token 是身份 JWT，UserInfo 返回用户 claims，claims 是身份声明。工程价值是身份认证与用户信息。取舍是验签 vs 数据获取。

• OAuth 2.1 PKCE 强制
• 团队规范
• 安全审计

OAuth 2.1 强制 PKCE（所有授权码流程）。团队规范：制定 OAuth 实现规范（PKCE、state、redirect_uri 校验、token 存储），统一实现。安全审计：审计授权流程（PKCE 是否实现、state 校验、redirect_uri 精确、token 存储安全）。工程价值：PKCE 强制落地 + 团队规范 + 审计保障。取舍：强制 PKCE 提升安全但需客户端实现。工程上按 2.1 规范 + 审计。

OAuth 2.1 PKCE 强制需团队规范与审计配合（授权流程、token 存储）。工程价值是安全实现。取舍是规范与审计成本。

• OIDC 与 OAuth 2.0
• ID Token 身份
• 工程价值

OAuth 2.0 是授权框架（授权访问资源），OIDC（OpenID Connect）在 OAuth 2.0 之上提供身份认证：增加 ID Token（JWT，携带用户身份 claims）与端点（UserInfo、issuer metadata）。工程价值：OIDC 让应用不仅能授权资源，还能认证用户身份（登录）。工程上登录用 OIDC（验签 ID Token 获取身份），授权用 OAuth（access_token）。取舍：OIDC 是 OAuth 的身份认证扩展。

OIDC 在 OAuth 2.0 上加身份认证（ID Token）。工程价值是登录认证。OAuth 授权 + OIDC 认证。

• HS256（对称 HMAC）
• RS256（非对称 RSA）
• 工程选择

JWT 签名算法：HS256（HMAC-SHA256，对称，用共享密钥签名/验签）、RS256（RSA-SHA256，非对称，私钥签名、公钥验签）。工程选择：HS256 简单但需共享密钥（服务端间），密钥泄露风险；RS256 更适合多方（公钥分发，验签无需共享密钥），适合身份提供方（IdP）签发、资源服务器用公钥验签。取舍：RS256 更适合分布式（非对称），HS256 适合单服务端。工程上身份 token 用 RS256（公钥验签），内部用 HS256。防算法混淆。

HS256 对称（共享密钥）、RS256 非对称（私钥签名/公钥验签）。工程上多方/身份用 RS256，防算法混淆。取舍是密钥管理。

• Implicit 弃用
• SPA 现代实践
• Authorization Code + PKCE

Implicit 模式（token 在 URL 片段）已弃用（泄露、无法清理、无 refresh）。SPA 现代最佳实践：用 Authorization Code + PKCE（客户端生成 code_verifier/challenge，用授权码换 token，无 secret）；用 BFF（Backend-for-Frontend）管理 token（HttpOnly Cookie），前端不直接持有 token；token 存内存而非 localStorage。工程价值：SPA 安全授权、防 token 泄露。取舍：PKCE + BFF 更安全但增加实现。工程上 SPA 用 PKCE + BFF。

Implicit 弃用后，SPA 用 Authorization Code + PKCE + BFF。token 存内存/HttpOnly，避免 localStorage。工程价值是安全授权。

• Client Credentials 流程
• 服务端到服务端
• 工程应用

Client Credentials 流程：客户端用 client_id + client_secret 直接换 access_token（无需用户交互），用于服务端到服务端认证（M2M）。工程价值：服务间调用（内部 API、微服务）用 client credentials 获取 token 认证。取舍：client_secret 需安全存储（服务端），无用户参与。工程上服务端用 client credentials 获取 token 调用 API。工程价值：M2M 认证。

Client Credentials 用 client_id/secret 换 token，服务端到服务端（M2M）。工程价值是服务间认证。取舍是 secret 安全存储。

• id_token 验签
• nonce 防重放
• 工程实践

OIDC 的 id_token 需验签（用 IdP 公钥，RS256/ES256）验证来源与完整性，并校验 iss/aud/exp 等。nonce 是客户端生成、随授权请求发送、在 id_token 中返回的随机值，客户端校验 nonce 一致性防重放（防止 ID token 被重放）。工程实践：验签 id_token（jwks 公钥）、校验 claims（iss/aud/exp/nonce）、防重放。工程价值：身份认证的完整性与防重放。取舍：需维护 IdP 公钥。工程上实现验签 + nonce 校验。

id_token 验签保证来源，nonce 防重放。工程实践是验签 + 校验 claims + nonce。工程价值是身份安全。

• BaaS 认证服务
• OAuth/OIDC 集成
• 工程价值

BaaS 认证服务（Auth0、Clerk、Supabase Auth）封装 OAuth/OIDC：提供登录组件、社交登录（Google/Apple）、会话管理、token 刷新、用户管理。现代集成：前端接入 BaaS SDK，处理 OAuth/OIDC 流程（PKCE、token 刷新、会话），后端验签 token。工程价值：快速集成认证，无需自建 OAuth/OIDC。取舍：BaaS 托管认证（数据在第三方），需评估合规与成本。工程上 BaaS 加速认证集成。

BaaS 认证封装 OAuth/OIDC，提供登录/会话/user 管理。工程价值是快速集成。取舍是第三方托管与合规。

• localStorage 存储
• Cookie 存储
• 内存存储

Token 存储策略：localStorage（易被 XSS 读取，但有持久性，方便）；Cookie（HttpOnly 防 XSS 读取，但需 CSRF 防护，SameSite）；内存（最安全，XSS 无法读取，但刷新丢失，需无感刷新）。工程取舍：安全优先用 HttpOnly Cookie（BFF 管理）或内存；localStorage 便利但 XSS 风险。工程价值：平衡安全与便利。工程上敏感 token 用 HttpOnly Cookie/BFF，SPA 用内存 + 刷新。

localStorage 易被 XSS 读取，Cookie+HttpOnly 防 XSS 但需 CSRF 防护，内存最安全但刷新丢失。工程取舍是安全 vs 便利。

• Scope 声明
• 权限精细化
• 最小权限

OAuth 2.0 的 Scope 声明客户端请求的权限范围（如 openid profile email、read:orders）。工程价值：精细化控制客户端可访问的资源/操作，实现最小权限；授权时用户/服务端按 scope 授权，资源服务器按 scope 校验。取舍：scope 粒度影响授权灵活性与安全。工程上定义清晰的 scope 层级，按最小权限授权，资源服务器校验 scope。工程价值：权限最小化。

Scope 声明权限范围，实现最小权限与精细化控制。工程上定义 scope、按需授权、资源服务器校验。取舍是粒度与安全。

• Refresh Token 过期
• 无感刷新（silent refresh）
• 工程实践

Refresh Token 过期后无法刷新，需重新认证。无感刷新（silent refresh）：access_token 过期时，前端静默用 refresh_token 刷新（BFF/iframe），用户无感知。工程实践：BFF 管理 refresh token，access_token 过期时自动刷新（拦截器），刷新失败（refresh 过期）才跳登录。取舍：无感刷新提升体验，但 refresh token 过期需处理。工程价值：无感续期。工程上拦截器自动刷新 + 刷新失败重新登录。

无感刷新用 refresh token 静默续期，过期才重新登录。工程实践是拦截器自动刷新。取舍是 refresh 过期处理。

• Token Introspection
• JWT（无状态）
• 会话撤销

Token Introspection 用 token 查询授权服务器的有效性（可实时撤销），JWT 是无状态（验签即可，无法实时撤销，需等过期或黑名单）。工程取舍：需要立即撤销（登出、权限变更）用 introspection（或黑名单/短 TTL）；需要无状态高性能用 JWT。工程价值：平衡撤销能力与性能。工程上混合：JWT 短 TTL + 黑名单/Introspection 兜底。取舍：Introspection 有网络开销，JWT 无状态。

Introspection 可实时撤销（有开销），JWT 无状态（难撤销）。取舍是撤销能力 vs 性能。工程上混合用。

• Backchannel Logout
• Frontchannel Logout
• 会话注销

OIDC 注销：Backchannel Logout（服务端到服务端，IdP 直接通知 RP 端点注销，可靠，不依赖浏览器）；Frontchannel Logout（通过浏览器 iframe 逐站跳转注销，需浏览器打开，依赖页面）。工程取舍：Backchannel 可靠（服务端通知）但需 RP 配置端点；Frontchannel 简单但依赖浏览器（可被拦截）。工程价值：IdP 登出时同步注销各 RP 会话。工程上关键 RP 用 Backchannel，兼容用 Frontchannel。

Backchannel 服务端通知可靠，Frontchannel 浏览器跳转依赖页面。工程取舍是可靠 vs 简单。工程价值是统一登出。

• Authorization Server Metadata
• 端点发现
• 工程应用

Authorization Server Metadata（RFC 8414）定义授权服务器的元数据文档（.well-known/oauth-authorization-server），包含授权端点、token 端点、JWKS、支持的 scope/算法等。工程价值：客户端自动发现授权服务器配置（端点、算法），无需硬编码。OIDC 的 Discovery（.well-known/openid-configuration）是其扩展。工程应用：客户端从元数据获取端点与公钥，简化配置。取舍：元数据需可被访问。工程价值：动态配置。

Authorization Server Metadata 提供端点/算法发现。工程价值是客户端自动配置。取舍是元数据可访问性。

• CTAP 2.2
• SSO/IdP
• 认证器能力

CTAP 2.2 增强认证器（安全密钥）能力，在 SSO/IdP 中：支持更丰富的认证器交互（如 CDA、条件交互、多方认证），提升 WebAuthn 无密码认证体验。工程价值：SSO/IdP 用 CTAP 2.2 认证器实现无密码、抗钓鱼登录，增强认证器能力。取舍：需认证器支持 CTAP 2.2。工程价值：IdP 的无密码认证基础设施。工程上 IdP 支持 CTAP 2.2 认证器。

CTAP 2.2 增强认证器能力，SSO/IdP 用它做无密码认证。工程价值是抗钓鱼与增强交互。取舍是认证器支持。

• CSP 域名白名单
• iframe sandbox 隔离
• 第三方脚本治理

第三方 CDN 脚本治理：CSP 域名白名单（script-src 允许信赖的 CDN 域名，避免通配）限制脚本来源；SRI 校验脚本完整性（防篡改）。运行时隔离：用 <iframe sandbox> 隔离第三方脚本（如广告、工具），限制其权限（无脚本/无同源访问），或隔离到独立 worker。工程价值：第三方脚本既能工作又受限。取舍：白名单/SRI 防加载恶意，sandbox 隔离运行。工程上白名单 + SRI + sandbox。

第三方脚本治理：CSP 白名单 + SRI 防加载，iframe sandbox 隔离运行。工程价值是供应链安全与隔离。取舍是功能与隔离。

• npm provenance
• 供应链可追溯
• 工程应用

npm 的 provenance attestation（原则上证明）让发布者证明包构建来源（构建环境、仓库、GitHub 工作流），通过 Sigstore 签名。工程价值：供应链可追溯——验证包确实来自可信来源，防止供应链攻击（构建环境被篡改、包被替换）。工程应用：发布时启用 provenance，消费时校验 provenance。取舍：provenance 增加发布流程与信任。工程价值：供应链安全的可追溯性。

npm provenance 用 Sigstore 签名证明构建来源，供应链可追溯。工程价值是防供应链攻击。取舍是发布流程与信任。

• Source Map 源码泄露
• 生产保护
• 工程应用

Source Map 映射混淆代码到源码，若生产环境暴露 .map 文件，可还原源码，泄露业务逻辑、密钥、内部实现。生产保护：生产环境不发布 source map（或仅内部/鉴权访问）；或 source map 上传到错误监控平台（Sentry）但不公开。工程取舍：source map 利于调试（错误堆栈）但泄露源码。工程上生产不公开 source map，错误监控用受限 source map。工程价值：防源码泄露。

Source Map 泄露源码/密钥。生产保护是不公开或受限访问。工程价值是防泄露，取舍是调试便利 vs 安全。

• 恶意 npm 包事件
• 自动化扫描
• 行为监控

恶意 npm 包事件：eslint-scope（被入侵发布恶意版）、event-stream（被注入窃取加密货币）、ua-parser-js（被植入后门）等，都是供应链攻击。应对措施：自动化扫描（npm audit、Snyk、依赖漏洞扫描，检查已知漏洞与签名）；行为监控（监控安装后脚本、可疑网络、运行行为）；锁定依赖（lockfile、版本固定）；SRI/provenance 校验。工程价值：供应链防护。工程上 CI 扫描 + 行为监控 + 锁定依赖。

恶意 npm 包是供应链攻击。应对是自动化扫描（漏洞/签名）+ 行为监控（安装脚本/网络）+ 锁定依赖。工程价值是供应链安全。

• open redirect 与授权码拦截
• redirect_uri 校验标准
• 双重校验/精确比对

攻击链：攻击者利用开放重定向（redirect_uri 可被操纵），构造恶意 redirect_uri，诱使用户授权后授权码被重定向到攻击者域名，攻击者用授权码换取 token（若未用 PKCE）——授权码拦截。防御：redirect_uri 严格校验——1) 授权端点与令牌端点双重校验（两端都校验一致的 redirect_uri）；2) 精确逐字节比对（不允许前缀/通配）；3) 拒绝通配符与子路径匹配；4) 校验失败时不重定向，直接报错（避免泄露信息）。工程价值：防授权码拦截。工程上注册精确 redirect_uri 并双重校验。

开放重定向 + 不严格 redirect_uri 校验导致授权码拦截。防御是双重校验、精确逐字节比对、拒绝通配/子路径、失败不重定向。工程价值是防授权码劫持。

• 提示注入
• 模型输出不可信
• 展示净化

AI 安全边界：提示注入（prompt injection）——恶意输入诱导模型执行攻击者意图（如注入指令、泄露数据）；模型输出不可信——模型可能输出恶意内容（XSS、钓鱼、危险指令）。前端影响：模型输出用于展示/交互，若直接渲染（HTML/Markdown）可 XSS。防御：模型输出视为不可信数据，展示前净化（DOMPurify）、不执行模型指令、隔离模型能力（不授予工具权限）、CSP 限制。工程价值：AI 应用的前端安全。工程上净化模型输出 + 限制模型权限。

提示注入与模型输出不可信是 AI 安全。前端需净化模型输出（DOMPurify）、限制模型权限、CSP。工程价值是 AI 应用安全。

• TUF（框架更新）
• Sigstore（签名）
• NPM 生态取舍

TUF（The Update Framework）是安全的更新框架（防篡改更新、密钥分权、委托），Sigstore 是软件签名/验证服务（签名包、提供 provenance）。NPM 生态：Sigstore 已用于 npm provenance（签名验证包来源）；TUF 的思想用于包完整性（但 npm 常用 registry 保证 + Sigstore）。取舍：Sigstore 提供签名与 provenance（实际应用），TUF 提供更新框架（稳定但实现复杂）。工程价值：供应链完整性。工程上 npm 用 Sigstore provenance，TUF 适合高安全更新系统。

Sigstore 签名/provenance 实际用于 npm，TUF 是更新框架（复杂）。取舍是签名可追溯 vs 框架复杂度。工程价值是供应链完整性。

• Typosquatting 原理
• 同名/近似名包
• 防御

Typosquatting（拼写错误劫持）攻击者发布与流行包近似名的恶意包（如 expresss 而非 express、crossenv 而非 cross-env），开发者拼错安装时安装恶意包，导致代码执行。防御：安装前核对包名、用 lockfile 锁定、CI 检查包名与来源、扫描代码引用、npm audit。工程价值：防拼写错误导致的供应链攻击。工程上安装时核对 + 锁定 + 扫描。

Typosquatting 用近似名载荷窃取。防御是核对包名、锁定 lockfile、扫描。工程价值是防拼写错误供应链攻击。

• npm sbom 生成
• CycloneDX/SPDX
• 绑定 lockfile 与构建产物

CI 中供应链校验：1) 用 npm sbom（或 @cyclonedx/cyclonedx-npm）生成 CycloneDX 或 SPDX 格式的 SBOM（物料清单）；2) 绑定 lockfile——SBOM 条目与 lockfile 一致（版本、来源），构建产物与 SBOM 一致（哈希）；3) 校验 npm provenance/Sigstore 签名——检查依赖包是否有签名、来源是否符合预期；4) 门禁——未签名、来源不符、SBOM 漂移（条目与 lockfile/产物不一致）的依赖阻断发布。工程价值：供应链完整性与可追溯。工程上 CI 生成 SBOM + 校验签名 + 门禁。

CI 用 npm sbom 生成 SBOM，绑定 lockfile/产物，校验 provenance/Sigstore，门禁阻断异常。工程价值是供应链可追溯与安全。