API1:2023 オブジェクトレベル認可の不備（Broken Object Level Authorization）
| Threat agents / Attack vectors（脅威エージェント／攻撃ベクター） | Security Weakness（セキュリティの弱点） | Impacts（影響） |
|---|---|---|
| API 固有：悪用難易度（Exploitability） 容易 攻撃者は、リクエスト内で送信されるオブジェクトの ID を改ざんすることで、オブジェクトレベル認可が破られた API エンドポイントを悪用できます。オブジェクト ID は連番の整数、UUID、汎用文字列など何でもあり得ます。データ型に関わらず、ID はリクエストターゲット（パスやクエリパラメータ）、リクエストヘッダ、あるいはリクエストペイロードの一部から容易に特定できます。 |
蔓延度（Prevalence） 広範 ： 検出可能性（Detectability） 容易 この問題は API ベースのアプリで極めて一般的です。サーバ側コンポーネントはクライアントの状態を完全には追跡せず、どのオブジェクトにアクセスするかの判断を、クライアントから送られるオブジェクト ID のようなパラメータに依存しがちだからです。さらに、サーバの応答からはリクエストの成否が容易に推測できます。 |
技術的影響（Technical） 中程度 ： ビジネス影響（Business） ケース依存 他ユーザーのオブジェクトへの不正アクセスは、権限のない第三者へのデータ漏えい、データ消失、データ改ざんを招きます。状況によっては、完全なアカウント乗っ取りにつながることもあります。 |
API は脆弱か？
オブジェクトレベル認可は、ユーザーが自分に権限のあるオブジェクトにのみアクセスできることを検証する、コードレベルで実装されるアクセス制御メカニズムです。
オブジェクトの ID を受け取り、そのオブジェクトに対して何らかの操作を行う すべての API エンドポイント は、オブジェクトレベルの認可チェックを実装すべきです。チェックでは、ログイン中のユーザーが、要求されたオブジェクトに対して要求された操作を実行する権限を持つことを検証します。
このメカニズムが破綻すると、一般に、すべてのデータに対する不正な情報開示、変更、破壊につながります。
現在のセッションのユーザー ID（例：JWT トークンから抽出）と、脆弱な ID パラメータを比較するだけでは、BOLA（Broken Object Level Authorization）の解決策として 不十分 です。このアプローチで対処できるのはごく一部のケースに限られます。
BOLA の場合、設計上ユーザーは脆弱な API エンドポイント／関数にアクセスできます。違反は、ID を改ざんして オブジェクトレベル で発生します。攻撃者が本来アクセスできない API エンドポイント／関数にアクセスできてしまう場合は、BOLA ではなく 機能レベル認可の不備（Broken Function Level Authorization）（BFLA）の事例です。
攻撃シナリオ例
シナリオ #1
オンラインストア（ショップ）向けの EC
プラットフォームが、ホストしているショップの売上チャートを表示する一覧ページを提供している。ブラウザのリクエストを調べると、チャートのデータソースとなる
API エンドポイントとそのパターン /shops/{shopName}/revenue_data.json
を特定できる。別の API
エンドポイントからは、すべてのホスト済みショップ名の一覧を取得可能。簡単なスクリプトで一覧中の名前を差し替え、URL
の {shopName} を入れ替えるだけで、攻撃者は数千の EC
ストアの売上データにアクセスできてしまう。
シナリオ #2
自動車メーカーが、運転者のスマートフォンと通信するモバイル API による車両のリモート制御を有効化している。API はエンジンの遠隔始動／停止、ドアの施錠／解錠を可能にする。このフローの一部として、ユーザーは車両識別番号（VIN）を API に送信する。しかし API は、その VIN がログイン中のユーザーに紐づく車両であることを検証せず、BOLA の脆弱性が生じている。攻撃者は自分のものではない車両にアクセスできてしまう。
シナリオ #3
オンライン文書ストレージサービスは、ユーザーが文書の閲覧、編集、保存、削除を行える。ユーザーの文書が削除されるとき、文書 ID を含む GraphQL のミューテーションが API に送られる。
bash
Copy code
POST /graphql { "operationName":"deleteReports", "variables":{ "reportKeys":["<DOCUMENT_ID>"] }, "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { { deleteReports(reportKeys: $reportKeys) } }" }
指定された ID の文書が、追加の権限チェックなしに削除されるため、ユーザーは他ユーザーの文書を削除できてしまう可能性がある。
防止方法（How To Prevent）
- ユーザーポリシーや階層に基づく、適切な認可メカニズムを実装する。
- クライアントからの入力を用いてデータベース内のレコードへアクセスする あらゆる関数 で、その認可メカニズムにより、ログイン中ユーザーが要求された操作をそのレコードに対して実行できるかを確認する。
- レコード ID には、ランダムで予測不能な GUID などの値を使用することを推奨する。
- 認可メカニズムの脆弱性を評価するテストを書き、テストが失敗する変更はデプロイしない。