【実務・中級編】 BOLA(Broken Object Level Authorization)の特定と悪用手法 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

APIの「裏口」を塞げ：BOLA（IDOR）を根絶するための実践的防御術

現場でコードを叩いている諸君、お疲れ様。今日は、API開発において「最も見落とされやすく、かつ最も致命的な」脆弱性、BOLA（Broken Object Level Authorization）について話そう。

かつてはIDOR（Insecure Direct Object Reference）と呼ばれていたこの脆弱性は、現在、OWASP API Security Top 10の筆頭に君臨している。なぜか？それは、APIの仕様書通りに機能を作ることに追われ、開発者が「このリクエストを投げているユーザーが、本当にそのIDのリソースにアクセスする権限を持っているか？」という根本的なチェックを、往々にして怠るからだ。

1. BOLAの正体：なぜ「IDを変えるだけ」で突破されるのか

BOLAの攻撃手法はあまりにシンプルだ。例えば、プロフィール情報を取得するAPIがあるとする。

GET /api/v1/users/12345/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer <JWT_TOKEN>

攻撃者は、この 12345 というIDを 12346 や 12347 に書き換える。もしサーバー側が「JWTトークンが有効か」だけを確認し、「そのトークンの持ち主がユーザー12346の情報にアクセスして良いか」を検証していなければ、即座に情報漏洩が成立する。

これが現場で起きる理由：
開発者は「ログインしているか（認証）」と「アクセス権があるか（認可）」を混同しがちだ。認証は通過したが、認可のロジックが抜け落ちている。これがBOLAの正体だ。

2. 脆弱なコードとセキュアな実装の比較

まずは、やってはいけない例から見てみよう。

【脆弱な実装例（Node.js/Express）】

// 注意：これはアンチパターンです
app.get('/api/v1/orders/:orderId', authenticate, (req, res) => {
  // 認証だけして、所有者確認をしていない
  const order = db.orders.findById(req.params.orderId);
  res.json(order);
});

このコードでは、req.params.orderId が誰の注文であろうとデータベースから引き出して返してしまう。

【セキュアな実装例（Node.js/Express）】

認可チェックは、必ず「データベースクエリの条件」に組み込むこと。これが鉄則だ。

app.get('/api/v1/orders/:orderId', authenticate, async (req, res) => {
  // ログインユーザーID（req.user.id）を条件に加える
  const order = await db.orders.findOne({
    where: {
      id: req.params.orderId,
      userId: req.user.id // ここで認可を強制する
    }
  });

  if (!order) {
    // 権限がない、または存在しない場合は404または403を返す
    return res.status(404).json({ error: 'Order not found' });
  }

  res.json(order);
});

このように、userId を条件に加えるだけで、攻撃者は他人のIDを指定しても null が返るため、情報を盗み出せなくなる。

3. インフラ・ミドルウェアでの「多層防御」

アプリケーションコードでの修正が基本だが、万が一の漏れを防ぐためにインフラ側でも対策を打っておくのがプロの仕事だ。

Nginxによるレート制限（攻撃の緩和）

BOLAの悪用は、大量のIDを総当たり（ブルートフォース）で行うケースが多い。NginxでAPI単位のレート制限を厳しく設定しておこう。

# nginx.conf
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;

server {
    location /api/v1/orders/ {
        limit_req zone=api_limit burst=10 nodelay;
        proxy_pass http://backend_app;
    }
}

4. 現場で意識すべき「防御のチェックリスト」

BOLAを防ぐために、明日から以下の項目をコードレビューの基準にしてほしい。

1. 予測不能なIDの使用: 連番（1, 2, 3...）ではなく、UUID（v4以上）を使用する。これは根本解決ではないが、攻撃者がIDを推測するコストを劇的に高める。
2. 所有者チェックの強制: controller層ではなく、service層やリポジトリ層でデータ取得時に必ず owner_id をフィルタリングする設計にする。
3. 認可の集中管理: 認証・認可ライブラリ（Passport.js, CASL, Punditなど）を導入し、個別のコントローラーで if 文を書く文化を排除する。
4. 404 vs 403の使い分け: セキュリティ上、存在しないリソースと権限のないリソースを同じ 404 Not Found として扱うことで、攻撃者に「そのリソースが存在するかどうか」というヒントを与えない手法も有効だ。

最後に：セキュリティは「仕様」の一部である

BOLAを防ぐための修正は、単なる「セキュリティ対策」ではない。それはシステムの整合性を保つための「ビジネスロジック」そのものだ。

「とりあえず動く」コードを書くのは新人でもできる。だが、「誰が、どのデータに、どんな条件でアクセスできるか」を厳密に制御するコードを書くことこそが、我々エンジニアがプロとして誇るべき技術的価値だ。

さあ、今すぐ君の書いたAPIのエンドポイントを一つずつ見直してくれ。IDを書き換えて、自分のデータ以外が見えてしまったら……その夜は眠る前に修正コードをデプロイすることだ。健闘を祈る。