FixVibe

// docs / security guides / pre-ship checklist

Vibe coding 安全檢查清單：上線前 44 項

針對使用 Cursor、Claude Code、Lovable、Bolt、v0、Replit 和 Windsurf 建立的應用程式的實用的、分階段組織的清單。每個項目都可以在五分鐘內完成。在投入生產之前運行它，然後在每個主要版本之前再次運行它。專案分為七個類別——秘密、資料庫、身份驗證、標頭、第三方、部署、監控——並標記有它們適用的部署階段。

PRE = 預先部署（審核您的來源）。 DEPLOY = 部署時。 POST = 部署後驗證。相關項目參考FixVibe 檢查category.check-id 表單中的ID。

秘密和API金鑰（8項）

硬編碼按鍵是振動編碼應用程式中最常見的現象。八項措施可將其拒於門外：

  1. PRE — Audit NEXT_PUBLIC_ env vars. 任何以 NEXT_PUBLIC_ 為前綴的內容都包含在客戶端捆綁包中。如果其中一個是 Supabase service_role 金鑰（解碼為 JWT 和 "role":"service_role"），請將其刪除並透過僅伺服器用戶端（src/lib/supabase/service.ts 和 import 'server-only'）進行路由。
  2. PRE — Grep for hardcoded provider keys. 搜尋 sk_live_、pk_live_、STRIPE_SECRET、sk-ant-、sk-、AIza、AKIA 和 JWT- 尋找字串 (eyJ) 的來源。將每個命中移至 .env.local 並僅透過 process.env.* 伺服器端進行引用。
  3. PRE — Verify .gitignore. 確認.env*.local、.npmrc、.yarnrc，且任何特定於提供者的憑證檔案都將被忽略。透過您的提供者模式運行 git ls-files 以查找已提交的任何內容。
  4. PRE — Scan the built bundle. 運行 npm run build，然後 grep .next/static 和相同模式的任何 dist/ 輸出。如果密鑰到達捆綁包，則開發人員永遠不會進行乾淨的環境分離。
  5. DEPLOY — Set secrets per environment. Vercel：設定→環境變量，每個變數的範圍為Pro歸納/預覽/開發。切勿與預覽環境共用sk_live_*。使用Vercel 的加密環境變數存儲，而不是內聯工作流程機密。
  6. DEPLOY — Disable build-log secret echo. 建置期間的一些 CI 配置 echo 環境變數。審核您的vercel.json、GitHub 操作工作流程或Cloudflare 頁面設置，以查找任何會將值推送到公共建置日誌中的echo $SECRET。
  7. POST — Run a passive scan. FixVibe 的Free 層涵蓋了這一點：貼上部署的URL，等待約20 秒，查找secrets.* 結果。 secrets.browser-storage 檢查捕獲因誤用SDK 而落在localStorage 或sessionStorage 中的鍵。
  8. POST — Rotate any key that ever shipped. 如果金鑰在公共捆綁包中存在甚至幾分鐘，則將其視為已洩露。透過儀表板輪換 Supabase 服務角色金鑰，重新產生 Stripe 受限金鑰，透過控制臺撤銷 Anthropic / OpenAI / Google 金鑰。

資料庫存取控制：RLS和Firestore規則（6項）

BaaS 預設值是有意允許的，因此第一個教學有效。 Pro歸納需要明確的政策。

  1. PRE — Force RLS on every public.* table. 在Supabase：每張表必須有ALTER TABLE ... ENABLE ROW LEVEL SECURITY 和FORCE ROW LEVEL SECURITY。 Force 很重要：沒有它，Postgres 會繞過表所有者的RLS。
  2. PRE — Write a policy per (table, role, action). 最小值：加入auth.uid() 的SELECT 策略。更好：單獨的INSERT / UPDATE / DELETE 策略，這樣UPDATE 就無法偷偷引入user_id 重新路由所有權的變更。
  3. PRE — Replace default Firebase rules. 預設測試模式規則為allow read, write: if true;。替換為每個集合的身份驗證綁定規則：match /users/{userId} 與 allow read, write: if request.auth.uid == userId;
  4. PRE — Lint migrations in CI. 在合併之前執行 supabase db lint 或等效命令。如果任何CREATE TABLE public.* 缺少符合的RLS 策略，CI 應該會使建置失敗。
  5. DEPLOY — Confirm RLS survived deploy. 部署後重新檢查Supabase Studio：表 → 每行 → RLS 切換為 ON。 Pro歸納資料庫遷移有時會領先策略文件；驗證該政策是否有效。
  6. POST — Run an active scan against a verified domain. baas.supabase-rls 主動檢查使用匿名鍵入一個微小的種子行，並報告寫入是否成功 - i.e。 RLS實際上並沒有強制執行。

