凌晨两点的安全事故
凌晨两点，Slack 弹出一条消息。有客户报告自己的账户被未授权访问。你查看日志后发现：三周前，一位开发者在 Next.js 的 API 路由中硬编码了 Supabase 的 service-role 密钥。在一次紧急部署中，这个密钥泄露到了公开的 GitHub 仓库。等你轮换密钥时，攻击者已经导出了用户数据。
这不是假设场景。在使用 AI 生成代码、快速交付的小团队中，这种情况经常发生。代码能跑通，测试能通过，功能上线了——但没有人做过结构化的安全审查。编写代码的 AI 助手优化的是功能性，而不是认证流程、输入处理和密钥管理中那些微妙的安全问题。
如果你构建 AI 智能体，或者使用 AI 编程助手来交付功能，你可能感受过这种张力：AI 辅助开发的速度，在「能用的代码」和「可以安全部署的代码」之间制造了一个缺口。一个遗漏的验证、一个拼接的 SQL 字符串、一个存储在 localStorage 而非 httpOnly cookie 中的令牌，都可能变成生产事故。
核心问题不在于开发者不关心安全。而在于安全审查是一种清单驱动的纪律，当你快速推进时，清单很容易被跳过。大多数团队需要的不是模糊的「注意安全」提醒——而是一份具体、可操作的清单，覆盖漏洞藏身的那些特定模式。
为什么 AI 辅助工作流中会出现安全缺口
AI 编程工具在生成功能性代码方面表现出色。但在默认情况下生成安全代码方面，可靠性较低。原因如下：
- 训练数据包含不安全模式。 互联网上充斥着硬编码 API 密钥、用字符串拼接 SQL、将令牌存储在 localStorage 中的教程。AI 模型会复现这些模式，因为它们在统计上很常见。
- 速度消除了审查压力。 当 AI 智能体在几分钟内生成功能可用的代码时，人的本能反应是直接发布，而不是再花一小时逐行审计。
- 安全是上下文相关的。 在一个上下文中安全的模式（例如只读的公开端点），在另一个上下文中可能是危险的（例如管理员删除端点）。AI 工具经常忽略这种细微差别。
- 清单是分散的。 安全最佳实践分散在 OWASP 指南、框架文档、博客文章和内部 Wiki 中。没有单一来源能覆盖与现代全栈 AI 辅助工作流相关的所有模式。
结果就是一组可预测的反复出现的漏洞：
- 源代码中硬编码的密钥
- 缺失或薄弱的输入验证
- 通过字符串拼接导致的 SQL 注入
- 令牌存储在 localStorage（容易受到 XSS 攻击）
- 敏感端点缺少授权检查
- 高开销 API 路由没有速率限制
- 日志或错误消息中泄露敏感数据
- 状态变更操作缺少 CSRF 保护
一个好的解决方案应该让检查每个类别变得简单，提供具体的通过/失败示例，并融入使用 AI 编程工具的工作流——不是替代开发者，而是给他们一个结构化的审查界面。
Security-Review 技能提供了什么
Security-Review 技能 是一个结构化的清单和模式库，专为使用 AI 编程助手的开发者设计。它来自 everything-claude-code 仓库，这是一个为 Claude Code 工作流设计的可复用技能集合。
这个技能不是扫描器、不是代码检查工具、也不是运行时工具。它是一个结构化的参考文档，AI 智能体（或人类）可以在代码审查期间查阅，以验证常见安全模式是否被遵循。可以把它理解为一份详细的、针对具体代码的安全清单，覆盖八个主要类别。
它覆盖的八个安全领域
-
密钥管理 — 检测硬编码的 API 密钥，验证环境变量的使用，检查
.gitignore是否包含.env文件，确认生产密钥存储在托管平台中。 -
输入验证 — 强制使用基于 Schema 的验证（例如 Zod），按大小、类型和扩展名限制文件上传，确保错误消息不泄露内部细节。
-
SQL 注入防护 — 验证所有数据库查询使用参数化查询或 ORM 方法，SQL 字符串中没有字符串拼接。
-
认证与授权 — 检查令牌存储方式（httpOnly cookie vs. localStorage），验证敏感操作前的授权检查，确认在适用的地方启用了行级安全（RLS）。
-
XSS 防护 — 确保用户提供的 HTML 被清理（例如使用 DOMPurify），配置了内容安全策略（CSP）头，
dangerouslySetInnerHTML的使用是安全的。 -
CSRF 保护 — 验证状态变更操作上的 CSRF 令牌、SameSite cookie 属性和双重提交 cookie 模式。
-
速率限制 — 确认 API 端点存在速率限制，对搜索或文件处理等高开销操作有更严格的限制。
-
敏感数据暴露 — 检查日志中不包含密码、卡号或令牌，返回给用户的错误消息不暴露堆栈跟踪或内部路径。
每个类别都包含 TypeScript 的具体失败和通过代码示例，让你可以轻松地将当前代码与预期模式进行对比。例如，技能会精确展示硬编码密钥是什么样的，以及正确的环境变量方式是什么样的，并附带可以逐项勾选的验证步骤。
如何融入工作流
该技能设计为在特定场景下激活，而不是在每次提交时都运行。推荐的激活触发条件包括：
- 实现认证或授权逻辑
- 处理用户输入或文件上传
- 创建新的 API 端点
- 处理密钥或凭证
- 实现支付功能
- 存储或传输敏感数据
- 集成第三方 API
实际使用中，你可能会这样操作：你让 AI 编程助手构建一个用户注册端点。代码生成后，你（或智能体）激活 security-review 技能并逐项检查清单。技能标记出生成的代码将 JWT 存储在 localStorage 中——这是一个失败模式——你在上线前切换为 httpOnly cookie。
这个技能适合什么场景——不适合什么场景
适合的场景
- 你正在构建有用户账户、支付或敏感数据的 Web 应用。 清单覆盖了这些场景中出现的精确模式。
- 你使用 AI 编程助手，想要一种结构化的方式来审计生成的代码。 技能给你一个具体的审查界面，而不是依赖记忆。
- 你是独立开发者或小团队，没有专职安全工程师。 清单弥补了缺乏专业安全审查的不足。
- 你使用 Next.js、Supabase、Express 或类似现代技术栈。 代码示例直接使用这些技术。
不适合的场景
- 你需要自动化的运行时安全扫描。 这个技能是参考清单，不是在 CI/CD 中运行或监控生产流量的工具。
- 你使用的语言或框架不在示例覆盖范围内。 代码示例以 TypeScript/JavaScript 为主。原则可以迁移，但具体模式可能不适用。
- 你需要合规认证（SOC 2、HIPAA、PCI-DSS）。 这个技能覆盖常见的 Web 应用漏洞，不涉及监管合规框架。
- 你需要依赖项漏洞扫描。 这个技能关注应用层代码模式，不涉及第三方包漏洞。
使用前需要检查什么
在将这个技能融入工作流之前，请考虑以下几点：
仓库信号
- everything-claude-code 仓库 有大量 star，表明社区关注度高。但 fork 数为零，这可能意味着仓库主要被用作参考，而非被 fork 后修改使用。
- 仓库许可证标记为 "Sponsors"，可能表示赞助或资助模式。请查看许可证条款以了解你的义务。
- 安全级别标记为 "Low"，这可能指的是仓库自身的安全态势或分类，而非技能的有效性。
内容质量
- 技能的清单很详细，包含具体的代码示例和失败/通过对比。这比抽象的安全建议更具可操作性。
- 示例使用了现代工具（Zod 做验证、DOMPurify 做清理、Supabase RLS），这些在当前 AI 辅助开发栈中很常见。
- 技能没有覆盖所有可能的漏洞类别。例如，它不涉及服务端请求伪造（SSRF）、不安全的反序列化或加密实现缺陷。如果你的应用涉及这些领域，你需要额外的审查资源。
集成上下文
- 技能设计用于 Claude Code 工作流，但清单本身在原则上是框架无关的。无论你使用什么 AI 工具，都可以将其作为手动审查指南使用。
- 没有提供安装命令。技能是一个参考文档（SKILL.md），你查阅它，而不是安装一个包。
- 技能不会修改你的代码。它提供模式和验证步骤。你（或你的 AI 智能体）必须自行应用更改。
实际示例：审查支付端点
假设你的 AI 助手生成了这个支付端点：
export async function POST(request: Request) {
const { cardNumber, amount, userId } = await request.json()
// 处理支付
const result = await stripe.charges.create({
amount,
currency: 'usd',
source: cardNumber,
})
console.log('支付已处理:', { cardNumber, amount, userId })
return Response.json({ success: true, chargeId: result.id })
}
对照 security-review 清单检查这段代码，会标记出：
- 输入验证（失败）： 对
cardNumber、amount、userId没有 Schema 验证。恶意用户可以发送负数金额或非数字值。 - 敏感数据暴露（失败）： 完整的卡号被记录到控制台。这违反 PCI-DSS 并造成数据泄露风险。
- 认证（失败）： 没有验证请求是否来自已认证用户。任何人都可以调用这个端点。
- 速率限制（失败）： 支付端点没有速率限制，这是一个高开销操作，也是滥用的目标。
- CSRF 保护（失败）： 状态变更的 POST 请求没有 CSRF 令牌验证。
应用技能的模式后，修正版本会包含 Zod 验证、脱敏日志、认证中间件、速率限制和 CSRF 验证。清单以结构化的方式让这些缺口变得可见。
总结
安全审查是一种受益于结构化的纪律。当你使用 AI 生成的代码快速交付时，拥有一份覆盖八个最常见漏洞类别——密钥、输入验证、SQL 注入、认证、XSS、CSRF、速率限制和数据暴露——的具体清单，可以降低发布可预防漏洞的概率。
Security-Review 技能 将这种结构提供为可复用的参考文档。它不是自动化安全工具、渗透测试或合规审计的替代品。它是一个实用的首轮审查界面，能捕捉 AI 编程助手最容易出错的模式。
如果你的工作流涉及使用 AI 工具生成代码并部署到生产环境，请检查这个技能的清单，评估其类别是否覆盖了你应用中的风险领域。结构化审查的成本是几分钟。遗漏漏洞的代价则以事故响应、客户信任和监管风险来衡量。