FixVibe

// docs / security guides / pre-ship checklist

Vibe coding 安全檢查清單:上線前 51 項

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

PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

秘密和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 in JavaScript Bundles 檢查捕獲因誤用SDK 而落在localStorage 或sessionStorage 中的鍵。
  8. POST — Rotate any key that ever shipped. 如果金鑰在公共捆綁包中存在甚至幾分鐘,則將其視為已洩露。透過儀表板輪換 Supabase 服務角色金鑰,重新產生 Stripe 受限金鑰,透過控制臺撤銷 Anthropic / OpenAI / Google 金鑰。

資料庫存取控制:RLS和Firestore規則(6項)

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

  1. PRE — Enable RLS on every public.* table. In Supabase: each table needs ALTER TABLE ... ENABLE ROW LEVEL SECURITY plus explicit policies for each role. RLS is what stops the anon and authenticated API roles; FORCE ROW LEVEL SECURITY only extends it to the table owner and is optional defence in depth.
  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. Supabase Row-Level Security 主動檢查使用匿名鍵入一個微小的種子行,並報告寫入是否成功 - 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. Auth Flow Defects 和 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 HTTP 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 Technology Fingerprinting. 被動技術堆疊發現顯示爬蟲可見的庫版本。如果您發布 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歸納應是公開的;預覽應受密碼保護或僅限於組織成員。 Vercel-Specific Exposure 報告表面。
  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 or HTTP file verification. Active scans require Hobby or above, scheduled scans require Pro or Unlimited, and live threat monitoring requires Unlimited.
  2. Schedule passive re-scans on Pro or Unlimited. Choose an available cadence for your verified domain. Scheduled runs share your scan allowance; enable completion notifications and signed webhooks as needed. A scheduled scan observes the app at run time, not continuously.
  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. Periodic certificate, DNS, bundle, and threat-intelligence checks can surface changes between scheduled scans. Coverage and alert timing depend on the signal and successful polling.

Replit Agent

If you build with Replit Agent, also check:

  1. Don't paste keys into the Agent prompt. Add them in Secrets and give the Agent the variable name instead, so the value never appears in generated code or chat history.
  2. Test CORS on the production domain. The preview pane and your deployed URL are different origins. Check your CORS allowlist against the domain users actually load.
  3. Replit Agent sometimes hardcodes test values. 代理程式可能會產生具有API_URL = 'http://localhost:5000</code> 的程式碼。發貨前,替換為<code>os.environ[API_URL']。

Firebase Studio

If you build with Firebase Studio, also check:

  1. Test-mode rules are temporary by intent, not by default. Test mode lets anyone read and overwrite data. If the generated rule carries a date cutoff, client access stops on that date; if not, the database stays open. Replace test rules before launch either way.
  2. Security rules protect data, not Hosting. Firestore and Storage rules don't govern what Firebase Hosting serves: everything in the public directory is public. Keep exports, backups and admin pages out of it.

Claude Code

If you build with Claude Code, also check:

  1. PRE — Keep personal Claude Code settings out of git. Commit .claude/settings.json for shared project settings, but keep .claude/settings.local.json out of the repo: Claude Code excludes it from git when it creates the file, so check it if you created it by hand. Session history lives in ~/.claude, outside the project (Claude Code docs).
  2. Bash operations are unverified. Claude Code 直接執行bash指令。 git commit -m "fix" 很方便,但如果工作目錄有一個 .env 檔案並且 glob 包含它,它就會提交。始終在Claude Code 提交之前檢查git diff --cached。

後續步驟

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

// scan your app

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

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • 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 安全檢查清單:上線前 51 項 · FixVibe