本文へスキップ
ITDセキュリティ対策プラットフォーム
目的から探す
検索
用語辞典9分で読める

IDORとは：IDを書き換えるだけで他人のデータが見えてしまう脆弱性

IDOR（Insecure Direct Object Reference／アクセス制御不備）は、URLやパラメータのIDを書き換えるだけで、本来見られないはずの他人のデータにアクセスできてしまう脆弱性です。仕組みの図解と、基本の防御（サーバー側で“この利用者がこの対象を見てよいか”を毎回確認）を防御目線で解説します。

本文を読む
#IDOR#アクセス制御#脆弱性
公開日
更新日
目次

URLの id=124 を 125 に変えただけで他人の請求書が表示されてしまう脆弱性が、IDOR（アクセス制御不備）です。仕組みと確実な防ぎ方を解説します（攻撃手順は載せません）。

なぜ起きるか

「認証（誰か）」は通っているのに、「認可（その人がこれを操作してよいか）」が抜けていると発生します。認証と認可は別物で、ログインできること＝そのデータを見てよいこと、ではありません。

よくある抜け結果
ログイン後はIDをそのまま信用他人のIDに書き換えるだけでアクセスできる
画面に出さない＝安全と誤解APIを直接呼び出されると防げない
作成/更新/削除に権限チェック無し閲覧だけでなく改ざん・削除まで可能

なぜ成立するか（仕組み）

利用者Aがログイン → 自分の請求書 /invoice?id=124
id を 125（利用者Bの物）に書き換える
↓ サーバーは「125は存在する」しか見ない
所有者チェックが無いので、他人の請求書が表示される
IDの“形”だけ見て所有者を確認しないと、自分のIDを他人のIDに変えるだけで通ってしまう。

IDはURLの ?id= だけに現れるわけではありません。APIのパス（/api/orders/125）、JSONの本文（"userId": 125）、ファイルのダウンロードURL、隠しフィールドなど、利用者が送ってくる値で対象を選んでいる場所はすべて同じ確認が必要です。

似た言葉との違い

IDORは「アクセス制御の不備」の中の一つの形です。呼び方が複数あり、隣の問題と混同されやすいので並べます。

用語何が抜けているか例
IDOR対象ごとの所有者・権限の確認利用者Aが、IDを変えて利用者Bの請求書を見る
BOLAIDORと同じ（OWASP APIセキュリティでの呼び方）APIの /orders/{id} で他人の注文を取れる
機能レベルの認可不備機能ごとの権限の確認一般利用者が管理者用のAPIを呼べる
認証の不備「誰か」の確認そのものログインせずにAPIを呼べる

OWASP Top 10 では、アクセス制御の不備（A01）が2021年版に続き2025年版でも1位です。APIに絞った OWASP API Security Top 10（2023年版）でも、BOLAが1位（API1:2023）に置かれています。

具体例：ログイン後に他人のデータが見えた事例

当サイトで扱った公的機関の事例には、原因がシステム更新時の不具合と公表されているものの、結果が「ログインした利用者が、他人のデータを扱えた」という認可の不備と同じ形になったものがあります。

  • 英国の会社登記所 Companies House（2026年3月）：WebFiling にログインした利用者が、特定の操作をすると他社の取締役の自宅住所などを見られる可能性があり、同意のない届け出も技術的には可能だった。同機関は外部からの攻撃ではなく、2025年10月のシステム更新で入った不具合が原因としている → 詳しい解説
  • 国税庁 e-Tax（2026年9月）：マイページの改修で生じた不具合により、79人分の贈与税申告書などが本人以外の利用者から閲覧できる状態だった → 詳しい解説

どちらも、ログインの確認は機能していました。抜けていたのは「その利用者が、この対象を扱ってよいか」の確認です。そして、どちらも改修の後に起きています。一度正しく作っても、機能を足したときに確認が外れることがあるため、自動テストで毎回確かめる意味があります。

防御：サーバー側で「所有者・権限」を毎回確認

1

対象ごとに所有者・権限をチェック（最重要）

データを返す/変更する直前に、「ログイン中の利用者IDが、その対象の所有者か・操作権限を持つか」をサーバー側で必ず照合。満たさなければ拒否。

2

既定で拒否（deny by default）

新しいエンドポイントは「明示的に許可した条件以外すべて拒否」を初期状態に。チェックを付け忘れても、アクセスが許可されてしまわないようにする。

3

“自分の物”だけを問い合わせる

クエリ自体に所有者条件を含める（例：利用者ID＝本人 で絞る）。アプリ全体で共通の認可ヘルパに通し、各所での書き忘れを無くす。

