securitywebai
AIで作ったWebアプリが一番やらかす：IDOR（認可ミス）を出荷前に潰す手順
|
6 min read
AI実装は速いが、そのぶん「認可（authorization）」が抜けやすい。IDOR（オブジェクト単位の認可ミス）を最短で見つけて直すための実務手順、判断基準、回帰テスト、運用の型をまとめる。
目次
- 結論（Conclusion）
- 背景（Explanation）
- 実務手順（Practical Guide）
- 1) 守るべき“オブジェクト境界”を定義する
- 2) id の入口を棚卸しする（最短監査）
- 3) 認可パターンを全箇所に統一する
- 4) denyを 403 か 404 に決めて標準化する
- 5) 回帰テストを1本入れる（ROI最大）
- 6) PIIを漏らさないdenyログにする
- 失敗パターン（Pitfalls）
- チェックリスト（Checklist）
- FAQ
- Q1. UUIDならIDORは防げる？
- Q2. 403と404、どっちが正しい？
- Q3. AIでコーディングするとき、IDORを減らすコツは？
- 内部リンク（Internal links）
- 免責
AIで実装させる前に、IDOR（認可ミス）をどう防ぐ？
結論（Conclusion）
IDOR（Insecure Direct Object Reference）は、ログイン済みのユーザーが id を変えるだけで他人のデータに触れる状態。
AI生成コードで増えやすいのは、AIが「機能が動く」方を先に満たし、認可を暗黙にしてしまうから。
最短の勝ち筋はこれ。
- すべての取得/更新で サーバー側の認可を必ず通す
- 403/404（denyの方針）とログを標準化する
- 回帰テストを1本入れる：AのオブジェクトをBが触れない
これだけで再発率が大きく下がる。
Implementation examples may be available on DevSnips.
背景（Explanation）
認証は「誰か」を決める。 認可は「何にアクセスできるか」を決める。
IDORは、認証はあるのに認可が抜ける/揺れる状態。 AI実装で増える理由は単純で、よくある生成パターンがこれ。
findById(id)して返す（所有者チェックなし）- UIでボタンを隠したから安全だと思う
- マルチテナント境界（org/team/project）を忘れる
「UUIDだから大丈夫」は負け筋。IDはログ/リンク/スクショ/サポート対応で漏れる。
実務手順（Practical Guide）
1) 守るべき“オブジェクト境界”を定義する
ユーザー/組織に紐づくデータを列挙する。
- プロジェクト、ドキュメント、請求
- スレッド、コメント
- ファイル、エクスポート、レポート
個人/業務データが入るなら、境界対象。
2) id の入口を棚卸しする（最短監査）
探す場所：
/:idルート- body内の
id,userId,orgId,projectId - Server Actions / 内部サービス
判断基準：
- クライアントが送れる
idは、必ず改竄される前提で設計する。
3) 認可パターンを全箇所に統一する
順番を固定する。
- 認証
- idで取得
- 取得したオブジェクトに対して認可
- 返す
疑似コード：
const user = await requireUser(req); // 未認証は401
const doc = await db.doc.findUnique({ where: { id: params.id } });
if (!doc) return notFound();
if (doc.orgId !== user.orgId) return deny();
return json(doc);
4) denyを 403 か 404 に決めて標準化する
- 列挙を減らすなら 404
- 監査や運用都合で明示したいなら 403
どちらでもいいが、全体で統一してヘルパー化する。
5) 回帰テストを1本入れる（ROI最大）
最小形：
- ユーザーAでオブジェクト作成
- ユーザーBで取得/更新を試す
- 403/404 を期待
判断基準：
- テストが書けないなら、認可境界が分散しすぎている。
6) PIIを漏らさないdenyログにする
残す：
- user id / org id（内部ID）
- route + method
- object type
残さない：
- トークン
- メール
- 生payload
失敗パターン（Pitfalls）
- 「UIで隠したからOK」（セキュリティコントロールではない）
- クライアントの
orgId/userIdを信用する - denyが揺れる（ルートによって200が返る）
- webhook/cron/batchの経路を忘れる
- ログに出しすぎて二次漏洩
チェックリスト（Checklist）
- [ ] ユーザー/組織スコープのリソース種別が定義されている
- [ ]
idを受け取る入口が棚卸しできている - [ ] 認証→取得→認可→返却 の順が全箇所で統一
- [ ] クライアント提供の
orgId/userIdを認可に使っていない - [ ] 403/404 の方針が決まっている
- [ ] denyレスポンスがヘルパー化されている
- [ ] 回帰テスト（BがAのオブジェクトに触れない）がある
- [ ] org/team/project の境界が強制されている
- [ ] webhook/cron/batchも同じ認可ルール
- [ ] denyログがある（ただしPII/秘密は出さない）
- [ ] AI生成コードで認可に触れる変更はレビューゲートを通す
FAQ
Q1. UUIDならIDORは防げる？
防げない。推測は減るが、IDはログ/リンク/スクショ/サポートで漏れる。必要なのはサーバー側の認可。
Q2. 403と404、どっちが正しい？
どちらもあり。列挙耐性なら404、監査なら403。重要なのは“全体で統一”すること。
Q3. AIでコーディングするとき、IDORを減らすコツは？
ルール化する。認可に触れる機能は必ず「否定テスト（他人のオブジェクトは触れない）」を要求し、レビューのチェック項目にする。
内部リンク（Internal links）
免責
本記事は一般的なセキュリティ情報であり、個別システムの安全性を保証するものではありません。