Claude Code：用于快速 Web 应用抽查的安全检查清单

轻量级安全抽查是什么

轻量级安全抽查是一次快速审查（通常 30–60 分钟），旨在在发布前捕捉明显且影响大的问题。它不是全面审计。把它想成一次安全走查：扫描那些在真实应用中最常出错的路径，寻找证据而不是猜测。

这份 Claude Code 安全检查清单侧重于日常 Web 应用中最容易出问题的领域：

• 认证假设（你如何确认用户身份）
• 授权缺口（他们被允许做什么）
• 输入校验
• 密钥/凭证处理
• 常见注入面（SQL、命令执行、模板渲染、重定向、上传）

它并不试图证明漏洞不存在、模拟复杂的威胁行为体或替代渗透测试。

“具体发现（Concrete findings）”意味着你记录的每个问题都有开发者可以立即采取行动的证据。对于每个发现，记录：

• 精确的文件和函数/处理器名称
• 一句说明有风险的行为
• 最小可复现步骤（请求、载荷或点击路径）
• 为什么重要（影响）以及谁可以触发它
• 一个安全的修复方向（不是完整重写）

AI 是辅助工具，不是权威。用它来搜索、总结并提出测试，然后通过阅读代码并在可能的情况下用真实请求复现来验证。如果模型不能指出具体位置和步骤，就把该说明视为未经证实。

在 10 分钟内设定范围

快速审查只有在缩小目标时才能奏效。在让 Claude Code 看任何东西之前，先决定今天想要证明的内容和不检查的部分。

从 1 到 3 条真实用户路径开始，那些错误会造成经济损失、暴露数据或授予权限。好的候选是登录、密码重置、结账和管理员编辑页面。

接着列出你必须保护的资产。要具体：用户账号、支付操作、个人数据、仅管理员可用的操作等。

然后用简单话语写下你的威胁假设。你是在防御一个好奇的用户、一个带脚本的外部攻击者，还是一个有部分访问权限的内部人员？你的答案会改变“足够好”的标准。

最后，定义通过和失败的标准，这样抽查会以发现结果结束而不是凭感觉。简单的规则往往效果很好：

• 通过：每个敏感操作都有明确的认证和授权检查。
• 失败：任何端点信任客户端提供的用户 ID 或角色。
• 通过：输入在服务器端被校验，而不仅仅在 UI。
• 失败：密钥出现在日志、配置或客户端代码中。

如果你无法描述失败的样子，范围仍然太模糊。

准备你提供给 Claude Code 的上下文

抽查只有在模型查看正确位置时才有用。收集一小束代码和说明，让审查能产生证据而非猜测。

开始时分享安全关键路径：请求入口点以及决定用户身份和权限的代码。包括足够的上下文来展示数据如何流动。

一个实用的代码包通常包括：

• 认证入口：会话/JWT 解析、Cookie 设置、登录回调、认证中间件
• 路由 + 处理器：控制器、RPC 方法、GraphQL 解析器、后台作业处理器
• 数据层：ORM 查询、原生 SQL 辅助、查询构建器、敏感表的迁移
• 策略检查：角色检查、所有权检查、特性开关、仅管理员端点
• 验证：请求模式验证、文件上传处理、反序列化代码

再加几行环境说明以明确假设：会话还是 JWT、令牌存放在哪里（Cookie 或 Header）、是否有反向代理或 API 网关、队列/定时任务、以及任何“仅内部”端点。

在追踪漏洞前，先要求进行清单盘点：入口点、受限端点和被触及的数据存储。这能防止错过攻击面。

还要就输出格式达成一致，强迫给出具体发现。一个简单的表格很有用：发现、严重性、受影响端点/文件、证据（精确片段或行范围）、利用场景、修复建议。

30–60 分钟审查的逐步工作流

将时间模块化：

• 10 分钟用于定向
• 15–30 分钟用于追踪流程
• 10 分钟用于写报告