4

画面制御を防御と勘違いしない

ボタンを隠す/出さないはUXであって防御ではない。APIは直接呼び出される前提で、サーバー側でだけ判断する。ランダムIDは補助に留める。

自分のアプリで確認する方法

自分が開発・管理するアプリで、次の手順で確かめます。他人のサービスで試すのは不正アクセスになり得るので、必ず自分の環境で行います。

  1. テスト用の利用者AとBを作り、それぞれにデータ（注文・ファイルなど）を1件ずつ作る
  2. Aでログインした状態で、Bのデータを指すIDで「閲覧・更新・削除」の各APIを呼ぶ。画面ではなく、開発者ツールやAPIクライアントから直接呼ぶ
  3. すべて403か404で拒否されることを確かめる。一覧APIの結果にBのデータが混ざらないことも見る
  4. この確認を自動テストにし、新しいエンドポイントを足したら同じテストを追加する

OWASP の API Security Top 10 も、認可の仕組みを評価するテストを書き、そのテストが失敗する変更はデプロイしないことを勧めています。

当サイトの視点：目立たないが被害は大きい。自動テストで確認する

IDORは技術的に地味で、コードレビューでも見落とされがちです。しかし「ワンクリックで他人の個人情報が全件見える」ような被害規模は最大級です。だからこそ、「別ユーザーで他人のIDにアクセスしたら403になるか」を自動テストに固定化するのが実戦的です。当サイトは「クライアント側の見た目で守らない／サーバー側でだけ判断する」を原則にしています。認可は仕組みとして毎回確実に実行されるようにするもので、人の注意力に頼らないことが大切です。

出典（一次情報）

  • OWASP Top 10:2025「A01 Broken Access Control」 — top10.owasp.org（順位、insecure direct object references の例）
  • OWASP API Security Top 10 2023「API1:2023 Broken Object Level Authorization」 — api-security.owasp.org（防ぎ方、テストの推奨）
  • MITRE CWE-639: Authorization Bypass Through User-Controlled Key — cwe.mitre.org
  • 事例の出典は、各事例の解説記事（Companies House・国税庁の公表）に掲載しています

次に読む

分類番号

CWE は脆弱性の原因となる弱点の種類を、MITRE ATT&CK は攻撃者の手口を分類した番号体系です。どちらも MITRE が管理し、脆弱性情報や検知ルールの分類に広く使われています。

CWE（弱点の種類）

CWE™: Copyright © 2006–2026, The MITRE Corporation. CWE is a trademark of The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE Terms of Use

よくある質問

QIDORで何が起きる？
A

ログイン済みの利用者が、URLやAPIのID（?id=124 など）を別の値に書き換えるだけで、他人の請求書・注文・個人情報・ファイルなどを閲覧・変更・削除できてしまいます。OWASPでも最も多い問題群（アクセス制御の不備）の代表で、特別な道具がなくても起きるのが怖い点です。

Q一番の防御は？
A

『サーバー側で毎回、“このログイン中の利用者が、この対象を操作してよいか”を確認する』ことです。IDが正しい形でも、それが本人の所有物か・権限があるかを必ずチェックし、無ければ拒否（既定で拒否）。クライアント側の画面制御だけに頼ってはいけません。

QIDをUUIDやランダムにすれば防げる？
A

それは“推測されにくくする”だけで、根本対策ではありません。IDが漏れたり共有されたりすれば、そのままアクセスされます。ランダム化は補助に留め、対策の中心は必ずサーバー側の所有者・権限チェックにします。

QIDORとBOLAの違いは？
A

指している問題は同じです。IDORはWebアプリで古くから使われてきた呼び方で、BOLA（Broken Object Level Authorization）はOWASPのAPIセキュリティTop 10での呼び方です。BOLAは2023年版でも1位（API1:2023）に置かれています。どちらも『対象（オブジェクト）ごとの認可の確認が抜けている』ことを指します。

Q自分のアプリにIDORがないか、どう確かめる？
A

自分のアプリで、テスト用の利用者AとBを作ります。Aでログインした状態で、Bが持つデータのIDを指定して閲覧・更新・削除を要求し、すべて拒否（403や404）されるかを確かめます。画面からではなくAPIを直接呼んで確認し、この確認を自動テストに入れておきます。

QIDORはOWASP Top 10のどれに当たる？
A

A01「アクセス制御の不備（Broken Access Control）」です。2021年版でも2025年版でも1位で、OWASPはその例として『固有の識別子を指定するだけで他人のアカウントを閲覧・編集できる（insecure direct object references）』を挙げています。