AI に作らせたアプリは「他人のデータを読めないか」とトークン失効を必ず確かめる（Datadog の比較実験）
安全なコード作成ルール Project CodeGuard を AI に与えても、生成された文書管理アプリにはログイン済みの利用者が他人の文書を読める IDOR（所有者確認の欠落）が残った。ルールを渡すだけでなく、アクセス範囲を仕様として指示し、出来上がったものを決まった観点で確認する。
実験で残った問題
Datadog が Claude Code（Sonnet 5）、Cursor（Composer 2.5）、Codex（GPT-5.5）に同じアプリを各 1 回作らせた結果:
- IDOR: ルールなしでは 3 モデルとも他人の文書にアクセス可能。ルールありでも解消したのは GPT-5.5 だけ。
- ログアウト後も読める: セッション失効の確認がデータ変更時だけで、ログアウトやアカウント無効化後も最大 15 分（アクセストークンの有効期限）読み取りできた。JWT の失効を確認せず、ログアウトやパスワードリセット後も最大 24 時間有効だった実装もあった。
- 秘密の既定値で本番起動: JWT やセッションの秘密が未設定のとき、コード内の既定値を先に入れてしまい、「未設定ならエラー」の検査が働かなかった。
- 古いリセットトークンが生きている: パスワードリセット用トークンを再発行しても、期限内の古いトークンが無効にならなかった。
各モデル 1 回ずつの結果なので、モデルの優劣を一般化はできない。
依頼と確認のしかた
- アクセス条件を仕様に書く。 「文書は作成者本人だけが読める。共有は明示的に招待した相手だけ」のように、所有者での絞り込みを依頼文に入れる。指定がないと AI は全員共有の設計にしがち。
- 2 アカウントで試す。 利用者 A の文書 ID を利用者 B のセッションで GET / PUT / DELETE し、404 か 403 になるかを確認する。一覧 API や検索 API も同様。
- 失効を確認する。 ログアウト、パスワード変更、アカウント無効化の直後に、古いトークンで読み取り API を叩いて拒否されるか確かめる。JWT を使うなら失効リストか短い有効期限＋リフレッシュ時の確認を入れる。
- 秘密の既定値を禁止する。
process.env.JWT_SECRET ?? "dev-secret"のような書き方を探し、未設定なら起動を失敗させる。 - リセットトークンは 1 つだけ有効にする。 再発行時と使用時に古いトークンをすべて無効化する。
既存の 公開アプリ解析前提でバックエンドを守る（A2B 攻撃の点検チェックリスト） とあわせて、生成コードのレビュー観点に組み込むとよい。
出典
- @MalwareBibleJP · 2026-10-27
- 一次情報: Datadog Security Labs securitylabs.datadoghq.com