OWASP API Security Top 10とは？BOLA・認証不備・過剰データ露出の仕組みと防御策をわかりやすく解説

自社のWebサービスやシステムにAPIを組み込んでいる企業は多いですが、「APIはファイアウォールの内側だから安全」という認識は危険です。現代のサイバー攻撃では、APIそのものを直接狙う手口が急増しており、認証不備や認可の設計ミスが大規模なデータ漏洩に直結した事例は国内外で後を絶ちません。

この記事では、OWASP API Security Top 10（OWASPのAPIセキュリティ脅威ランキング）について、各項目の仕組みと現場で使える防御策を解説します。Webアプリケーション開発者・インフラエンジニア・社内情シスのいずれにも役立つ内容にまとめました。

OWASP API Security Top 10とは？

OWASP（Open Web Application Security Project）は、ソフトウェアのセキュリティ向上を目的とした国際的な非営利団体です。OWASP API Security Top 10は、API特有の脅威を体系化したリストで、2019年に初版が公開され、2023年に改訂されました。

Webアプリ全般向けの「OWASP Top 10」とは別に、APIに特有のリスク10項目を定義しています。REST API・GraphQL API・SOAP Webサービスなど、多様なAPI形式に共通して適用できる考え方です。

なぜAPIセキュリティが今これほど重要なのか

マイクロサービス化・クラウドネイティブ化・スマートフォンアプリの普及により、現代のシステムはAPIを中心に設計されています。その結果として：

・攻撃面の拡大: APIエンドポイントが増えるほど、攻撃者の侵入口も増える
・認証・認可ロジックの複雑化: マイクロサービス間の連携でアクセス制御が設計しにくい
・スキャナの限界: 自動スキャンツールはAPIの業務ロジック上の欠陥を見落としやすい
・データの直接漏洩: APIはデータベースの値を直接返すことが多く、漏洩した場合のインパクトが大きい

既存のWAF（Webアプリケーションファイアウォール）だけでは対処しきれないAPIセキュリティの死角を、OWASP API Security Top 10は体系的に整理しています。

OWASP API Security Top 10の全項目と仕組み

1. BOLA（Broken Object Level Authorization）: オブジェクトレベル認可の不備

最も発生頻度が高く、深刻な脆弱性です。APIエンドポイントがリクエストしてきたユーザーに「そのオブジェクトへのアクセス権があるか」を確認していない状態です。

想定例: `/api/orders/12345` という注文APIで、注文ID「12345」を「12346」「12347」と変えるだけで他ユーザーの注文情報が取得できてしまう設計はBOLAの典型です。

対策:
・リクエストごとの認可チェック: ユーザーのセッション情報と取得対象オブジェクトの所有者を毎回照合する
・予測困難なIDの使用: 連番IDの代わりにUUID等のランダムな値を使用する
・アクセス制御テストの自動化: テストスイートで「他ユーザーのオブジェクトを取れないか」を継続的に確認する

2. Broken Authentication: 認証の不備

APIの認証メカニズムに欠陥があり、不正にセッションを乗っ取られたりアカウントに侵入されたりするリスクです。

典型的なパターンとして：パスワードリセットフローの設計ミス、短すぎるセッショントークン、期限切れのトークンが失効処理されていない、などが挙げられます。

対策:
・標準的な認証フレームワークの活用: OAuth 2.0・OpenID Connectなど実績ある仕様に準拠する
・ブルートフォース対策: レート制限とアカウントロックを組み合わせる
・トークン管理の厳格化: JWTの署名アルゴリズムを適切に設定し、期限切れトークンはサーバー側で無効化する

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

2023年版で新設された項目で、旧版の「Excessive Data Exposure（過剰データ露出）」と「Mass Assignment（一括代入）」を統合したものです。

・過剰データ露出: APIがクライアントに必要以上のデータを返し、秘密情報が含まれているケース
・一括代入: クライアントから送られてきたJSONオブジェクトをそのままモデルに代入し、管理者フラグ等の書き換えを許してしまうケース

対策:
・レスポンスフィルタリング: 必要な項目だけを明示的に選んで返す（全フィールドを自動で返さない）
・入力値の許可リスト管理: 更新可能なフィールドを明示的に定義し、それ以外を無視する

4. Unrestricted Resource Consumption: リソース消費の無制限

APIに適切なレート制限・クエリ制限がなく、大量リクエストで費用が爆発したり、サービスが停止したりするリスクです。クラウドAPIでは金銭的被害（請求額の急増）にも直結します。

対策:
・レート制限の実装: IPアドレスやユーザーごとにリクエスト数の上限を設ける
・クエリ複雑度の制限: GraphQL APIではクエリの深さ・フィールド数に上限を設ける
・ページネーションの強制: 一度に返せるレコード数に上限を設ける

5. Broken Function Level Authorization: 関数レベル認可の不備

管理者向けAPIエンドポイントへ一般ユーザーがアクセスできてしまう問題です。エンドポイントのURLを推測または発見した攻撃者が、権限外の操作（ユーザー削除・設定変更等）を実行できます。

想定例: `/api/users/list`（一般ユーザー向け）の隣に `/api/admin/users/list`（管理者向け）が存在し、後者に認証はあっても認可チェックが甘い設計。

対策:
・ロールベースアクセス制御（RBAC）: エンドポイントごとに必要ロールを明確に定義し、ミドルウェアで一元的にチェックする
・管理APIの分離: 管理機能は別ドメイン・別サービスに分離し、社内ネットワークからのみアクセス可能にする

6. Unrestricted Access to Sensitive Business Flows: 機密ビジネスフローへの無制限アクセス

