IDORとは｜「find({ id })」の1行が、あなたのアプリの全データを他人に見せる

定義と、実際にコードを動かして見る挙動

IDORの本体は「アクセス制御チェックの欠落」。この記事のコードは想像ではなく実際に実行した結果で、1行の差がそのまま被害の有無になる。

認可設計とIDORの関係は、OWASPの定義に集約されています。“a vulnerability that arises when attackers can access or modify objects by manipulating identifiers”。URLやパラメータの識別子を操作するだけで、他人のオブジェクトにアクセス・変更できてしまう脆弱性です。

実際に動かして確かめる

認可設計とIDORを理解する一番の近道は、コードを動かして見ることです。

百聞は一実行に如かずです。以下のコードは編集部が実際にNode.jsで実行したもので、出力もそのまま貼っています。

const orders = [
  { id: 1001, userId: "user-alice", item: "ノートPC", amount: 128000 },
  { id: 1002, userId: "user-bob", item: "モニター", amount: 32000 },
];

// ❌ 脆弱: IDだけで検索。所有者を確認しない
function getOrderVulnerable(orderId) {
  return orders.find((o) => o.id === orderId) ?? null;
}

// ✅ 修正: 所有者(userId)も条件に含める
function getOrderFixed(orderId, requestingUserId) {
  return orders.find((o) => o.id === orderId && o.userId === requestingUserId) ?? null;
}

=== 脆弱な実装（IDのみで検索） ===
attacker(user-mallory) が bob の注文1002を要求:
{
  "id": 1002,
  "userId": "user-bob",
  "item": "モニター",
  "amount": 32000
}

=== 修正後の実装（所有者チェックあり） ===
attacker(user-mallory) が bob の注文1002を要求:
null
bob(user-bob) が自分の注文1002を要求:
{
  "id": 1002,
  "userId": "user-bob",
  "item": "モニター",
  "amount": 32000
}

結果が語ること

同じgetOrderという関数名で、差は検索条件に userId が入っているかだけです。脆弱な方はmalloryにbobの注文明細（金額つき）をそのまま返し、修正版は他人のデータには null、自分のデータには正しく応答しています。

対策は3層——検索条件・データセット・識別子

本命は検索条件への所有者ID追加。IDの複雑化とデータセット限定は、それを補強する層として重ねる。

認可設計とIDORの対策は、OWASPがいくつかの層で示しています。“Implement access control checks for each object”。ユーザーがアクセスを試みるオブジェクトごとに、アクセス制御チェックを実装する——実務では3つの層に分けて考えると設計しやすくなります。

層1（本命）: 検索条件に所有者を必ず入れる

// ❌
const order = await prisma.order.findUnique({ where: { id: orderId } });

// ✅
const order = await prisma.order.findFirst({
  where: { id: orderId, userId: req.user.id },
});

層2: 「持っているものだけ」から探す発想

OWASPはこうも助言しています。全件から検索してIDが一致するかを見るのではなく、最初からユーザーがアクセス権を持つデータセットの中だけを探す——「自分のプロジェクト一覧から取得する」のように、範囲を絞ってから検索する発想です。この考え方はAPI連携の記事で扱った最小権限の原則と同じです。

層3（補助）: 推測しにくい識別子

連番ID（1, 2, 3…）は総当たりで簡単に探索できます。UUIDやランダムな長い文字列に変えると推測は難しくなりますが、OWASPは“access control is crucial even with these identifiers”と釘を刺しています。複雑な識別子はチェックの代わりではなく、チェックに重ねる保険です。

自分のアプリで探す——15分でできる手動テスト

自動診断ツールは苦手な領域。2つのテストアカウントとIDの入れ替えだけで、多くのIDORは自分で見つけられる。

認可設計とIDORの不備は「仕様として何が正しいか」を判断する必要があるため、機械的な脆弱性スキャナーでは見つけにくい代表格です。個人開発者が自分でできる、最も確実なテスト手順を示します。

手順

1. テストアカウントを2つ作る（A・B）
2. Aでログインし、自分のデータ（注文・投稿・設定など）のURLやAPIレスポンスからIDを控える
3. Bでログインした状態で、控えたAのIDを使ってアクセスを試みる（URL書き換え・APIパラメータ変更）
4. Aのデータが見えた・編集できたら、そのエンドポイントはIDOR。修正して層1から適用する

UIの非表示は防御にならない