【入門編】APIの認可におけるIDOR（Insecure Direct Object Reference）の防止 – アプリケーションセキュリティ & 安全な開発防御ガイド

「自分のものだけ」を正しく守る。API開発者が絶対に避けるべきIDOR（権限不備）の落とし穴

こんにちは！現場でセキュリティの最前線に立っていると、日々いろいろな「想定外」に遭遇します。

今日は、Webアプリケーション開発者が最初にぶつかる壁でありながら、実は非常に奥が深い「IDOR（Insecure Direct Object Reference：安全でない直接オブジェクト参照）」という脆弱性についてお話しします。

難しそうな名前ですよね。でも、実はこれ、「家の鍵を閉め忘れる」のとは少し違う、もっと巧妙な「泥棒の手口」なんです。一緒に紐解いていきましょう。

—

まずはイメージしてください。あなたは高級マンションのオーナーだとします。
各部屋には room_id=101, room_id=102 と番号が振られていますよね。

IDORの脆弱性があるシステムとは、「101号室の住人が、URLの数字を102に変えるだけで、隣の102号室の合鍵を勝手に作れてしまう状態」を指します。

例えば、あなたのマイページを表示するAPIがこんな形だとします。
GET /api/user/profile?id=1001

攻撃者はこう考えます。「自分（1001）の情報が取れるなら、1002も取れるんじゃないか？」と。そして、URLを書き換えてリクエストを投げます。サーバーが「お、1002番のデータね。はいどうぞ！」と中身を返してしまったら…それがIDORの完成です。

サーバーは「URLで指定されたID」を信じすぎて、そのデータが本当にリクエストを送ってきた本人に属するものなのかを確認していないんです。

—

では、どうすればこの「なりすまし」を防げるのでしょうか。対策は意外とシンプルです。

連番（1, 2, 3…）だと攻撃者に次のターゲットを教えるようなものです。代わりに、UUID（ランダムな文字列）を使いましょう。

※これだけで攻撃の難易度は跳ね上がります。

これが一番の防御策です。たとえURLで id=1002 と指定されても、サーバー側で「今ログインしているのは誰だ？」を確認するのです。

実装のコード例（Node.js / Expressのイメージ）

app.get(‘/api/user/profile’, (req, res) => {
// 悪い例：URLからIDを直接取得してDB検索
// const userId = req.query.id;

// 良い例：セッション（ログイン情報）からuserIdを特定する
const currentUserId = req.session.userId;

// DBから取得する際も、必ず「自分のID」であることをWHERE句で縛る
const userData = db.query(
‘SELECT FROM users WHERE id = ?’,
[currentUserId] // URLのパラメータは無視して、ログイン中のIDを使う！
);

res.json(userData);
});

—

開発者は、アプリのロジックだけでなく、ブラウザに送る「メッセージ（ヘッダー）」にも気を配る必要があります。特に最近の攻撃では、悪意のあるスクリプトが裏で動くケースも多いため、以下のヘッダーを意識してみてください。

—

IDORを防ぐ鍵は、「クライアントから送られてきたデータは、すべて嘘かもしれないと疑うこと」です。

「URLにIDが入っているから、そのデータを返せばいいや」ではなく、「このユーザーは、本当にこのデータにアクセスする権利を持っているのか？」とサーバー側で最後にもう一度確認する。この「ひと手間」が、あなたのユーザーのプライバシーを守る最強の盾になります。

開発はスピードが命ですが、泥棒に入られた後では取り返しがつきません。今日から、APIを実装するたびに「これ、自分のIDをURLから無理やり書き換えても壊れないかな？」と自分に問いかけてみてください。

一歩ずつ、安全なコードへの階段を登っていきましょう！応援しています。