目标不是完美覆盖，而是一小组可测试的发现。

在阅读代码时保持应用打开。点击 UI 并观察发出哪些请求。笔记应指向特定端点、参数和数据来源。

一个适合一次完成的工作流：

1. 草绘入口点和信任边界。标记公开路由、登录路由、管理员路由、Webhook、上传和第三方回调。标出数据何时从用户可控变为服务器信任。
2. 对每个重要端点，写下证明身份的方式以及发生位置。如果检查在“中间件”，确认每条路由确实使用了它。
3. 对授权做同样的事。挑一个高风险操作（查看他人数据、更新角色、导出、删除），把权限决策一直追溯到数据库查询层面。
4. 追踪用户输入到汇聚点。把一个参数从请求追到 SQL/ORM 查询、模板渲染、命令执行、URL 获取（SSRF）、重定向和文件路径。
5. 在追踪过程中扫描密钥和配置流。寻找日志、客户端代码、错误信息、环境转储和弱存储模式中的令牌。

一个有用的习惯：对每个“看起来没问题”的地方，写出你会如何破坏它。如果你不能描述破坏尝试，说明你可能还没验证透彻。

认证（Authn）抽查：证明用户是谁

认证是应用决定“这个请求属于这个人”的地方。快速抽查不是读每一行代码，而是找到建立身份的位置，然后检查捷径和失败路径。

定位信任边界：身份首次被创建或接受的地方。这可能是会话 Cookie、JWT Bearer 令牌、API key，或边缘处的 mTLS。让 Claude Code 指出把“匿名”变为用户 ID 的确切文件和函数，并列出所有可以达到相同效果的其它路径。

值得检查的认证点：

• 标识所有认证入口（网页登录、API 令牌、移动端认证、内部服务认证），并确认它们是否在一个一致的身份模型上汇合。
• 检查登录和密码重置的速率限制、封锁机制和用户枚举（存在与否的错误信息或时间差异）。
• 检查会话和 Cookie：HttpOnly、Secure、SameSite、过期、登录或权限变更时的轮换、以及登出是否在服务器端使会话失效（而不是仅“删除 cookie”）。
• 审查 MFA 与恢复流程，确保恢复路径不会比 MFA 本身更弱（例如仅通过邮箱重置而绕过 MFA）。
• 审查认证失败的日志：对运营有用，但不要泄露帮助攻击者的信息（不要有“用户存在”提示、不要记录令牌）。

一个实用示例：如果重置邮件返回“账号未找到”，那就是快速枚举问题。即使错误消息通用，时延差异也能泄露同样的信息，因此也要抽查响应时延。

授权（Authz）抽查：证明用户被允许

授权错误往往造成最大的损害："这个用户是否被允许在特定资源上执行该操作？" 快速抽查应有意尝试突破该假设。

用通俗话写出角色和权限，保持可读：

• 所有者可邀请成员
• 成员可以编辑自己的个人资料
• 客户支持可查看账单详情但不能更改套餐
• 管理员可以删除项目

然后验证每个敏感操作是否在服务器端强制执行授权，而不仅仅在 UI 中隐藏。按钮可以隐藏、客户端可以阻止路由，但攻击者仍能直接调用 API。

通常能发现真实问题的快速扫描包括：

• 找出创建、删除、导出、变更角色或访问账单的端点/变异
• 对每个端点，定位服务端的权限检查（不是前端）
• 查找用户可控的 ID（projectId、userId、orgId）并确认所有权检查
• 确认仅管理员路径在缺少角色时是“失败封闭”的
• 检查租户边界：orgId/accountId 应来自会话上下文，而不仅是请求输入

典型的 IDOR 气味很简单：像 GET /projects/{id} 这样的请求，其中 {id} 由用户控制，服务器加载它却未验证它是否属于当前用户或租户。

一个能强迫出真正答案的提示：

