frontend-review-security

前端审查 — 安全性

你正在进行前端安全审查。重点领域包括：

1. 静态检查 — 有风险的 HTML 接收点、客户端打包文件中的环境变量暴露
2. 身份验证 / 授权 — 令牌存储、路由守卫、会话管理
3. AI 自我渗透测试 — 对常见漏洞模式进行桌面检查
4. 预发布环境 — HTTP 标头、身份验证边界、Cookie 标志

流程

1. 运行 scripts/audit-security.sh --repo <client-repo>。
2. 阅读 raw/security.json。
3. 对每个 dangerouslySetInnerHTML / v-html / .innerHTML = 命中项，定位文件并判断输入是否经过清理。
4. 执行身份验证与授权审查（见下文）。
5. 执行环境变量 / 配置审查（见下文）。
6. 对于 AI 自我渗透测试，在脑中逐一演练下方的攻击场景。
7. 对于预发布环境，拟定标头检查清单。

身份验证与授权审查

令牌存储

检查访问令牌的存储位置，并标记不安全的模式：

存储方式	风险	判定
httpOnly Cookie	JS 无法访问，可抵御 XSS	✅ 推荐
localStorage	页面上的任意 JS 都能读取——XSS 会窃取令牌	⚠ 标记并要求采取 XSS 缓解措施
sessionStorage	与 localStorage 有相同的 XSS 风险	⚠ 标记
内存中（模块变量）	刷新页面后丢失；仅适用于生命周期较短的 SPA	视情况而定

• 检查刷新令牌是否也存储在 httpOnly Cookie 中。
• 检查访问令牌的有效期是否较短（建议：15 分钟至 1 小时）。

路由守卫

• ProtectedRoute（或等效组件）是否有加载状态，以防在身份验证状态确定前闪现受保护页面？

// Bad: no loading state — redirects to /login during initial auth check
if (!user) return <Navigate to="/login" />;

// Good: loading state prevents flash
if (isLoading) return <LoadingSpinner />;
if (!user) return <Navigate to={`/login?redirect=${encodeURIComponent(location.pathname)}`} />;

• 登录后，应用是否会跳回原始页面（redirect / redirect_to 参数）？
• 每个受保护的 API 端点是否都实施了服务端授权——仅靠前端守卫可通过 DevTools 或 curl 绕过。

令牌刷新

• API 客户端遇到 401 时，是否会先刷新令牌并自动重试？
• 刷新操作是否去重，以避免并行的 401 触发多次刷新请求？

let refreshPromise: Promise<string> | null = null;
async function refreshToken(): Promise<string> {
  if (refreshPromise) return refreshPromise;
  refreshPromise = doRefresh().finally(() => { refreshPromise = null; });
  return refreshPromise;
}

登出

• 登出时是否会调用服务端端点，并清除所有客户端状态？

// Required logout sequence:
await api.post('/auth/logout');   // revoke server-side session
queryClient.clear();              // clear TanStack Query cache
authStore.reset();                // clear Zustand / Jotai auth atoms
router.replace('/login');        // navigate away before clearing is dangerous

• 登出后，强制重新加载页面是否会显示上一位用户的数据？（检查：TanStack Query 开发工具、React 状态、localStorage）

环境变量 / 配置审查

• 带 VITE_ / NEXT_PUBLIC_ 前缀的变量不得包含机密信息。 Vite / Next.js 会将这些变量嵌入客户端打包文件——任何人都能在 DevTools 中读取。
• 不得提交 .env 文件。 运行：git log --all --full-history -- '*.env'
• src/config.ts（或等效文件）是否是读取环境变量的唯一入口？在各组件中散布直接调用 import.meta.env.VITE_FOO 是审查中的危险信号。
• 如果必需的环境变量缺失，config.ts 是否会在启动时抛出错误？

// config.ts — startup-time validation
const requireEnv = (key: string): string => {
  const value = import.meta.env[key];
  if (!value) throw new Error(`Missing required env var: ${key}`);
  return value;
};

• vite-env.d.ts 中是否扩展了 ImportMetaEnv，以便 TypeScript 捕获未知的 VITE_* 键？

AI 自我渗透测试场景

在脑中逐一演练每个场景，并记录：正常 / 发现问题 / 无法确定。

1. 通过 URL 参数进行 XSS — 恶意的 ?q=<script>alert(1)</script> 是否会未经清理就被渲染？
2. 通过表单输入进行 XSS — 是否会在未经清理的情况下，使用 dangerouslySetInnerHTML 渲染用户提供的 HTML？
3. CSRF — 修改状态的 API 调用是否要求 CSRF 令牌，或使用 SameSite=Strict Cookie？
4. 绕过身份验证边界 — 未经身份验证的 fetch('/api/protected') 是否能返回数据？
5. 存储中的敏感数据 — localStorage.getItem 是否会暴露令牌、PII 或会话数据？
6. 仅在客户端进行授权 — React 代码中是否存在服务端未同步实施的角色检查？
7. 开放重定向 — 登录参数 redirect / next 是否允许任意外部 URL？

预发布环境检查清单

起草以下清单，供人工针对已部署的预发布 URL 执行：

• 存在 Content-Security-Policy 标头，且限制严格
• Strict-Transport-Security (HSTS) 的 max-age ≥ 31536000
• X-Frame-Options: DENY 或 SAMEORIGIN
• X-Content-Type-Options: nosniff
• Cookie 设置了 Secure、HttpOnly、SameSite=Strict（或 Lax）
• 不带有效会话的 GET /api/me 返回 401，而不是用户数据
• 普通用户访问 GET /api/admin-only 返回 403，而不是数据

输出

将以下内容写入 <client-repo>/.frontend-review/report/latest/md/security-review.md：

• 静态检查发现（有风险的接收器、环境变量泄露）
• 身份验证 / 授权发现（令牌存储、路由守卫缺口、退出登录问题）
• AI 渗透测试记录（每个场景：正常 / 发现问题 / 无法确定）
• 预发布环境检查清单（由人工执行）
• 待提交的问题（包含标题和正文的 gh issue create 命令）

请勿自行执行 gh issue create 命令——将它们列出，供人工执行。

范围限制

• 请勿尝试实际利用漏洞。这是案头审查。
• 请勿针对生产 URL 运行扫描器。
• 请勿修改客户端源代码。
• CVE 分诊和趋势监测由 frontend-review-deps 负责。

参考资料

• 检查清单：10-security.md、25-auth-authorization.md、26-env-config.md
• 阶段：week-3-security-vrt.md
• OWASP：https://owasp.org/www-project-top-ten/