「URLの id=124 を 125 に変えたら、他人の請求書が表示された」——それがIDOR（アクセス制御不備）です。仕組みと確実な防ぎ方を解説します（攻撃手順は載せません）。
なぜ起きるか
「認証（誰か）」は通っているのに、「認可（その人がこれを操作してよいか）」が抜けていると発生します。認証と認可は別物で、ログインできること＝そのデータを見てよいこと、ではありません。
| よくある抜け | 結果 |
|---|---|
| ログイン後はIDをそのまま信用 | 他人のIDに書き換えれば素通り |
| 画面に出さない＝安全と誤解 | APIを直接叩かれると無防備 |
| 作成/更新/削除に権限チェック無し | 閲覧だけでなく改ざん・削除まで可能 |
なぜ成立するか（仕組み）
防御：サーバー側で「所有者・権限」を毎回確認
対象ごとに所有者・権限をチェック（最重要）
データを返す/変更する直前に、「ログイン中の利用者IDが、その対象の所有者か・操作権限を持つか」をサーバー側で必ず照合。満たさなければ拒否。
既定で拒否（deny by default）
新しいエンドポイントは「明示的に許可した条件以外すべて拒否」を初期状態に。チェックの付け忘れが“通る”側に倒れないようにする。
“自分の物”だけを問い合わせる
クエリ自体に所有者条件を含める（例：利用者ID＝本人 で絞る）。アプリ全体で共通の認可ヘルパに通し、各所での書き忘れを無くす。
画面制御を防御と勘違いしない
ボタンを隠す/出さないはUXであって防御ではない。APIは直接叩かれる前提で、サーバー側でだけ判断する。ランダムIDは補助に留める。
当サイトの視点：派手さは無いが、被害は最大級。テストで“見張る”
IDORは技術的に地味で、コードレビューでも見落とされがちです。しかし「ワンクリックで他人の個人情報が全件見える」ような被害規模は最大級。だからこそ、「別ユーザーで他人のIDを叩いたら403になるか」を自動テストに固定化するのが実戦的です。当サイトは「クライアント側の見た目で守らない／サーバー側でだけ判断する」を原則にしています。認可は“仕組みで毎回効かせる”もので、人の注意力に頼らないのが肝です。
次に読む
- 用語：CSRF とは（認証と認可の違い）
- 入門：セキュリティ超入門 / 無料セキュリティツール
よくある質問
QIDORで何が起きる？
ログイン済みの利用者が、URLやAPIのID（?id=124 など）を別の値に書き換えるだけで、他人の請求書・注文・個人情報・ファイルなどを閲覧・変更・削除できてしまいます。OWASPでも最も多い問題群（アクセス制御の不備）の代表で、特別な道具がなくても起きるのが怖い点です。
Q一番の防御は？
『サーバー側で毎回、“このログイン中の利用者が、この対象を操作してよいか”を確認する』ことです。IDが正しい形でも、それが本人の所有物か・権限があるかを必ずチェックし、無ければ拒否（既定で拒否）。クライアント側の画面制御だけに頼ってはいけません。
QIDをUUIDやランダムにすれば防げる？
それは“推測されにくくする”だけで、根本対策ではありません。IDが漏れたり共有されたりすれば素通りします。ランダム化は補助に留め、本命は必ずサーバー側の所有者・権限チェックにします。