為何 AI 撰寫工具會留下安全漏洞

為什麼AI-產生的程式碼在安全性方面有所不同

AI 編碼工具產生的安全漏洞有其結構性原因。它們不是隨機的疏忽；而是。它們是訓練和優化的可預測產物。

• Training data skews toward "make it work." 開源存儲庫和教程主導LLM 培訓。中間的 OSS 儲存庫是為了解決問題而編寫的，而不是作為安全強化的典範。 LLM 學習的是野外代碼的分發，而不是安全代碼的分發。
• Autocomplete is sticky. 當您貼上使用service_role 鍵的程式碼片段時，它將成為下一個檔案的模板。 Cursor 的自動完成功能將在它不屬於的客戶端元件中建議它。該工具正在執行其最佳化的操作（速度），但它不知道安全邊界。
• No long-term context or incident memory. 一位人類開發人員因缺少 WHERE 子句而燒毀了生產資料庫，並將這一教訓延續了多年。 LLM沒有情景記憶。每個文件都是一個新的開始。該工具不會從您上次的RLS繞過或您團隊的事件事後分析中學習。
• Speed is the rewarded metric. 開發人員選擇這些工具是因為它們交付速度快。延遲回饋是即時且直接的。安全回饋缺失或延遲－出貨三週後FixVibe掃描中發現的漏洞。 LLM 針對人類即時獎勵的指標進行了最佳化。
• Implicit trust in platform defaults. 當Cursor 生成Vercel 應用程式時，它假定Vercel 的預設設定已得到強化。其中包括：auto-HTTPS、簽章 cookie、DDoS 保護。其他則不然：預設沒有CSP，沒有HSTS，寬容CORS。生成的程式碼繼承了並不總是合理的平臺假設。

差距 1：客戶端包中的秘密

服務角色 API 金鑰、OAuth 令牌和私密金鑰最終以 JavaScript 捆綁包形式傳送到瀏覽器。 FixVibe 將這些標記為secrets.browser-storage 和secrets.bundle-leak 結果。這些金鑰可以在來源映射、精簡程式碼或明文JS中發現。

Why it happens: Cursor 貼上使用服務角色初始化客戶端的Supabase 程式碼片段表示程式碼現在處於自動完成狀態。產生的 React 元件要求“從資料庫取得所有項目”，Cursor 建議服務用戶端匯入。僅伺服器程式碼和客戶端程式碼之間的邊界抽象化為LLM。

Fix: 將機密儲存在標記為 NEXT_PUBLIC_ 的環境變數中，僅用於公鑰。服務金鑰、API 私鑰和簽章金鑰必須位於src/lib/secrets.ts 和import 'server-only' 中。使用伺服器操作或 API 路由來呼叫敏感服務，而不是客戶端元件。

差距 2：行級安全性缺失或不完整

Supabase 表格是在未啟用RLS 的情況下建立的。 Firebase Firestore 規則永遠不會編寫或保留在寬鬆測試模式下。匿名用戶可以讀取和寫入每一行。 FixVibe 將其標記為baas.supabase-rls 和baas.firebase-rules。

Why it happens: RLS 是 Postgres 特定的功能。受過 Rails、Django、Laravel 和 Express 培訓的法學碩士將應用程式層身份驗證檢查視為常態。在Supabase 上啟用RLS 需要明確的ALTER TABLE 語句和策略定義－在訓練資料中較不常見的模式。

Fix: 對於Supabase，強制在每個表格上使用RLS 和ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY;。建立將行範圍限定為經過驗證的使用者或組織的策略。對於Firebase，切勿將規則保留為預設測試模式；編寫適用於經過驗證的使用者的明確規則。

差距 3：身分驗證邊界混亂

會話使用 getSession()（讀取未經驗證的 cookie）在客戶端進行驗證。魔法連結沒有過期時間。 JWTs 跳過aud 和exp 檢查。密碼重置是可逆的。 FixVibe 將這些標記為 active.auth-flow 結果。

