title: “典型的な API 脆弱性” part: “Part 4” chapter: “4-2”

典型的な API 脆弱性

本章では、OWASP API Security Top 10 で代表される API 特有の脆弱性のうち、本書で特に重視する BOLA、Mass Assignment、Rate Limit 不備などを中心に整理する。

本章のゴール

• 前提：API のアタックサーフェス（前章）を整理でき、Burp Suite 等で API リクエストを再現できる。
• 到達目標：BOLA / Mass Assignment / Rate Limit 不備などの成立条件と検証方針を説明し、仕様と実装の差分からリスクを特定できる。
• 対応演習：exercises/crapi/ を対象に、ID パラメータの変更、想定外フィールドの追加、認証系エンドポイントのレート制限確認などを、合意された範囲で実施し、成立条件を記録する（起動手順は 付録「演習環境クイックスタート」 を参照）。

BOLA（Broken Object Level Authorization）

BOLA は、オブジェクト（リソース）レベルのアクセス制御不備により、他者のデータにアクセスできてしまう脆弱性である。典型的なパターンは次のとおり。

• URI パスに含まれる ID（例：/api/v1/users/123）を変更すると、他ユーザの情報が取得できる
• クエリパラメータや JSON ボディの ID を変更すると、他者の注文やチケットを取得／操作できる

図4-2: BOLA の成立イメージ（概要）

flowchart LR
    U[ユーザA（認証済み）] -->|ID を変更してリクエスト| API[API]
    API --> C{所有者/権限チェック}
    C -->|不備| X[他者リソースが取得/更新される]
    C -->|適切| D[拒否（権限不足）]

図4-2 のポイントは、「ID を推測困難にする」ことではなく、サーバ側で「認証情報（誰か）」と「対象リソース（どれか）」の対応関係を検証できているかである。

Pentest では、次のような手順で検証する。

• 異なるユーザロール（一般ユーザ、管理者など）で同じ API を呼び出し、レスポンス差分を比較する
• ID を連番や推測可能な値に変えて Repeater / Intruder で連続リクエストを行う
• レスポンスコードや本文から、「存在しないリソース」と「権限不足」の扱いが適切かを確認する

根本的な対策は、「ID の形式を変えること」ではなく、「認証情報とリソース所有者をサーバ側で厳密にチェックすること」である。

Mass Assignment（過剰なプロパティバインディング）

Mass Assignment は、フレームワークのオブジェクトバインディング機能により、想定外のフィールドまでクライアント入力で上書き可能となる脆弱性である。

例として、ユーザ更新 API が次のような JSON を受け取る設計を想定する。

{
  "name": "Alice",
  "email": "alice@example.com"
}

しかし、サーバ側のモデルには role や isAdmin などのフィールドが存在し、かつバインディングの制限が行われていない場合、クライアントが次のような JSON を送信することで権限昇格が発生しうる。

{
  "name": "Alice",
  "email": "alice@example.com",
  "role": "admin"
}

Pentest では、OpenAPI 仕様やレスポンスボディ、開発者向けドキュメントからモデルの構造を推測し、「想定されていないフィールド」を追加したリクエストを送信して挙動を確認する。

Rate Limit 不備

レート制限（Rate Limiting）の不備は、単体では脆弱性と認識されにくいが、他の攻撃（認証試行、スクレイピング、リソース枯渇攻撃など）の実現を容易にする。

代表的なケースは次のとおり。

• 認証エンドポイントに対して無制限にパスワード試行が可能
• ワンタイムコードや SMS の再送要求に制限がなく、ブルートフォースが成立する
• 重い処理（レポート生成、画像変換など）を伴う API に対して、リクエスト数制限がない

Pentest では、テスト環境や同意された条件の範囲で、一定時間内に複数のリクエストを送信し、レスポンスやログから制限の有無を確認する。実務環境では、DoS に該当しないよう、事前に上限や監視方法について合意しておく必要がある。

過剰なデータ露出とフィルタリング不備

API においては、クライアント側で不要なフィールドを単に表示しないだけで、バックエンドからはすべて返却しているケースがある。これにより、次のようなリスクが生じる。

• UI では見えないが、レスポンス JSON には内部 ID や機密情報が含まれている
• クエリパラメータで fields や include を指定することで、非公開属性を取得できる

Pentest では、レスポンス JSON の全体を確認し、ビジネス的に不要な情報が含まれていないかをチェックする。必要であれば、クライアント側のフィルタリングを前提とせず、API レイヤでのデータ最小化を推奨する。

セキュリティ設定不備と API 固有のミスコンフィグ

API ゲートウェイや API Management 製品を利用する場合、設定ミスにより以下のような問題が発生することがある。

• 認証を要するエンドポイントが誤って「公開」扱いになっている
• ステージング用・デバッグ用のエンドポイントが本番環境に残っている
• 古いバージョンの API が意図せず公開されたままになっている

これらは API Security Top 10 の API8: Security Misconfiguration や API9: Improper Inventory Management に該当する。OpenAPI 仕様や DNS、ログを参考に、「存在しているが利用されていないエンドポイント」「ドキュメント外の API」がないかを確認する。

次に読む章

• OAuth2 / OIDC / 外部 ID 連携のテスト

本章のポイント

• BOLA は「ID を隠す」問題ではなく「サーバ側の所有者・権限チェック」問題であり、複数ロールでの差分比較と ID 操作で成立条件を確認する。
• Mass Assignment はバインディング制御の不足で発生するため、仕様・レスポンスから推定したフィールドを追加して挙動を観察する。
• レート制限不備、過剰なデータ露出、設定不備／棚卸し不備は複合的にリスクを高めるため、合意された範囲で負荷に配慮しつつ確認する。