AI 生成程式碼的安全掃描：給 vibe-coded 應用的 DAST

為什麼AI-產生的程式碼需要不同的安全掃描

AI 編碼工具在開源儲存庫上進行了大規模培訓。此訓練資料偏向make it work 而非make it secure。由此得出一些結構模式：

• Autocomplete bias. 最接近的匹配導入獲勝。在一個檔案中貼上使用 service_role 鍵的 Supabase 片段會使該鍵成為下一個檔案中的自動完成建議 - 即使在它從未屬於的客戶端 React 元件中也是如此。
• No long-term context. LLM 不記得你上次繞過RLS 或你的團隊的事件事後分析。每個產生的文件都是新鮮的，通常缺少人類在文件中攜帶的防禦模式。
• Speed as the rewarded metric. 用戶好評速度； LLM 訓練強化了這一點。在延遲回饋訊號上，「產生最快的 Next.js 身份驗證」優於「產生最安全的 Next.js 身份驗證」。
• Training data gaps. 較舊的程式碼庫主導訓練數據，並且早於現代安全預設（嚴格CSP、SameSite=Lax、HSTS、RLS）。產生的程式碼與 2019 年正常但如今不安全的模式相呼應。
• Implicit platform trust. 當Cursor 產生Vercel 應用程式時，它假定Vercel 的預設值是安全的。有些是（auto-HTTPS，簽名cookie）。許多不是（預設沒有CSP，寬鬆的CORS，預設Next.js調試路由）。

vivi 編碼應用程式中存在過多的十個漏洞類別

在對AI-產生的應用程式進行數千次掃描時，相同的發現類別出現得不成比例：

1. Exposed Supabase service-role keys. 提交給客戶端捆綁包的service_role JWT（開始eyJ）會繞過專案上的每個RLS 策略。 Cursor 在邊界的錯誤一側自動完成它；密鑰在 /_next/static/... 中發貨。
2. Missing Row-Level Security (RLS). 模型看到CREATE TABLE public.items 並繼續，但不啟用RLS。然後，匿名用戶可以透過匿名公鑰讀取或寫入任何行。參見baas.supabase-rls。
3. Open Firebase / Firestore rules. 產生的規則檔案通常會讀取allow read, write: if true; 或完全跳過規則檔案。預設測試模式規則將在 30 天後過期並鎖定資料庫，但前提是開發人員注意到。
4. 當 env-var 規則失效時，Hardcoded API keys in bundles. Stripe 即時金鑰、Anthropic sk-ant-*、OpenAI sk-*、Google AIza* 和 AWS AKIA* 金鑰最終會內聯到 JS 有效負載中。 secrets.browser-storage 在渲染頁面層級標記它們。
5. Missing Content Security Policy. 沒有 Content-Security-Policy 回應標頭意味著每個內聯腳本 XSS 只需單擊即可完全接管帳戶。 CSP 是抽象的； codegen 通常會跳過它。 headers.security-headers 報告與部署平臺特定的修復指南之間的差距。
6. Next.js middleware misplacement. 使用src/ 佈局，Next.js 僅拾取src/middleware.ts — 根級middleware.ts 會被默默忽略。身份驗證似乎仍然有效，因為頁面呼叫requireAuth()，但標頭、CSP 和速率限制無法實現。
7. IDOR via unsigned IDs. 產生的GET /api/items/[id] 處理程序信任路徑參數，並且從不驗證所有權。遍歷整數或UUID空間會暴露每個租戶的資料。
8. Broken auth flows. 沒有 expires_at 的 Magic-link 令牌； JWT 跳過aud 和exp 的驗證；客戶端 getSession() 呼叫（讀取未經驗證的 cookie）而不是伺服器端 getUser()。
9. Debug endpoints in production. 產生/api/debug、/api/health、/api/__nextjs_original-stack-frame 或/.next/trace 路由洩漏內部。 discovery.platform-vercel 透過內容驗證來偵測它們，以避免 SPA 後備出現誤報。
10. Plaintext sensitive fields. 密碼、API 金鑰和 PII 以純文字形式儲存在 Postgres 中，因為遷移未到達 pgcrypto 或外部保管庫。

DAST 與SAST：為什麼兩者對於AI-產生的程式碼都很重要

靜態分析 (SAST) 和動態分析 (DAST) 是互補的，而非取代的。分割對於AI-產生的程式碼比手寫的程式碼更重要。

SAST 讀取磁碟上的原始碼。它在構建運行之前捕獲原始檔案中的秘密、危險的函數呼叫和危險的模式。它無法查看運行時配置、部署的環境變數或捆綁程式如何轉換程式碼。

