【要約】AIが作ったアプリ、セキュリティの穴は誰が塞ぐ？ [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
AIを用いてアプリを開発するエンジニアが、機能の動作確認のみに注力することで、重大な脆弱性を見逃すリスクに直面している。AIは「動くこと」を最優先するため、以下の問題が発生しやすい。
- ・内部リスク：DBへの過剰な権限付与や、通信・保存データの未暗号化。
- ・外部リスク：DoS攻撃への無防備、XSS、SQLインジェクション、認可の不備（IDOR）。
- ・検知の困難さ：これらはアプリが正常に動作するため、単純な動作確認では発見できない。
// Approach
開発者はAIが生成したコードに対し、フレームワークの防御機能がどこまで適用されているかを検証するアプローチを取るべきである。具体的には以下の対策を講じる。
- ・権限とログ：最小権限の原則に基づき権限を分離し、監査ログを取得する。
- ・暗号化の徹底：HTTPSの利用、パスワードのハッシュ化、DB内の重要データの暗号化を行う。
- ・攻撃防御の実装：レートリミットの導入、エスケープ処理、プレースホルダの利用を徹底する。
- ・認可の検証：SupabaseのRLS（行レベルセキュリティ）設定や、他者データへのアクセス試行テストを行う。
// Result
エンジニアがフレームワークの守りと人間の責任の境界線を理解することで、AI開発における安全性を確保できる。具体的には以下の成果が期待できる。
- ・リスク低減：Next.jsやSupabase等の定番構成を活用し、XSSやSQLインジェクションを自動的に防ぐ。
- ・役割の変化：エンジニアは「ゼロから防御を書く」作業から、「境界線を検証する」高度な役割へシフトできる。
- ・事故防止：認可（IDOR）やレートリミットといった、動作確認では見えない領域の穴を事前に塞げる。
Senior Engineer Insight
> AI開発時代において、エンジニアの役割は「実装者」から「検証者」へ変貌する。AIは「動くもの」を作るが、「安全なもの」を作る保証はない。特に認可（IDOR）やレートリミットは、単体テストでは検知困難なため、設計段階での意識が不可欠だ。モダンなフレームワークの恩恵を理解しつつ、その「抜け穴」を突く攻撃シナリオを想定したレビュー能力が、実戦における生存戦略となる。