API Security

APIセキュリティ（API Security）とは、アプリケーションプログラミングインターフェース（API）を不正アクセス、データ漏洩、悪用から保護するための包括的なセキュリティプラクティスです。マイクロサービスアーキテクチャやクラウドネイティブ開発の普及により、APIは現代のシステム間通信の中核を担っており、その攻撃対象面は急速に拡大しています。

OWASP API Security Top 10は、APIに特有のセキュリティリスクを体系的に整理したガイドラインです。従来のOWASP Top 10がWebアプリケーション全般を対象としているのに対し、API Security Top 10はBroken Object Level Authorization（BOLA）、Broken Authentication、Excessive Data Exposureなど、API固有の脆弱性パターンに焦点を当てています。

APIセキュリティでは、認証・認可（OAuth 2.0、APIキー、JWT）、入力検証（スキーマバリデーション）、レート制限（DDoS防御・リソース保護）、APIゲートウェイ（一元的なセキュリティポリシー適用）の4つの柱が重要です。REST APIに加え、GraphQL APIやgRPCなど多様なAPIプロトコルそれぞれに固有のセキュリティリスクが存在し、プロトコルに応じた適切な対策が求められます。

OWASP API Security Top 10

OWASP API Security Top 10（2023年版）は、APIに最も頻出するセキュリティリスクを順位付けしたリストです。第1位のBroken Object Level Authorization（BOLA）は、APIが要求されたオブジェクトへのアクセス権限を適切に検証せず、他のユーザーのデータにアクセスできてしまう脆弱性で、API脆弱性の中で最も多く報告されています。

その他の重要なリスクとして、Broken Authentication（認証メカニズムの欠陥）、Broken Object Property Level Authorization（オブジェクトのプロパティレベルでの認可不備）、Unrestricted Resource Consumption（リソース消費の制限不備）、Broken Function Level Authorization（機能レベルの認可不備）、Server-Side Request Forgery（SSRF）、Security Misconfigurationなどがあります。

REST APIのセキュリティ

REST APIのセキュリティでは、HTTPメソッドの適切な使用と制限が基本です。GETリクエストは副作用のない読み取り操作にのみ使用し、データ変更にはPOST/PUT/PATCH/DELETEを使用します。また、レスポンスに不要なデータを含めない（最小データ原則）、エラーレスポンスにスタックトレースや内部情報を含めない、APIバージョニングにより後方互換性を管理することが重要です。

REST APIでは、URLパスパラメータやクエリパラメータを通じたIDOR（Insecure Direct Object Reference）攻撃に特に注意が必要です。例えば、/api/users/123 のようなエンドポイントで、IDを変更するだけで他のユーザーの情報にアクセスできてしまうケースが多発しています。すべてのエンドポイントでオブジェクトレベルの認可チェックを実装することが不可欠です。

GraphQL APIのセキュリティ

GraphQLはクライアントが必要なデータを柔軟に指定できるクエリ言語ですが、その柔軟性がセキュリティリスクを生みます。深くネストされたクエリによるDoS攻撃（クエリの深さ制限が必要）、イントロスペクションの悪用（本番環境ではイントロスペクションを無効化すべき）、バッチクエリによる認証バイパス（同一リクエスト内で複数のクエリを実行してレート制限を回避）などが代表的です。

GraphQLでは、クエリの複雑さ（depth、breadth、コスト）を分析し、過度に複雑なクエリをブロックするクエリコスト分析の実装が推奨されます。また、Persisted Queries（事前に登録されたクエリのみ実行を許可）を使用することで、任意のクエリ実行による攻撃を防止できます。

API認証（OAuth 2.0 / APIキー / JWT）

OAuth 2.0は、APIの認可フレームワークとして最も広く採用されています。リソースオーナーの認証情報をAPIクライアントに直接共有せずに、限定的なアクセス権限（スコープ）を付与できます。PKCE（Proof Key for Code Exchange）を使用したAuthorization Code Flowが、サーバーサイド・クライアントサイドの両アプリケーションに推奨されます。

