secure

安全

对代码库执行安全审计，并优先修复最重要的问题。AI 构建的应用往往会在几个可预见的方面出错。检查这些方面，证明每项发现，并予以修复。

步骤 1：梳理应用

阅读代码并简要列出：

• 框架，以及服务器代码的运行位置
• 数据库，以及浏览器是否会直接与其通信
• 用户的登录方式
• 所有 API 路由、服务器操作和 webhook 端点
• 应用使用的所有第三方密钥
• 所有会产生费用的调用：AI 模型、电子邮件、短信

步骤 2：按潜在损失从大到小执行检查

1. 密钥

• 搜索代码和 git 历史记录中的密钥与密码。
• 检查 .env 文件是否已加入 .gitignore。
• 列出所有会传到浏览器的环境变量。大多数框架会用公开前缀标记这些变量。其中不得包含任何密钥。
• 绕过访问规则的数据库密钥（管理员密钥或服务密钥）绝不能传到浏览器。
• 曾经提交过的密钥必须轮换。删除文件并不会将其从 git 历史记录中移除。

2. 数据隔离：客户绝不能看到其他客户的数据

• 每个返回客户数据的查询都必须在服务器端按已登录用户或账户进行筛选。
• 如果浏览器会直接查询数据库，数据库自身的访问规则必须覆盖每张表的读取、创建、更新和删除操作。
• **验证这一点：**创建两个账户。以账户 A 的身份，通过修改 URL 或 API 调用中的 ID，请求账户 B 的一条记录。请求必须失败。这是 AI 构建的应用中危害最大的问题，在正常使用中却无法察觉。

3. 每条路由都要验证身份

• 每条路由和服务器操作都要检查用户是否已登录。
• 每条路由和服务器操作都要检查用户是否拥有其操作的对象。
• 管理员页面必须在服务器端检查用户的角色。隐藏链接并不能提供保护。

4. 付款和 webhook

• webhook 端点必须先验证签名，再执行操作。
• 付费访问权限必须通过已验证的 webhook 授予，绝不能依赖浏览器加载的“感谢”页面（参见 付款）。

5. 滥用和成本

• 对登录、注册、密码重置以及所有会产生费用的端点实施速率限制。
• 为每位用户的 AI 调用设置每日上限，并在 AI 提供商处设置支出限额或提醒。只需一个脚本攻击未设防的 AI 端点，一夜之间产生的费用就可能超过企业一个月的收入。

6. 输入和输出

• 在服务器端验证输入。
• 使用参数化查询或 ORM，绝不要使用用户输入拼接字符串。
• 绝不要将用户输入作为原始 HTML 渲染。
• 检查上传文件的类型和大小。

7. 依赖项 运行包管理器的审计命令，并修复高危和严重问题。

8. 错误和日志

• 绝不能向用户显示堆栈跟踪。
• 日志中绝不能包含密码、令牌、卡号，也不得包含超出所需范围的个人数据。

步骤 3：受监管数据检查关卡

如果应用存储健康记录、金融账户数据、儿童数据或学生记录，请暂停并明确告知创始人：这类数据受特殊规则约束。例如，美国健康数据要求与每家存储该数据的托管服务商签署协议。建议在发布前由专家进行审查。此检查清单不足以保障这类数据的安全。

步骤 4：修复

经创始人批准后，立即修复严重问题。每次修复后，重新运行发现该问题的检查。用通俗语言列出其余问题，并说明各自的风险。

规则

• **报告前，先验证每项发现。**没有证据的发现会浪费创始人的时间，还会让他们学会忽视你。
• **使用知名的身份验证库或服务。**绝不要从头实现密码存储或会话管理。
• **暂不处理：**付费渗透测试（等到涉及敏感数据或用户数达到约 1,000 人时再做）、单点登录（等客户提出需求时再做）或 Web 应用防火墙（托管服务商已覆盖基础防护）。

输出

| Severity | Finding | Where (file:line) | Proof | Fix | Status |

严重程度：严重（数据或资金可能立即泄露）、高（很可能遭到利用）、低（方便时修复）。最后用一句话说明该应用是否适合面向付费客户。