为何 AI 编程工具会留下安全漏洞

为什么AI-生成的代码在安全性方面有所不同

AI 编码工具产生的安全漏洞有其结构性原因。它们不是随机的疏忽；而是。它们是训练和优化的可预测产物。

• Training data skews toward "make it work." 开源存储库和教程主导LLM 培训。中间的 OSS 存储库是为了解决问题而编写的，而不是作为安全强化的典范。 LLM 学习的是野外代码的分发，而不是安全代码的分发。
• Autocomplete is sticky. 当您粘贴使用service_role 键的代码片段时，它将成为下一个文件的模板。 Cursor 的自动完成功能将在它不属于的客户端组件中建议它。该工具正在执行其优化的操作（速度），但它不知道安全边界。
• No long-term context or incident memory. 一位人类开发人员因缺少 WHERE 子句而烧毁了生产数据库，并将这一教训延续了多年。 LLM没有情景记忆。每个文件都是一个新的开始。该工具不会从您上次的RLS绕过或您团队的事件事后分析中学习。
• Speed is the rewarded metric. 开发人员选择这些工具是因为它们交付速度快。延迟反馈是即时且直接的。安全反馈缺失或延迟——发货三周后FixVibe扫描中发现的漏洞。 LLM 针对人类实时奖励的指标进行了优化。
• Implicit trust in platform defaults. 当Cursor 生成Vercel 应用程序时，它假定Vercel 的默认设置已得到强化。其中包括：auto-HTTPS、签名 cookie、DDoS 保护。其他则不然：默认情况下没有CSP，没有HSTS，宽容CORS。生成的代码继承了并不总是合理的平台假设。

差距 1：客户端包中的秘密

服务角色 API 密钥、OAuth 令牌和私钥最终以 JavaScript 捆绑包形式发送到浏览器。 FixVibe 将这些标记为secrets.browser-storage 和secrets.bundle-leak 结果。这些密钥可以在源映射、精简代码或明文JS中发现。

Why it happens: Cursor 粘贴使用服务角色初始化客户端的Supabase 代码片段意味着代码现在处于自动完成状态。生成的 React 组件要求“从数据库获取所有项目”，Cursor 建议服务客户端导入。仅服务器代码和客户端代码之间的边界抽象为LLM。

Fix: 将机密存储在标记为 NEXT_PUBLIC_ 的环境变量中，仅用于公钥。服务密钥、API 私钥和签名密钥必须位于src/lib/secrets.ts 和import 'server-only' 中。使用服务器操作或 API 路由来调用敏感服务，而不是客户端组件。

差距 2：行级安全性缺失或不完整

Supabase 表是在未启用RLS 的情况下创建的。 Firebase Firestore 规则永远不会写入或保留在宽松测试模式下。匿名用户可以读取和写入每一行。 FixVibe 将其标记为baas.supabase-rls 和baas.firebase-rules。

Why it happens: RLS 是 Postgres 特定的功能。受过 Rails、Django、Laravel 和 Express 培训的法学硕士将应用程序层身份验证检查视为常态。在Supabase 上启用RLS 需要明确的ALTER TABLE 语句和策略定义——在训练数据中不太常见的模式。

Fix: 对于Supabase，在每个表上强制使用RLS 和ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY;。创建将行范围限定为经过身份验证的用户或组织的策略。对于Firebase，切勿将规则保留为默认测试模式；编写适用于经过身份验证的用户的显式规则。

差距 3：身份验证边界混乱

会话使用 getSession()（读取未经验证的 cookie）在客户端进行验证。魔法链接没有过期时间。 JWTs 跳过aud 和exp 检查。密码重置是可逆的。 FixVibe 将这些标记为 active.auth-flow 结果。

Why it happens: Supabase Auth、Clerk 和类似服务处理会话状态，但它们的 API 有安全和不安全模式。 getSession() 很方便，但未经验证。 LLM 在训练数据中更频繁地看到便利性API，而不是安全性。服务器端令牌验证是抽象的，需要显式的 HTTP 标头或中间件调用。

Fix: 始终使用supabase.auth.getUser() 服务器端。切勿信任受保护路由上的getSession()。验证每个请求的JWT，检查exp、aud 和签名。将访问令牌的令牌过期时间设置为 1 小时，并为较长的会话使用刷新令牌。

差距 4：缺少 HTTP 安全标头

没有Content-Security-Policy，没有X-Frame-Options，没有Strict-Transport-Security，没有X-Content-Type-Options。 FixVibe 将此标记为headers.security-headers 发现。

Why it happens: 安全标头是特定于部署平台的。 Cursor 生成Next.js 的代码；设置CSP需要next.config.js调整、中间件或vercel.json覆盖。这些不在默认的项目脚手架中。 “标题用于 DevOps”的心理模型仍然很常见。

Fix: 在next.config.js 或支持nonce 的中间件中设置CSP：Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; ...。添加HSTS：Strict-Transport-Security: max-age=31536000; includeSubDomains。对静态主机使用 Vercel 的 vercel.json 标头或中间件。

差距 5：第三方集成配置错误

Stripe 密钥、Sentry 令牌、Anthropic API 密钥是硬编码的或提交到存储库。分析起源过于宽容。 npm 依赖项已过时。 FixVibe 扫描将这些标记为discovery.tech-fingerprint 和我们的秘密检查器下的发现。

Why it happens: 集成是从文档和教程粘贴的。 LLM 复制模式，包括任何硬编码值。环境变量纪律要求 CI/CD 中的明确纪律 - LLM 无法强制执行。

Fix: 对每个第三方凭证使用环境变量。将机密存储在您的部署平台（Vercel、Netlify、Heroku 或保管库）中。每月使用 npm audit 审核 npm 依赖关系。当安全更新可用时，使用 Dependabot 或 Renovate 进行自动 PR。

修复模式

缩小这些差距并不需要从头开始重建。模式是一致的：

1. Audit: 针对您的实时应用程序运行FixVibe。对于回购扫描，启用 FixVibe GitHub 应用程序。收集结果 - 秘密、RLS、身份验证、标头、第三方。
2. 加固:修复高置信度的发现。启用 RLS + FORCE。将密钥迁移到环境变量。在中间件中设置 CSP 和 HSTS。使用服务端身份验证校验。仅在代码/配置变更适用之处使用编码代理提示,DNS 或由提供商负责的修复请遵循操作员步骤。
3. Monitor: 在已验证的域上安排每日被动扫描或每周主动扫描。设置 Slack 的 Webhook。每个关键发现都应在船舶发出后几分钟内触发警报。
4. 响应:发现出现时,复制与修复责任方匹配的 FixVibe 修复操作:代码/配置工作使用编码代理提示,DNS、提供商控制台、密钥轮换和人工审查使用操作员步骤。重新扫描以确认。

该领域的发展方向

弥补这些差距是当今团队的工作。在接下来的 2-3 年中，前沿正在发展：框架和工具中更好的默认设置（Next.js 中间件自动CSP、Supabase RLS 作为默认设置）、IDE-time 安全反馈（Cursor 当您要将服务密钥粘贴到客户端组件时发出警告的建议）以及 MCP- 驱动的自动修复（您的编码代理可以访问 FixVibe 结果并可以自主修复它们）。 FixVibe 的公共changelog 跟踪哪些差距首先缩小。

后续步骤

有关启动前的 go/no-go 检查清单，请参阅Pre-launch SaaS security checklist。有关包含代码片段和真实故障模式的分步强化演练，请阅读How to secure an app built with AI coding tools。