“针对这个端点，展示决定访问的确切代码，并列出允许不同 orgId 的用户访问它的具体条件。如果没有，给出原因并指明文件和函数名称。”

输入校验：尽早阻止坏数据

大多数快速 Web 应用问题都源于一个缺口：应用接受了开发者没有预料到的输入。把“输入”视为任何用户或其他系统可影响的东西，即使看起来无害。

首先列出你正在抽查的端点的输入：

• URL 查询和路径值
• 请求体字段（包括嵌套 JSON）
• 头部（认证头、内容类型、转发 IP）
• Cookies
• 文件上传（名称、大小、类型、元数据）

验证应该尽可能靠近数据进入应用的边界进行，而不是深埋在业务逻辑深处。检查基础项：类型（字符串或数字）、最大长度、必需与否，以及格式（邮箱、UUID、日期）。

对于已知值（角色、状态字段或排序方向），优先使用允许列表。它比“屏蔽若干坏值”更难被绕过。

还要检查错误处理。如果应用拒绝输入，不要在响应、日志或 UI 中回显原始值。这是小校验漏洞演变成数据泄露或注入辅助工具的方式。

针对高风险端点（登录、搜索、上传、管理员操作）的一份快速“坏输入”迷你计划：

• 过长字符串（例如 10,000+ 字符）
• 错误类型（数组替代字符串）
• 意外的枚举值
• 可能改变含义的特殊字符
• 必需字段的空值

示例：接受任意字符串的排序参数可能会在后续变成 SQL 片段。像 “date” 或 “price” 的允许列表能在早期防止这类错误。

常见注入面：快速扫描目标

快速审查通常在同几个地方发现问题：任何将用户输入解释为代码、查询、路径或 URL 的地方。这里是你要搜寻“输入越过信任边界”的位置。

把数据从入口点（查询参数、头、Cookie、上传、管理员表单）追到最终使用点。

快速扫描目标：

• SQL 注入：字符串拼接的查询、动态 ORDER BY、以及通过拼接用户值构造的 IN (...) 构造器
• XSS：HTML 渲染、模板、markdown 预览、富文本编辑器里假设“后续再清理”的场景
• 命令注入：围绕图片处理、PDF 工具、备份或使用 convert 之类工具的 shell 调用，传入的用户控制参数
• SSRF：用于 Webhook、链接预览、从 URL 导入功能以及接受用户 URL 的内部状态检查的 URL 获取器
• 路径遍历：文件下载端点、ZIP 解压以及上传管道中按名称读取文件的流程

还要注意反序列化和模板注入。任何解析用户提供的 JSON、YAML 或模板字符串的功能都可能隐藏风险，尤其是当它们支持自定义类型、表达式或服务端渲染时。

如果功能接受 URL、文件名或格式化文本，默认假设其可被滥用，直到你能用代码路径和测试证明否则。

密钥/凭证处理：查找泄露和弱存储

密钥问题通常一旦知道查找位置就很明显。聚焦密钥的存放位置和它们被意外复制的地方。

密钥常出现的地方：

• 环境变量和应用配置文件
• CI 输出和构建日志（包括失败的部署日志）
• 客户端打包和移动构建（任何会分发给用户的内容）
• 调试端点、健康页和管理员工具
• 错误页面、堆栈跟踪和分析事件

然后要求一个具体答案：如果某个密钥今天被泄露，会发生什么？一个好的系统有轮换路径（签发新密钥）、撤销（禁用旧密钥）和快速重新部署的办法。如果回答是“我们之后会改”，那就把它当作一个问题记录。

最小特权也是一个快速改进点。问题会因为密钥权限过大而恶化。查找能 DROP 表的数据库用户、能管理账户的第三方令牌或在环境间共享的 API key。倾向于每个服务、每个环境使用独立且权限最小的密钥。

可快速粘贴进 Claude Code 的检查提示：

