はじめに

例えば、自分のユーザー情報を見るためのAPIがあるとします。

GET /users/1

この「1」の部分を「2」に変えたらどうなるでしょうか。

もしそのまま他人の情報が見えてしまうなら、それはバグです。
そして、このタイプの問題は実務でもよく起きます。

この記事では、この問題がなぜ起きるのかをコードで確認しながら整理していきます。

まずは何が起きているのか

次のようなAPIを考えます。

GET /users/1

レスポンス：

{
  "id": 1,
  "name": "Taro"
}

特に変わったことはしていない、よくあるAPIです。

問題のある実装

サーバー側のコードがこうなっていたとします。

<?php

$id = $_GET['id'];

$user = findUserById($id);

echo json_encode($user);

このコード、動きとしては正しいです。

指定されたIDのユーザーを取得して返しているだけです。

何が問題か

この状態でログインしているユーザーが

GET /users/2

のようにリクエストすると、どうなるか。

→ そのままユーザー2の情報が返ってきます。

つまり、

「ログインしているユーザーが誰か」と「取得するデータ」が結びついていない

状態です。

なぜこうなるか

このコードは

データを取得する処理

しかしていません。

一方で、

そのデータにアクセスしていいか

は一切確認していません。

ここが抜けると、IDを変えるだけで他人のデータにアクセスできてしまいます。

修正する

やることはシンプルで、「誰のデータか」をチェックします。

<?php

session_start();

$userId = $_SESSION['user_id'];
$targetId = $_GET['id'];

if ($userId != $targetId) {
  http_response_code(403);
  exit;
}

$user = findUserById($targetId);

echo json_encode($user);

これで、自分のデータ以外にはアクセスできなくなります。

よくあるパターン

この問題は、特別な場面だけで起きるわけではありません。

例えば：

ユーザー情報
注文履歴
ファイルダウンロード
管理画面

「IDを指定して何かを取得する」処理がある場所なら、どこでも起きます。

IDを隠しても意味がない

たまに

/users/1 → /users/aj3f9k

のようにIDを隠すケースがあります。

これ自体は悪くないですが、これだけでは解決しません。

アクセス制御がなければ、値を推測された時点で同じ問題が起きます。

まとめ

今回の問題は、特別な攻撃というより

「アクセス制御を書いていない」

ことが原因です。

ログインしているかどうかだけでなく、

「そのデータにアクセスしていいのか」

まで含めて実装する必要があります。

このあたりを意識しておかないと、気づかないうちに穴ができるので注意が必要です。