身份驗證和會話（7 項）

AI-編碼應用程式中的身份驗證錯誤往往很微妙：令牌驗證中的一對一偏差、丟失HttpOnly標誌、getSession()（本應有getUser()）。

  1. PRE — Replace getSession() with getUser(). getSession() 讀取cookie並信任它；getUser() 與 Supabase 後端進行驗證。在伺服器路由上始終使用getUser()。
  2. PRE — Confirm token expiry. Magic-link、密碼重設和電子郵件驗證令牌需要伺服器強制過期。預設Supabase 魔法連結會在 1 小時後過期——如果沒有真正的原因，請勿將其覆蓋為更高的數字。
  3. PRE — Verify JWT aud and exp. 如果您在任何地方手動解碼令牌，請檢查這兩個聲明。更好：使用 SDK 的 getUser() 來為你做這件事。
  4. PRE — Audit cookie flags. 自訂會話 cookie 應為Secure; HttpOnly; SameSite=Lax（或Strict 對於非OAuth 串流）。 localStorage 沒有課程材料。
  5. PRE — Validate the next redirect param. 登入後的next 查詢參數必須以/ 開頭，而不是//（開啟重定向至attacker.example）。拒絕伺服器端的任何其他內容。
  6. POST — Test logout. 登入、登出、檢查 cookie（DevTools → 應用程式 → Cookies）。必須在相同回應中清除會話 cookie。如果它持續存在，則註銷處理程序實際上並未破壞伺服器端狀態。
  7. POST — Active probe. active.auth-flow 和 active.account-enumeration 檢查表面破壞的身份驗證邊界 - 對「使用者存在」與「錯誤密碼」的不同回應、缺少登入速率限制、未簽署的重設令牌。

HTTP 安全標頭與內容安全策略（6 項）

標頭是整個管道中最便宜的強化，也是程式碼產生器最常跳過的。

  1. PRE — Ship a real CSP. 最小值：script-src 'nonce-{NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'。 script-src 中沒有'unsafe-inline'。當中間件設定 x-nonce 請求標頭時，Next.js 會自動套用隨機數。
  2. PRE — Add the legacy three. X-Content-Type-Options: nosniff、X-Frame-Options: DENY（或單獨依賴CSP frame-ancestors）、Strict-Transport-Security: max-age=31536000; includeSubDomains。
  3. PRE — Tighten Referrer-Policy. 預設strict-origin-when-cross-origin 適用於大多數應用程式。不要發送 unsafe-url 或根本不發送標頭。
  4. PRE — Replace Access-Control-Allow-Origin: *. Grep 查找它。替換為明確的來源允許列表。無論* 與credentials: include 在一起，瀏覽器都會拒絕該請求——但這並不能防止後端配置錯誤。
  5. DEPLOY — Verify headers post-deploy. 開啟 DevTools → 網路 → 點選根文檔 → Headers 標籤。 CSP、HSTS、X-Frame-Options、X-Content-Type-Options 應存在。 CSP 不得在script-src 中包含'unsafe-inline'。
  6. POST — Run headers.security-headers. 被動標頭檢查透過部署平臺修復指南報告每個遺失的標頭（Vercel vercel.json、Cloudflare 頁_headers、Netlify _headers、Next.js 中間件）。

第三方整合和APIs（5 項）