• “查找硬编码的令牌、密码和私钥。列出精确文件路径和匹配的字符串模式。”
• “找出任何记录请求头、cookies、环境变量或完整错误对象的代码。展示日志行以及可能出现的敏感字段。”
• “检查密钥是否可能出现在快照、导出或构建产物中。识别被捕获的内容以及它们的存储位置。”

最后，确认防护措施：阻止将密钥提交到源代码（pre-commit/CI 检查），并确保备份或快照不包含明文凭证。如果平台支持快照与回滚，验证密钥是在运行时注入，而不是烘焙进已保存的镜像。

强迫给出具体发现的提示（可复制粘贴模式）

含糊的提示会得到含糊的答案。强迫模型承诺给出证据：精确位置、可追踪的路径、可运行的复现以及能证明该结论错误的条件。

一次只用一个模式，然后在你确认或拒绝细节后要求修订。

• 文件级证据：“在仓库中搜索 auth、sessions、tokens 和 middleware。命名确切的文件、函数和行范围。引用相关代码片段。如果无法指出代码，回答 ‘未找到证据’。”
• 从输入到汇聚点的追踪：“挑一个用户可控输入（头、查询、体、cookie）。逐步展示数据流从入口到被使用的地方（SQL、HTML、shell、模板、重定向、文件路径）。列出链中的每个函数。”
• 复现步骤：“给出最小复现的 curl 示例（方法、URL 形式、头、体）。包括预期状态码和成功/失败响应示例。说明假设（角色、认证状态）。”
• 控制误报：“有什么能证伪这一发现？列出 2–3 项检查：配置标志、中间件顺序、允许列表验证、参数化查询、框架的转义。如果存在，解释风险为何变化。”
• 最小安全修复 + 测试：“提出阻止该问题的最小变更且不破坏合法用例。然后写一个要新增的测试（名称、意图、输入、期望结果）。如果有权衡，说明它们。”

如果输出仍然模糊，逼近问题：

“仅回答：文件路径、函数名、有风险的行，以及一句话的影响描述。”

一个现实的例子：把直觉变成已验证的问题

个人资料更新端点常常隐藏访问控制漏洞。这里给出一个小案例，按本清单走一遍。

场景：一个 API 端点更新用户资料：

PATCH /api/profile?accountId=123，请求体如 { "displayName": "Sam" }。

你要求 Claude Code 找到处理器、追踪 accountId 的用途，并证明服务器是否强制执行所有权检查。

常见发现：

• 认证（Authn）： 请求需要会话或令牌，表面上受保护。
• 授权（Authz）： 处理器信任查询字符串中的 accountId，并在未校验其与登录用户匹配的情况下更新该账户。
• 输入校验： displayName 被修剪，但 accountId 未被验证为整数。
• 注入面： SQL 使用字符串拼接构建，如 "... WHERE account_id=" + accountId。

一个好的报告要具体：

• 严重性： 高（IDOR + 可能的 SQL 注入）
• 证据： 使用有效登录的请求修改了另一用户；SQL 从不可信输入构建
• 修复： 忽略客户端的 accountId，服务器端使用认证用户的 account id；参数化查询
• 测试： 尝试更新其他账户并期望 403；拒绝非数字的 accountId

修补后快速复查：

• 用不同的 accountId 重试相同请求并确认失败。
• 确认日志显示服务器使用经过认证的 id，而不是查询参数。
• 确认查询使用占位符/参数而不是字符串拼接。
• 运行一个针对畸形输入（字母、超大数字）的负面测试。

会让抽查错过真实问题的常见陷阱

最快错过漏洞的方法是信任 UI 的防护。按钮被隐藏或禁用并不等于权限检查。如果服务器仍然接受请求，任何人都能通过替换用户 ID、更改角色或直接调用 API 来重放请求。

