アクセス制御の不備.

アクセス制御の不備は OWASP Top 10(2021)で第 1 位 に上昇し、OWASP がテストしたアプリの 94% で確認され、CWE-284、CWE-639、CWE-862(認可の欠落)を含む 34 の CWE にマッピングされています。これは、アプリが「誰が 何を できるか」を一貫して強制できないときに発生します。すなわち、サーバー側チェックの欠如、隠された URL への依存(隠蔽によるセキュリティ)、クライアント側のロール情報の信頼、あるいは所有者検証を伴わないオブジェクト直接参照の露出などが原因となります。

どこで失敗するか

認可は、すべてのリクエストに対してサーバー側で再評価されなければなりません。よくある失敗は、UI やゲートウェイでのみ認可を強制し、その後クライアントが送信してくる識別子を信頼してしまうことです。攻撃者は単に、別のオブジェクト ID、ロールパラメータ、または HTTP メソッドを付けてリクエストを再送するだけです。

flowchart TD
  A[リクエスト: GET /api/invoice/1043] --> B{認証済みか?}
  B -->|いいえ| R[401 で拒否]
  B -->|はい| C{所有者/ロール検査を<br/>サーバー側で強制しているか?}
  C -->|欠落| L[別テナントに属していても<br/>請求書 1043 を返す]
  C -->|あり| D{主体はオブジェクトを所有<br/>またはロールを持つか?}
  D -->|いいえ| F[403 Forbidden]
  D -->|はい| G[200 リソースを返す]
  L --> X[アクセス制御の不備:<br/>IDOR / データ漏えい]

実際のインシデント

First American Financial の情報漏えい(2019 年)では、典型的な IDOR によって約 8 億 8,500 万件の住宅ローン文書が露出しました。連番形式の URL には認証が不要だったのです。Optus の情報漏えい(2022 年、オーストラリア)では、認証されていない API エンドポイントを介して約 980 万件の顧客レコードが露出しました。USPS Informed Visibility(2018 年)では、ログイン中のあらゆるユーザーが、保護されていない API を通じて他人のアカウントデータを照会できてしまいました。

防御策

集中化されたデフォルト拒否型の認可ミドルウェアを使用する。すべてのサーバー側操作で所有者検証を強制する。不透明またはスコープ化された識別子を優先する。アクセス制御の失敗をログに記録し、異常を検知したらアラートを発する。ディレクトリリスティングを無効化する。JWT/セッションのスコープをサーバー側で無効化する。そして手動のスポットチェックに頼るのではなく、結合テストと継続的な DAST で認可経路を網羅する。