您包含的每個腳本都是CSP 豁免和潛在的供應鏈表面。將第三方視為您信任邊界的一部分。

  1. PRE — Reverse-proxy analytics where possible. PostHog、Plausible、Umami 都支援透過您自己的網域進行代理（e.g。/api/posthog）。這使 connect-src 保持在同一來源並免受廣告攔截器的影響。
  2. PRE — CSP-allowlist the rest. 對於 Google Analytics、Stripe.js、Sentry、Intercom、GTM 等，將每個供應商的來源添加到匹配的 CSP 指令中（script-src 用於加載程序，connect-src 用於遙測，frame-src 用於 iframe，img-src 用於像素）。
  3. PRE — Use Stripe Checkout, not raw card forms. Stripe Checkout 是頂級重定向；該腳本不需要 CSP 條目。託管PCI 表面完全位於Stripe 的網域中。僅當您有充分的理由時才自行推出。
  4. PRE — Lock package-lock.json in CI. 在生產版本中運行npm ci（不是npm install）。在每次發布之前使用 npm audit 或 Snyk 審核依賴關係。
  5. POST — Watch discovery.tech-fingerprint. 被動技術堆疊發現顯示爬蟲可見的庫版本。如果您發布 EOL React、jQuery 或 Bootstrap，FixVibe 會標記並連結到已知的 CVE。

部署衛生和基礎設施（8 項）

部署方式與部署內容同等重要。 AI-編碼的應用程式尤其受益於明確部署強化。

  1. PRE — Disable x-powered-by. 在next.config.js：poweredByHeader: false。刪除免費版本公開訊號。
  2. PRE — Confirm middleware lives at src/middleware.ts. 對於src/ 目錄佈局，Next.js 會忽略根級別middleware.ts。錯誤放置的中間件無法設定 CSP / 身份驗證標頭 / 速率限制。
  3. PRE — Sanity-check Vercel deployment protection. Pro歸納應是公開的；預覽應受密碼保護或僅限於組織成員。 discovery.platform-vercel 報告表面。
  4. PRE — Block dotfile and config probes at the edge. 為/.env、/.git/*、/.aws/*、/.next/trace 模式新增重寫或拒絕規則。預設情況下，Vercel 對其中許多返回 403；交叉檢查。
  5. DEPLOY — Separate environments. Pro歸納、預覽、開發。每個人都有自己的一套秘密。實時鍵永遠不會達到預覽，Stripe測試模式永遠不會達到Pro歸納。
  6. DEPLOY — Enable Vercel Web Application Firewall. Pro 和企業計劃包括帶有託管規則的WAF。 Cloudflare Pages 有機器人戰鬥模式。兩者都減少了自動掃描器的濫用和密碼噴射負載。
  7. POST — Verify TLS configuration. SSL 實驗室或 testssl.sh 針對您的生產域。 TLS 最低 1.2，首選 TLS 1.3，無弱密碼，HSTS 預先載入合格。
  8. POST — Confirm health-check endpoints are minimal. /api/health 應該返回沒有主體的200 OK。不要在未經身份驗證的情況下回顯環境、建置雜湊或部署時間戳記。

持續監控和重新掃描（4 項）

安全不是一次性的裝船前審核。每次部署都會發生漂移。

  1. Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT 或 HTTP 檔案驗證。這可以解鎖計劃的重新掃描、主動探測和即時威脅監控。
  2. Schedule passive re-scans. Pro 計劃支援 3 小時節奏; Unlimited 支援 6 小時節奏。每次顯示新發現的計劃掃描都會觸發一封電子郵件（如果您已連接，也會觸發網路鉤子）。
  3. Wire outbound webhooks. Account → Webhooks → 新增HTTPS端點，訂閱scan.completed + finding.created + scan.active_api.first_used。路由到 Slack / Discord / PagerDuty。
  4. Enable live threat monitoring on Unlimited. 證書透明度日誌差異、DNS 更改、JS 捆綁秘密洩露、威脅情報列表 — 在檢測到它們時立即觸發，而不是在下一次計劃掃描時觸發。

後續步驟

想要了解這些計畫為何重要的教育背景嗎？閱讀AI-generated code security scanning。想要每個強化步驟的具體程式碼片段嗎？請參閱How to secure an app built with AI coding tools。

// scan your app

別再讀了，去找你應用裡的漏洞。

插入 URL — FixVibe 在不到一分鐘的時間內執行本指南中的每項被動檢查以及 200 多項其他檢查。 Free，無需安裝，無卡片。

  • Free 層 — 每月 3 次掃描，無卡片。
  • 針對任何 URL 進行被動掃描 — 無需網域驗證。
  • 針對 Cursor、Claude Code、Lovable、Bolt、v0、Replit 進行了調整。
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
執行免費掃描 →

無需註冊

Vibe coding 安全檢查清單：上線前 44 項 — Docs · FixVibe