// 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。