Why it happens: Supabase Auth、Clerk 和類似服務處理會話狀態，但它們的 API 有安全和不安全模式。 getSession() 很方便，但未經驗證。 LLM 在訓練資料中更頻繁地看到便利性API，而不是安全性。伺服器端令牌驗證是抽象的，需要明確的 HTTP 標頭或中間件呼叫。

Fix: 始終使用supabase.auth.getUser() 伺服器端。切勿信任受保護路由上的getSession()。驗證每個請求的JWT，檢查exp、aud 和簽名。將存取令牌的令牌過期時間設定為 1 小時，並為較長的會話使用刷新令牌。

差距 4：缺少 HTTP 安全標頭

沒有Content-Security-Policy，沒有X-Frame-Options，沒有Strict-Transport-Security，沒有X-Content-Type-Options。 FixVibe 將此標記為headers.security-headers 發現。

Why it happens: 安全標頭是特定於部署平臺的。 Cursor 產生Next.js 的代碼；設定CSP需要next.config.js調整、中間件或vercel.json覆蓋。這些不在預設的項目腳手架中。 「標題用於 DevOps」的心理模型仍然很常見。

Fix: 在next.config.js 或支援nonce 的中間件中設定CSP：Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; ...。添加HSTS：Strict-Transport-Security: max-age=31536000; includeSubDomains。對靜態主機使用 Vercel 的 vercel.json 標頭或中間件。

差距 5：第三方整合配置錯誤

Stripe 金鑰、Sentry 令牌、Anthropic API 金鑰是硬編碼的或提交到儲存庫。分析起源過於寬容。 npm 依賴項已過時。 FixVibe 掃描將這些標記為discovery.tech-fingerprint 和我們的秘密檢查器下的發現。

Why it happens: 整合是從文件和教學課程貼上的。 LLM 複製模式，包括任何硬編碼值。環境變數紀律要求 CI/CD 中的明確紀律 - LLM 無法強制執行。

Fix: 對每個第三方憑證使用環境變數。將機密儲存在您的部署平臺（Vercel、Netlify、Heroku 或保管庫）中。每月使用 npm audit 審核 npm 依賴關係。當安全性更新可用時，使用 Dependabot 或 Renovate 進行自動 PR。

修復模式

縮小這些差距並不需要從頭開始重建。模式是一致的：

1. Audit: 針對您的即時應用程式運行FixVibe。對於回購掃描，請啟用 FixVibe GitHub 應用程式。收集結果 - 秘密、RLS、身份驗證、標頭、第三方。
2. 強化:修復高信心度的發現。啟用 RLS + FORCE。將密鑰移至環境變數。在中介軟體中設定 CSP 和 HSTS。使用伺服器端驗證檢查。僅在程式碼/設定變更適用之處使用編碼代理提示,DNS 或由供應商負責的修復請遵循操作員步驟。
3. Monitor: 在已驗證的網域上安排每日被動掃描或每週主動掃描。設定 Slack 的 Webhook。每個關鍵發現都應在船舶發出後幾分鐘內觸發警報。
4. 回應:發現出現時,複製與修復負責方匹配的 FixVibe 修復動作:程式碼/設定工作使用編碼代理提示,DNS、供應商主控臺、密鑰輪替和人工審查使用操作員步驟。重新掃描以確認。

該領域的發展方向

彌補這些差距是當今團隊的工作。在接下來的 2-3 年裡，前沿正在發展：框架和工具中更好的預設設定（Next.js 中間件自動 CSP、Supabase RLS 作為預設設定）、IDE-time 安全性回饋（當您要將服務金鑰貼到客戶端元件時發出警告的建議 ZQXZXZX）驅動的自動修復（您的編碼代理可以存取FixVibe 發現並可以自主修復它們）。 FixVibe 的公開 changelog 追蹤哪些缺口首先縮小。

後續步驟

有關啟動前的 go/no-go 檢查清單，請參閱Pre-launch SaaS security checklist。有關包含程式碼片段和真實故障模式的逐步強化演練，請閱讀How to secure an app built with AI coding tools。