APIが技術的には正常動作していても、業務ロジック上悪用できてしまうケースです。ボット（自動化ツール）による大量リクエストが典型で、フラッシュセール時の先買い・OTPの総当たり・招待コードの使い回しなどに悪用されます。

対策:
・リクエストパターンの監視: 通常ユーザーでは不自然な操作速度・順序を検知する
・CAPTCHAや端末フィンガープリント: 人間の操作かボットかを区別する仕組みを組み込む

7. Server Side Request Forgery（SSRF）: サーバーサイドリクエストフォージェリ

クライアントが指定したURLにサーバーがリクエストを送信する機能を悪用し、内部ネットワークのシステムや クラウドのメタデータAPIにアクセスさせる攻撃です。

クラウド環境では `http://169.254.169.254/` のようなインスタンスメタデータAPIを経由してクラウドサービスの認証情報が取得される場合があります。

対策:
・URLの許可リスト管理: サーバーがアクセスして良いドメイン・IPレンジを明示的に制限する
・プライベートIPへのアクセス禁止: 10.0.0.0/8・172.16.0.0/12・169.254.0.0/16等のIPへのリクエストを拒否する

8. Security Misconfiguration: セキュリティの設定ミス

APIサーバーやフレームワークの設定ミスが原因で生じる脆弱性です。具体的には：

・不必要なHTTPメソッドの許可: PUTやDELETEが不要なエンドポイントで有効になっている
・詳細なエラーレスポンス: スタックトレース・DBエラー詳細がクライアントに返ってしまう
・CORSの過剰許可: `Access-Control-Allow-Origin: *` で全オリジンを許可してしまっている
・古いTLSバージョンの許可: TLS 1.0/1.1が無効化されていない

対策:
・必要なHTTPメソッドのみを許可するように設定する
・本番環境ではエラーの詳細をクライアントに返さず、ログにのみ記録する
・CORSポリシーを最小限に絞る

9. Improper Inventory Management: 不適切なインベントリ管理

廃止された旧バージョンのAPIや、テスト用APIエンドポイントが本番環境に残ったままになっているリスクです。古いAPIはセキュリティパッチが当たっておらず、攻撃者の格好の標的になります。

対策:
・APIドキュメントの自動生成と管理: 公開中の全エンドポイントをOpenAPI等で管理し、廃止エンドポイントを確実に削除する
・APIバージョニングポリシーの策定: v1をいつ廃止するかの基準とスケジュールを明文化する
・定期的なAPI棚卸し: 四半期ごとに全APIエンドポイントを見直し、不要なものを削除する

10. Unsafe Consumption of APIs: APIの安全でない利用

自社APIへの攻撃だけでなく、自社システムが外部API（サードパーティAPI）を利用する際のリスクです。外部APIのレスポンスをそのまま信頼して処理することで、インジェクション攻撃やリダイレクト攻撃の踏み台になる場合があります。

対策:
・外部APIレスポンスの検証: 受け取ったデータをそのまま使わず、スキーマ・型・値の範囲を検証する
・サードパーティAPIのリスク評価: 利用開始前にセキュリティポリシー・認定情報を確認する
・タイムアウトとフォールバック: 外部API呼び出しには必ずタイムアウトを設け、応答不能時の挙動を設計する

中小企業でも今日からできる防御のポイント

OWASP API Security Top 10を見ると項目が多く感じるかもしれませんが、まず優先すべき対策は絞れます。

特にBOLAは「技術的な設定ミス」ではなく「設計レベルの認可漏れ」であるため、フレームワーク任せにできません。エンドポイントを新規作成するたびに「認可チェックが入っているか」をコードレビューで確認する習慣をつけることが最も効果的です。

よくある誤解と注意点

誤解1: 「JWTを使っているから認証は安全」
JWTはトークンの形式を定める仕様であり、認可（誰が何にアクセスできるか）の設計はAPI側の責務です。JWTで「誰か」は判断できても「そのリソースへのアクセス権があるか」はAPIロジックで別途チェックが必要です。

誤解2: 「APIドキュメントを公開しなければ攻撃されない」
攻撃者はブラウザの通信ログやモバイルアプリの解析からAPI仕様を推測します。APIの秘匿化（隠蔽によるセキュリティ）は防御として信頼できません。適切な認可設計こそが根本的な対策です。

誤解3: 「WAFがあれば外部からのAPI攻撃は防げる」
WAFはシグネチャベースで既知の攻撃パターンを検知しますが、BOLA・機能レベル認可の不備・業務ロジック悪用は正常に見えるリクエストで実行されるため、WAFでは検知・防御できません。

本記事のまとめ

OWASP API Security Top 10（2023年版）を中心に、APIセキュリティの主要な脅威と対策を解説しました。

・BOLA（オブジェクトレベル認可の不備）: 最も頻度が高く危険。リクエストごとの所有者チェックが必須
・認証の不備: 標準的な認証仕様への準拠とトークン管理の厳格化で対応
・過剰データ露出・一括代入: レスポンスの最小化と入力の許可リスト管理で防ぐ
・設定ミス: エラーレスポンス・CORSポリシー・不要メソッドの見直しを定期的に行う
・インベントリ管理不備: 全APIエンドポイントを可視化し、廃止エンドポイントを確実に削除する

APIは現代のシステムの心臓部です。「使えればいい」から「安全に使える」設計への意識転換が、インシデントを未然に防ぐ第一歩です。

WebアプリケーションのAPIセキュリティをより深く理解するには、姉妹サイトAPIセキュリティとは？REST APIを狙う攻撃手法と防御策も参考にしてください。