DAST 像用戶一樣點擊已部署的應用程式。它可以查看已發送的回應，針對生產包運行，並捕獲儲存庫和部署之間的配置偏差。它在轉譯的 JavaScript 中找到 SAST 從未見過的硬編碼鍵，因為它們是在構建時透過 process.env 賦值輸入的。

For AI-generated code, DAST is essential 因為運送的內容與模型所寫的不同。捆綁、搖樹、轉譯和環境變數內聯都會創造新的表面。原始碼上的 SAST 可能會完全錯過捆綁包嵌入的秘密。 DAST 捕獲兩層。成熟的管道針對已部署的預覽在CI和DAST中運行SAST - 這就是FixVibe模式。

在 AI- 代碼掃描器中尋找什麼

大多數通用DAST掃描器（Burp Suite、OWASP ZAP、Nessus）都是為整體應用程式和傳統身分驗證流程而設計的。掃描 Vercel + Supabase + Stripe AI- 產生的應用程式需要：

• BaaS coverage. 針對Supabase RLS、Firebase / Firestore 規則、Clerk 配置、AWS Amplify 以及這些服務發出的JWT 形狀進行真實檢查。通用OWASP規則不知道要標記什麼。
• JS bundle inspection. 針對API-金鑰格式、簽名令牌和特定於提供者的模式（Stripe sk_live_、Anthropic sk-ant-、Supabase JWTs 開頭eyJ）調整了正規表示式。一般熵啟發法會引發太多誤報。
• Passive + active split. 被動檢查（標頭、cookie、秘密、BaaS 配置、DNS）針對任何 URL 安全運作。主動偵測器（SQLi、XSS、SSTI、IDOR 步行）需要授權邊界，因為它們會發射攻擊有效負載。
• Framework awareness. 識別Next.js 應用程式路由器與頁面路由器、Vite SPA 重寫、Vercel 部署保護、Cloudflare 頁面路由。無法區分 Vite SPA 後備和真實 /_next/build-manifest.json 的掃描器會產生噪音。
• Rate-limit safety. 每次掃描的有限請求預算、基線回應比較以避免 WAF- 混淆的誤報、隨機路徑探測基線以檢測毯子 403 部署。
• Authorization gating for intrusive payloads. 在大多數司法管轄區中，將 SQLi 或 OS- 命令有效負載發送到您不擁有的網域是非法的。真正的掃描程式需要 DNS 或 HTTP- 檔案所有權驗證，然後才能對目標執行主動模式。

FixVibe的方法：基於證據的掃描，低誤報負載

FixVibe is a DAST built specifically for AI-generated web apps. The passive phase runs 200+ checks on the rendered page (headers, CSP, cookies, leaked secrets, BaaS misconfiguration, tech fingerprinting, DNS, attack-surface discovery). The active phase adds payload-firing probes (SQLi, XSS, SSTI, CORS, redirects, IDOR walking, CSRF, account enumeration, blind-SSRF) gated behind verified-domain ownership. Repo scans add code-phase checks against connected GitHub repositories. Every finding includes evidence, a CWE link, a remediation recipe, and either a coding-agent prompt or operator steps depending on who can actually apply the fix. The scan engine is open in the changelog — every new check, accuracy improvement, and false-positive fix is logged publicly.

FixVibe 與 Burp Suite、ZAP 和 Nessus：每個工具獲勝時

沒有一個工具可以涵蓋所有工作流程。 FixVibe 適合的誠實框架：

這些工具相互補充

• Start with FixVibe passive 作為任何部署預覽的免費 30 秒基準。如果什麼都沒有出現，你就會得到一個快速的信心訊號。
• 當您想要針對您自己的基礎設施進行完全主動覆蓋 (SQLi/SSTI/IDOR/etc.) 時，請在經過驗證的網域上Move to FixVibe active。
• Layer SAST（Semgrep、CodeQL、Snyk）位於 CI 中的原始程式碼。 SAST 捕捉運行時看不到的內容 - 程式碼路徑中永遠不會到達部署的危險模式。
• Reach for Burp Suite 當您需要自訂攻擊鏈時（特定的身份驗證繞過、複雜的IDOR 場景、業務邏輯缺陷）。 Burp 是可用的最深的手動工作臺； FixVibe 是最快的自動化基準。

後續步驟

Continue 和 Vibe coding security checklist 進行 44 項出貨前審核，或跳到 How to secure an app built with AI coding tools 使用程式碼片段進行逐步強化。