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. 開発者がこれらのツールを選択するのは、出荷が早いためです。レイテンシーのフィードバックは即時かつ直接的です。セキュリティ フィードバックが存在しないか遅延しています。出荷から 3 週間後の 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 ルールはまったく書き込まれないか、許容テスト モードのままになります。 Anon ユーザーはすべての行を読み書きできます。 FixVibe は、これに baas.supabase-rls および baas.firebase-rules としてフラグを立てます。

Why it happens: RLS は Postgres 固有の機能です。 Rails、Django、Laravel、Express でトレーニングを受けた LLM は、アプリケーション層の認証チェックが標準であると考えています。 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() を決して信頼しないでください。すべてのリクエストで JWTs を検証し、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 キー、セントリー トークン、Anthropic API キーはハードコーディングされるか、リポジトリにコミットされます。分析のオリジンは許容範囲が広すぎます。 npm の依存関係は古いです。 FixVibe スキャンは、discovery.tech-fingerprint とシークレット チェッカーの下でこれらを検出結果としてフラグを立てます。

Why it happens: 統合はドキュメントとチュートリアルから貼り付けられます。 LLM は、ハードコードされた値を含むパターンをコピーします。 Env-var の規律には CI/CD での明示的な規律が必要ですが、LLM では強制できません。

Fix: すべてのサードパーティ資格情報に環境変数を使用します。シークレットを展開プラットフォーム (Vercel、Netlify、Heraku、またはボールト) に保存します。 npm の依存関係を npm audit で毎月監査します。セキュリティ更新プログラムが利用可能な場合は、自動化された PR のために、Dependabot または Renovate を使用します。

修復パターン

これらのギャップを埋めるために、最初から再構築する必要はありません。パターンには一貫性があります。

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 セキュリティ フィードバック (サービス キーをクライアント コンポーネントに貼り付けようとしているときに警告する Cursor の提案)、および MCP- 主導の自動修正 (コーディング エージェントが FixVibe の結果にアクセスして修正できる)自主的に）。 FixVibe の公開 changelog は、どのギャップが最初に縮まりつつあるかを追跡します。

次のステップ

起動前の go/no-go チェックリストについては、Pre-launch SaaS security checklist を参照してください。コード スニペットと実際の障害パターンを含む段階的な強化のチュートリアルについては、How to secure an app built with AI coding tools を参照してください。