API3:2023 オブジェクトプロパティレベル認可の不備（Broken Object Property Level Authorization）

Threat agents / Attack vectors（脅威エージェント／攻撃ベクター）	Security Weakness（セキュリティの弱点）	Impacts（影響）
API 固有：悪用難易度（Exploitability）容易 API は、オブジェクトのすべてのプロパティを返すエンドポイントを公開しがちです（特に REST）。GraphQL など他のプロトコルでは、返すプロパティを指定する細工が必要になる場合があります。操作可能な追加プロパティの特定には手間がかかりますが、支援する自動化ツールも存在します。	蔓延度（Prevalence）一般的：検出可能性（Detectability）容易 API レスポンスを観察するだけで、返却オブジェクト表現中の機微情報を見つけられます。追加（隠し）プロパティの特定にはファジングがよく使われます。変更可能かどうかは、API リクエストを作り分けてレスポンスを分析すれば判断できます。対象プロパティがレスポンスに返らない場合は副作用の分析が必要です。	技術的影響（Technical）中程度：ビジネス影響（Business）ケース依存私的／機微なオブジェクトプロパティへの不正アクセスは、データ漏えい・消失・破損を招きます。状況によっては権限昇格やアカウントの部分的／完全な乗っ取りにつながることもあります。

API は脆弱か？

API エンドポイントでユーザーにオブジェクトへのアクセスを許す際は、アクセス対象の各プロパティ について、ユーザーがアクセス可能かを検証することが重要です。

次のような場合、API エンドポイントは脆弱です：

ユーザーが読むべきでない 機微なプロパティ を公開している（旧称：「Excessive Data Exposure」）。
ユーザーがアクセスすべきでない機微なプロパティの 変更／追加／削除 を許している（旧称：「Mass Assignment」）。

攻撃シナリオ例

シナリオ #1

ある出会い系アプリでは、不適切行為のユーザーを通報できる。ユーザーが「報告」ボタンを押すと、次の API 呼び出しが行われる：

POST /graphql
{
  "operationName":"reportUser",
  "variables":{
    "userId": 313,
    "reason":["offensive behavior"]
  },
  "query":"mutation reportUser($userId: ID!, $reason: String!) {
    reportUser(userId: $userId, reason: $reason) {
      status
      message
      reportedUser {
        id
        fullName
        recentLocation
      }
    }
  }"
}

このエンドポイントは、認証済みユーザーに対し、本来アクセスできないはずの「fullName」「recentLocation」といった 機微な（通報された）ユーザーオブジェクトのプロパティ を返してしまうため脆弱です。

シナリオ #2

宿泊提供者（“host”）がゲストの予約を承認してから課金する仕組みのオンラインマーケットプレイス。フローの一部として、ホストは次の正当なペイロードで POST /api/host/approve_booking を送る：

{
  "approved": true,
  "comment": "Check-in is after 3pm"
}

ホストがこの正当なリクエストをリプレイし、次の悪意あるペイロードを追加する：

{
  "approved": true,
  "comment": "Check-in is after 3pm",
  "total_stay_price": "$1,000,000"
}

エンドポイントは、ホストが内部プロパティ total_stay_price にアクセス（変更）できるべきか検証しておらず脆弱です。その結果、ゲストは本来より高額を請求されます。

シナリオ #3

短編動画ベースのソーシャルネットワークが厳格なコンテンツフィルタリング／検閲を行っている。動画がブロックされても、ユーザーは次のリクエストで説明文を変更できる：

PUT /api/video/update_video

{
  "description": "a funny video about cats"
}

不満を持つユーザーが、上記の正当なリクエストをリプレイし、次の悪意あるペイロードを追加する：

{
  "description": "a funny video about cats",
  "blocked": false
}

エンドポイントは、ユーザーが内部プロパティ blocked にアクセス（変更）できるべきかを検証しておらず脆弱です。ユーザーは true を false に変更して、自身のブロックされたコンテンツを解除できてしまいます。

防止方法（How To Prevent）

API でオブジェクトを公開する際は、公開する各プロパティ に対してユーザーがアクセス可能か常に確認する。
to_json() や to_string() のような 汎用メソッドを避け、返却したいプロパティを ホワイトリスト方式（選択方式） で明示する。
可能なら、クライアント入力をコード変数／内部オブジェクト／オブジェクトプロパティに自動バインドする関数（Mass Assignment）を避ける。
クライアントが更新すべき 限定されたプロパティのみ 変更を許可する。
追加の防御層として スキーマベースのレスポンス検証 を実装し、すべての API メソッドで返却データを定義・強制する。
エンドポイントの業務要件／機能要件に従い、返却データ構造は 最小限 に保つ。