另一个常见遗漏是目标过于模糊。“做一个安全审查”通常会得到通用报告。抽查需要严格范围（哪些端点、哪些角色、哪些数据）和严格的输出格式（文件名、函数、有风险的行、最小复现）。

同样规则适用于 AI 输出：不要接受没有指向的声明。如果发现没有包含具体代码位置和触发步骤，把它视为未经证实。

抽查偏离轨道的常见方式

这些陷阱经常重复出现：

• 因为是管理员页面就假设“仅管理员”，而不是因为服务器强制检查
• 要求广泛审查而不是“给我能绕过 X 的精确请求”
• 接受“可能的 SQL 注入”却没有指出查询构造点和输入路径
• 跳过不太明显的入口点，如 Webhook、定时任务、导入工具和内部管理员操作
• 修补表面症状（添加过滤或正则）而根因是缺少验证或缺少授权

如果你发现自己不断为每个新场景添加过滤器，请停下来。修复通常更早且更简单：在边界处校验输入，并使授权检查显式且集中，这样每条代码路径都能使用它们。

出货前你可以做的快速检查

这些不能替代全面审查，但能捕捉疲惫时常出现的错误。保持聚焦于你能快速证明的事项：一次可发送的请求、可加载的页面或可找到的日志行。

五项常见且高收益的快速检查：

• 认证摩擦： 连续尝试 10 次错误登录。是否看到速率限制、封锁或至少减速？能否从错误信息或时延判断某个邮箱是否存在？
• 通过 ID 替换测试授权： 选取一个真实资源（订单、发票、个人资料）。修改 URL、JSON 体或 GraphQL 变量中的 ID。你是否能看到不属于你的数据，哪怕只是元数据？
• 输入把关： 针对关键字段（邮箱、姓名、搜索、文件上传），尝试超长字符串、奇怪的 Unicode 和意外类型（数字代替字符串）。是否对长度和允许值有要求？
• 密钥泄露： 在最近的日志和客户端包中搜索令牌、API key、JWT 或 "Authorization: Bearer"。也检查错误页面。“只在预发环境”常常变成“随发布一起上线”。
• 注入面： 查找向 SQL、过滤器、模板渲染、shell 命令或重定向 URL 做字符串拼接的代码。如果输入在没有严格校验的情况下到达这些位置，就假定存在风险直到被证明安全。

写下你本周能上线的三个修复，不要列愿望清单。例如：（1）为登录和密码重置添加速率限制；（2）在 “按 id 获取” 端点强制服务器端所有权检查；（3）限制输入长度并为搜索字段拒绝意外字符。

后续步骤：把此清单作为构建流程的一部分

只有当发现能改变出货内容时，抽查才有价值。把此检查表作为一个小而可重复的构建步骤，而不是一次性的救火行动。

把每个发现转成一个明确的待办事项：

• 修复：代码或配置会发生的改动
• 测试：如何证明已修复（一个请求、一个单元测试、一个 QA 步骤）
• 负责人：一个明确负责的人
• 目标日期：下个发布或具体某天
• 证据：显示问题的文件/端点以及精确请求或载荷

选择与你的风险和团队规模匹配的节奏。对许多团队而言，每次发布都做一次是最理想的。如果发布频繁，可每月做一次 30–60 分钟的审查，并在发版前做更短的检查。

通过创建可复用的提示包和检查表模板来简化重复操作。保持提示聚焦于具体输出：展示路由、保护、失败的请求和预期行为。把提示包存放在团队常用的工作区，避免被跳过。

如果你通过聊天构建应用，把检查表内嵌到规划阶段。在第一次可用版本完成后，添加一段简短的“安全假设”说明（认证/授权、输入、密钥），然后立即运行抽查。

像 Koder.ai（koder.ai）这样的平台非常适合这种习惯，因为它们允许你在保留审查检查点的同时快速迭代。围绕高风险更改使用快照和回滚，可以让你在修复安全问题时更容易上线，而不会在修复导致行为异常时卡住。