// docs / security guides / cursor checklist
Cursor 安全检查清单：上线前 28 项
用Cursor 构建？ Cursor 的自动完成、Composer 模式和代理功能非常强大，并且会创建可预测的安全盲点。此清单针对 Cursor 特定模式：服务角色密钥内联、Composer 生成的未经审查的整个文件、代理模式终端命令以及作为您的第一个安全防护栏的 <code>.cursorrules</code> 文件。涉及机密、数据库、身份验证、标头、部署和 Cursor 特定陷阱的 28 个项目。
PRE = 预部署（审核您的源）。 DEPLOY = 在部署时。 POST = 部署后验证。相关项目参考FixVibe 检查category.check-id 表单中的ID。
秘密和 API 密钥（5 项）
Cursor 的自动完成功能是在秘密很常见的开源代码上进行训练的。该模型会自由地建议它们，尤其是在身份验证尝试失败之后。
- PRE — Write security rules into
.cursorrules. 添加一行：“切勿将SUPABASE_SERVICE_ROLE_KEY、sk_live_*或任何以提供程序首字母缩略词开头的环境变量内联到客户端代码中。始终使用仅服务器导入。” Cursor 读取.cursorrules并将其纳入每个建议中。 - PRE — Audit Composer-generated files. 当Cursor 的 Composer 创建整个文件（尤其是身份验证处理程序）时，逐行检查它。 Composer 有时会内联应仅用于服务器的环境变量。在组件导入中查找
NEXT_PUBLIC_或对服务键的直接引用。 - PRE — Reject auto-imports of service clients into client components. 如果 Composer 将
import { supabase } from '@/lib/supabase/service'导入到 React 文件中，请立即删除它并通过 API 端点进行路由。仅服务器导入已明确标记 - 不要跳过它们。 - PRE — Scan Agent-mode commits. 代理模式运行终端命令，可以直接提交。审核
git log --oneline -20和git diff HEAD~5以确保在代理运行期间没有提交看似秘密的字符串。 - POST — Run secrets.browser-storage. 对已部署的URL 进行被动扫描。如果服务密钥出现在 JS 捆绑包中，请立即轮换它 — Cursor 的自动完成功能可能会内联它。
数据库访问控制（4项）
Composer 通常会生成有效的授权代码，但会跳过RLS——“它有效”的时刻让人们看不到缺失的策略执行。
- PRE — Force Cursor to generate migrations with RLS. 在
.cursorrules中：“每个CREATE TABLE public.*迁移必须包括ALTER TABLE ... ENABLE ROW LEVEL SECURITY和FORCE ROW LEVEL SECURITY。”然后要求 Composer 生成迁移。 - PRE — Review Composer-generated policies. Composer 有时会在不检查
auth.uid()的情况下编写策略。像allow select on public.items这样没有using子句的策略是非常危险的。需要 user_id 匹配。 - DEPLOY — Confirm
FORCE ROW LEVEL SECURITYis live. 打开Supabase Studio，检查每个表的RLS 开关。如果 Composer 的迁移有ENABLE但忘记了FORCE，表所有者（您的迁移）将绕过 RLS。这是一个真正的差距。 - POST — Run the baas.supabase-rls active check. 它尝试使用匿名键进行写入。如果成功，RLS 实际上并没有强制执行 - 可能缺少
FORCE关键字。
身份验证和会话（4 项）
Cursor 快速生成身份验证流程，但经常错过保持令牌安全的微妙服务器端验证。
- PRE — Ensure all auth routes use
getUser(). 在API 路线中搜索getSession()并替换为await supabase.auth.getUser()。getSession()读取未经验证的cookie；getUser()使用Supabase 后端进行验证。 - PRE — Check Composer auth handlers for token expiry. Magic-link 令牌需要服务器强制
expires_at。默认Supabase 为 1 小时 — 不要要求Cursor 在没有真正原因的情况下覆盖它。 - PRE — Audit the sign-in redirect guard. 登录后的
next查询参数重定向必须经过验证：必须以/开头，不能以//开头。作曲家有时会跳过这一点。如果缺少，请手动添加。 - POST — Test logout server-side state destruction. 登录、注销、检查 cookie（DevTools → 应用程序 → Cookies）。必须立即清除会话 cookie。如果它持续存在，则注销处理程序不会破坏状态。
HTTP 安全标头和CSP（3 项）
Cursor默认情况下很少生成中间件。如果您不明确询问，CSP 和 HSTS 通常不存在。
- PRE — Demand CSP in
.cursorrules. 添加：“用Content-Security-Policy生成src/middleware.ts。对script-src使用随机数，没有不安全内联。”然后要求Cursor生成它。如果没有这个提示，中间件就会被跳过。 - PRE — Verify
src/middleware.tsexists. 对于src/目录布局，Next.js 仅拾取src/middleware.ts。根级别middleware.ts会被默默忽略。如果CSP 未登陆，请检查文件是否位于正确的位置。 - POST — Run headers.security-headers. 被动扫描报告缺少 CSP、HSTS、X-Frame-Options、X-Content-Type-Options。打开报告并按照适用于您的部署平台的修复指南进行操作。
部署卫生（5 项）
Cursor 应用程序通常会落在 Vercel 上，它具有良好的默认值，但需要对 build/deploy 边界进行显式强化。
- DEPLOY — Check Vercel env-var scoping. 设置 → 环境变量 → 每个秘密的范围应仅限于Production。切勿与预览版或开发版共享
sk_live_*。 - DEPLOY — Disable build-log secret echo. 如果您的
vercel.json或GitHub 操作工作流程具有echo $SECRET，请将其删除。构建日志公开存档；日志中的秘密被泄露。 - DEPLOY — Use Vercel's managed secrets, not inline workflow vars. Vercel 的设置 → 环境变量静态加密。 GitHub Actions 的秘密总比没有好，但它是为CI 而设计的，而不是部署平台集成。
- POST — Verify CSP nonce on the deployed preview. 在浏览器中打开Vercel预览链接，打开DevTools→网络→根HTML响应。 CSP 标头必须存在，并包含
'strict-dynamic'以及每个请求的唯一随机数。 - POST — Rotate any key that ever shipped, even to Preview. 如果某个密钥到达生产捆绑包的时间哪怕只有 10 分钟，它就会遭到泄露。立即旋转。
Cursor特定陷阱（4 项）
Cursor 工作流程特有的模式会带来安全风险：
- Agent mode auto-fixes propagate old patterns. 如果您要求代理“修复身份验证错误”，它可能会多次重新生成相同的身份验证文件，每次都内联相同的服务密钥（如果它位于代码库上下文中）。先清洁原件，然后请代理商修复。
- Cursor Index leaks intent. Cursor 的
@codebase索引非常强大，但如果您的.cursor目录曾经暴露（错误配置的 S3、git 历史记录），则索引会暴露您的架构和秘密模式。将.cursor保留在本地。 - Composer mode loses context between files. Composer 生成的每个文件都是新鲜的。如果您要求它生成客户端文件，然后生成 API 路由，它们可能会使用不同的 Supabase 客户端配置。检查两者并确保它们符合您的架构。
- Autocomplete bias toward "working" over "secure". Cursor 建议传递当前上下文的最快代码。如果您的测试有
NEXT_PUBLIC_SERVICE_KEY，自动完成功能会记住它并重新建议它。在与模型共享代码之前清理测试装置。
后续步骤
一旦锁定了 Cursor 特定模式，请对照 general vibe coding security checklist（44 项）和 step-by-step hardening 进行交叉检查。如果您正在混合工具，另请参阅Claude Code checklist。