APIキーは最もシンプルな認証方式ですが、クライアントの識別には適しているものの、ユーザーの認証・認可には不十分です。APIキーはHTTPヘッダーで送信し、URLパラメータには含めないでください（ログへの記録やリファラー漏洩のリスク）。JWT（JSON Web Token）はステートレスな認証に適していますが、署名検証の省略、alg:noneの許可、シークレットの弱さなどが脆弱性の原因となります。

レート制限とスロットリング

レート制限は、APIに対する過剰なリクエストを防止し、サービスの可用性を保護するための仕組みです。ユーザー単位、IPアドレス単位、APIキー単位など、複数のディメンションでレート制限を適用することで、正当なユーザーへの影響を最小限にしつつ、悪意のあるリクエストを効果的にブロックします。

レート制限の実装には、トークンバケット、リーキーバケット、固定ウィンドウ、スライディングウィンドウなどのアルゴリズムがあります。HTTPレスポンスヘッダー（X-RateLimit-Limit、X-RateLimit-Remaining、Retry-After）を通じてクライアントに制限状況を通知し、429 Too Many Requestsステータスコードで制限超過を伝達することがベストプラクティスです。

APIゲートウェイによるセキュリティ制御

APIゲートウェイは、すべてのAPIリクエストが通過するエントリポイントとして、認証・認可、レート制限、入力検証、ログ記録、暗号化などのセキュリティポリシーを一元的に適用する役割を担います。Kong、AWS API Gateway、Apigee、Azure API Managementなどの製品が広く利用されています。

APIゲートウェイの重要な機能として、リクエスト/レスポンスの変換（機密データのマスキング）、スキーマバリデーション（OpenAPI仕様に基づく入力検証）、mTLS（相互TLS認証によるサービス間通信の保護）、WAF統合（インジェクション攻撃の検出・ブロック）があります。ゼロトラストアーキテクチャにおいて、APIゲートウェイはマイクロセグメンテーションの重要な実施ポイントとなります。

• 01
  すべてのエンドポイントでオブジェクトレベル認可の実装：OWASP API Security Top 10の第1位であるBOLA脆弱性を防止するため、すべてのAPIエンドポイントで、リクエストされたリソースに対するアクセス権限をオブジェクトレベルで検証してください。UUIDなどの推測困難な識別子を使用し、連番IDの使用は避けましょう。
• 02
  OAuth 2.0 + PKCEによる堅牢な認証・認可：APIの認証にはOAuth 2.0のAuthorization Code Flow with PKCEを採用し、アクセストークンのスコープを最小限に設定してください。JWTを使用する場合は、署名アルゴリズムの固定（RS256推奨）、有効期限の短縮、リフレッシュトークンのローテーションを実装しましょう。
• 03
  多層的なレート制限の適用：グローバル、ユーザー単位、エンドポイント単位の複数レベルでレート制限を設定し、DDoS攻撃とブルートフォース攻撃を防止してください。認証エンドポイントには特に厳格なレート制限を適用し、アカウント列挙やクレデンシャルスタッフィングへの耐性を確保しましょう。
• 04
  APIスキーマバリデーションの厳格化：OpenAPI（Swagger）仕様に基づいて、リクエストのボディ、パラメータ、ヘッダーを厳密にバリデーションしてください。許可されていないフィールドの拒否（追加プロパティの禁止）、データ型・長さ・パターンの検証、ネストされたオブジェクトの深さ制限を実装しましょう。
• 05
  APIゲートウェイによるセキュリティポリシーの一元管理：すべてのAPIトラフィックをAPIゲートウェイ経由に集約し、認証・認可・レート制限・ログ記録・WAFルールを一元的に適用してください。バックエンドサービスへの直接アクセスを遮断し、APIゲートウェイが唯一のエントリポイントとなるネットワーク構成を徹底しましょう。
• 06
  APIインベントリの維持とシャドーAPI検出：組織内のすべてのAPIエンドポイントを文書化したAPIインベントリを維持し、未文書化のシャドーAPIやゾンビAPI（廃止されたが稼働中のAPI）を定期的にスキャン・検出してください。APIディスカバリツールを導入し、ネットワークトラフィック分析による未知のAPIエンドポイントの特定を自動化しましょう。