API5:2023 機能レベル認可の不備（Broken Function Level Authorization）

Threat agents / Attack vectors（脅威エージェント／攻撃ベクター）	Security Weakness（セキュリティの弱点）	Impacts（影響）
API 固有：悪用難易度（Exploitability）容易攻撃者は、本来アクセス権のない匿名ユーザーや一般（非特権）ユーザーとして、正当な API 呼び出しを脆弱なエンドポイントへ送るだけでよい。露出したエンドポイントは容易に悪用される。	蔓延度（Prevalence）一般的：検出可能性（Detectability）容易機能やリソースに対する認可チェックは、通常設定またはコードレベルで管理される。現代のアプリは多様なロール／グループ／複雑なユーザ階層（サブユーザー、複数ロール等）を持つため、適切なチェックの実装は混乱しやすい。一方で API は構造化されており、機能へのアクセスが予測しやすいため、こうした欠陥は見つけやすい。	技術的影響（Technical）重大：ビジネス影響（Business）ケース依存この種の欠陥により、攻撃者は権限外の機能にアクセスできる。特に管理機能が主要な標的となり、データ漏えい／消失／改ざんに至る。最終的にはサービス障害を招く可能性もある。

API は脆弱か？

機能レベル認可の欠陥を見つける最良の方法は、ユーザ階層、各種ロール／グループ を踏まえつつ、認可メカニズムを詳細に分析し、次の問いを立てることです：

一般ユーザーが 管理用エンドポイント にアクセスできてしまわないか？
ユーザーが、本来許可されない 機微な操作（作成／変更／削除） を、HTTP メソッドを変えるだけ（例：GET → DELETE）で実行できないか？
グループ X のユーザーが、URL やパラメータ（例：/api/v1/users/export_all）を推測するだけで、本来 グループ Y のみに公開 すべき機能へアクセスできないか？

URL パスだけ を根拠に、そのエンドポイントが一般用か管理用かを 決めつけない こと。

開発者が管理系エンドポイントを /api/admins のような特定の相対パスにまとめることはあるが、実際には /api/users など 一般用と同一パス配下 に管理系が混在していることも非常に多い。

招待ユーザーのみ参加可能なアプリの登録プロセスで、モバイルアプリは GET /api/invites/{invite_guid} を呼び出し、応答 JSON には ユーザーのロール や メール など招待の詳細が含まれる。

攻撃者はリクエストを複製し、HTTP メソッドとエンドポイントを POST /api/invites/new に改ざん。これは 管理コンソール からのみアクセスされるべきエンドポイントだが、機能レベル認可チェックが未実装。

攻撃者は管理権限付きの新規招待を送信して悪用する：

POST /api/invites/new

{
  "email": "attacker@somehost.com",
  "role":"admin"
}

後に攻撃者は、この細工した招待で 管理者アカウント を作成し、システムへ フルアクセス を獲得する。

ある API には、管理者のみに公開すべき GET /api/admin/v1/users/all が存在し、アプリの 全ユーザーの詳細 を返すが、機能レベル認可チェックがない。API 構造を把握した攻撃者が推測アクセスし、機微情報が露出する。

アプリケーションには、全ての業務機能から呼び出される 一貫性があり分析しやすい 認可モジュール を用意すべきです。多くの場合、こうした防御はアプリコード外部のコンポーネントで提供されます。