Insecure Direct Object Reference（IDOR）は、アクセス制御が適切に実装されていないために、
ユーザーが本来アクセスするべきでないリソース（ファイル、データ、ユーザー情報など）に直接アクセスできてしまう脆弱性です。
IDORは、URLやAPIリクエストに含まれるIDなどを手動で変更することで悪用されることが多く、
セッション管理や認可制御が不十分なアプリケーションにとって重大なセキュリティリスクとなります。
実際のデータ漏洩事例
2020年、某航空会社の予約管理システムにおいてIDOR脆弱性が報告されました。
攻撃者は、予約IDを連番で変更するだけで他人の搭乗情報やパスポート番号にアクセスでき、
数十万件の個人情報が閲覧可能な状態となっていました。
この事件は、大規模なデータ漏洩として報道され、企業の信頼性に大きなダメージを与えました。
攻撃者による悪用方法
IDORは、次のような単純なリクエスト改変で悪用されます：
GET /user/profile?id=1001これを攻撃者が以下のように変更します：
GET /user/profile?id=1002サーバー側で認可チェックがなければ、攻撃者は他人の情報を自由に閲覧・編集できるようになります。
なぜ危険なのか？
IDORは目立ちにくく、簡単に見逃されるため、攻撃者にとっては“おいしい”脆弱性です。
一般ユーザーに成りすまし、企業顧客の個人情報、医療データ、財務情報などを不正取得できる可能性があり、
特に同時セッションの乗っ取りやセッション固定攻撃と組み合わせると極めて危険です。
脆弱なコードの例
// 認証済みユーザーのIDを信頼しすぎている
String id = request.getParameter("id");
User user = userService.findById(id);
return user.getProfile();
安全な実装例
// ログインユーザーIDと照合して正当性を検証
String requestedId = request.getParameter("id");
String loggedInUserId = session.getAttribute("userId");
if (!requestedId.equals(loggedInUserId)) {{
response.sendError(HttpServletResponse.SC_FORBIDDEN, "アクセス権限がありません。");
return;
}}
User user = userService.findById(loggedInUserId);
return user.getProfile();
IDOR を防ぐ方法
- すべてのリソースアクセス時に認可チェックをサーバーサイドで実施
- ユーザーIDやオブジェクトIDを外部公開しない（UUIDなどのランダム値を使う）
- アクセス制御のためのロールベースアクセス制御（RBAC）または属性ベースアクセス制御（ABAC）の導入
- セキュリティ自動テスト（SAST/DAST）による脆弱性の検出
- セッション固定やトークン管理と合わせて対策
企業に与える影響
IDORの脆弱性による情報漏洩は、個人情報保護法違反やGDPRの罰則対象となり、
数百万〜数千万単位の罰金、顧客離れ、訴訟、株価の暴落などのリスクを企業にもたらします。
特に金融、医療、教育分野での被害は深刻です。
まとめ
Insecure Direct Object Reference（IDOR）は、実装ミスや設計ミスによって生じやすい脆弱性です。
攻撃は単純ですが、影響は重大です。APIやWebアプリケーションでは、
ロールやセッション情報に基づいた厳格なアクセス制御を導入することで、
ログイン脆弱性やデータ漏洩のリスクを最小限に抑えることができます。
キーワード: IDOR, Insecure Direct Object Reference, アクセス制御の欠陥, 認可ミス, ロールベース制御, ログイン脆弱性, セッション管理, サイバーセキュリティ, 個人情報保護, データ漏洩, APIセキュリティ, 同時セッション
