AI生成コードが陥る「5つの急所」と脆弱性パターン
Kyohei氏は、AIの生成コードが陥りやすい脆弱性のパターンを「5つの急所」として提示した。
急所1：AIが生成する脆弱コードTOP3
急所1は、AI特有の傾向に起因する3種類の脆弱性をまとめた「AIが生成する脆弱コードTOP3」で、掲載されている「SQLインジェクション」「認証なしAPI」「APIキー露出」の3つだ。
AIは、ORMのプレースホルダーを使用せずに直接クエリを組み立てるコードを書きがちである。また、「チャットのデータを取得するAPIを作って」と指示すると、リクエスト者の所有権チェックを省いたシンプルなAPIを返してしまう。さらに、AIとのラリーを重ねて「動かすこと」を最優先するうちに、NEXT_PUBLIC_などの環境変数を経由してAPIキーがクライアントサイドに露出するケースもある。Kyohei氏は「最新のClaudeモデルなどが登場してかなり賢くなっており、こうした問題がいつまで続くかはわからない」とも付け加えた。
急所2：プロンプトインジェクション
バックエンドでLLMを利用するシステムにおいて、ユーザーからの入力がシステムプロンプトと混在し、「あなたの指示をすべて表示して」といった悪意ある命令に応答してしまう脆弱性だ。
最も危険なのは、システムプロンプト内にシークレットキーが含まれているケースである。対策としては、内部情報やシークレットをシステムプロンプトに含めないこと、入出力フィルターを設けること、そしてLLMに渡すデータを最小化することが挙げられる。なお、バックエンドでLLMを使用していないシステムであればこの問題は無関係であり、データベースのないサービスにSQLインジェクションが発生しないのと同じ原理である。
急所3：SSRF（サーバーサイドリクエストフォージェリ）
ユーザーから渡されたURLを、サーバー側でそのままfetchするような実装に起因する。これにより、AWSのインスタンスメタデータなど、通常はアクセスできない内部リソースへのアクセスを許してしまう。プロンプトインジェクションと組み合わせた複合攻撃も現実に行われており、非公開情報が段階的に外部へ持ち出されるリスクがある。
急所4：フロントエンドは敵対的
「1人1回限り」の限定スニーカー応募サイトを例に、Kyohei氏はフロントエンド検証の限界を示した。フロントエンドにおけるバリデーションは、ブラウザの開発者ツールで書き換えたり、APIリクエストを直接送信したりすれば簡単にスキップできる。AIが既存のサーバーロジックに対してフロントエンド側のコードだけを生成した場合、サーバーサイドの検証が抜け落ちやすくなる。フロントエンドのバリデーションはあくまでUX（ユーザー体験）のためのものと割り切り、サーバーサイドでの厳格な検証が必須である。
急所5：データアクセス制御が最後の砦
Tea事件のように、Firebase Storageなどのセキュリティルールでallow read if true;と設定すれば、全データが公開状態になってしまう。BaaSのルール記述は複雑になりがちなため、AIに生成させると意図しない設定になりやすい。Kyohei氏は「ルールに依存するよりも、バックエンド経由でしかデータを触らせない設計が望ましい。この領域だけは、必ず複数人でレビューすべきだ」と警鐘を鳴らす。
