OWASP API Security Top 10の概要とベスト プラクティス

不正なアクセスや操作、露出からデータを守り、プライバシーを確保してユーザーとステークホルダーの信頼を維持し、APIの機密性、整合性、可用性を確保するには、堅牢なAPIセキュリティ対策が必要です。APIセキュリティのベスト プラクティスには次のようなものがあります。

• 強力な認証と認可を実施する。適切な認可チェックを実行して、認証されたクライアントが特定のリソースにアクセスしたりアクションを実行したりするために必要な権限を持っていることを確認します。きめ細かいアクセス制御を使用して、機密性の高いAPIエンドポイントやデータ、関連するオブジェクトや機能へのアクセスを制限します。
• 入力と出力のエンコーディングを検証する。APIクライアントから受け取ったすべての入力を検証してサニタイズすることで、インジェクション攻撃を防ぎ、出力を適切にエンコードして悪意あるスクリプトの実行を阻止します。
• 安全な通信を使用する。APIクライアントとサーバ間のデータ送信に安全性の高いプロトコルを使用し、転送中と保管中の機密情報を暗号化してデータの機密性と整合性を確保します。
• レート制限と調整を行う。APIクライアントが指定の時間枠内で行うことのできるリクエスト数に制限を設けて、分散型サービス拒否（DDoS）攻撃やブルート フォース攻撃など、過剰使用や不正アクセスの試みを阻止します。
• 定期的なセキュリティ テストと監査を行う。セキュリティ評価、侵入テスト、コード レビューを定期的に実施して、APIの潜在的な脆弱性を特定して対処します。また、セキュリティ監査を実施して、弱点を見つけ、業界標準や指令を確実に遵守します。これは、APIと、基盤となるフレームワークやライブラリの相互依存性を考えれば、特に重要です。
• スキーマとプロトコルを遵守する。OpenAPI仕様に従ってポジティブ セキュリティ モデルを自動的に作成して実施することは、一貫したセキュリティ ポリシーを確立する上で重要です。
• APIを動的に検出して継続的に評価する。APIが急増することで、シャドーAPIなど、用途不明のAPIや管理対象から外れたAPIが生まれています。セキュリティ管理では、ゼロ トラストや最小権限アクセスのパラダイムに従ってAPIの現状を常に確認して保護することで、サードパーティとの相互依存関係がもたらす見えないリスクを緩和する必要があります。
• 包括的に脅威を検知する。APIは、セキュリティ上の弱点、設定ミス、ボット、不正行為、悪用などのさまざまな脅威にさらされやすく、これらから保護する必要があります。

2023年版OWASP API Security Top 10は、APIセキュリティの一般的な弱点に対する意識を高め、APIの開発と保守に携わる開発者、設計者、アーキテクト、管理者などがAPIセキュリティに対するプロアクティブなアプローチを維持できるよう支援することを目的として作成されました。

2023年版OWASP API Security Top 10のリスクは次のとおりです。

1. オブジェクト レベルでの認可の不備。このセキュリティ脆弱性は、アプリケーションがオブジェクト レベルやデータ レベルでアクセス制御を適切に実施しない場合に発生します。これにより、攻撃者が認可チェックを操作または回避し、アプリケーション内で特定のオブジェクトやデータに対して不正にアクセスすることを許す恐れがあります。この脆弱性の原因としては、認可チェックの不適切な実装、適切な検証の欠落、アクセス制御の回避などが挙げられます。オブジェクトのIDを受け取り、そのオブジェクトに対して何らかのアクションを実行するすべてのAPIエンドポイントに、オブジェクトレベルの認可チェックを実装して、要求されたオブジェクトに対して要求されたアクションを実行する権限がログイン ユーザーにあることを検証しなければなりません。
2. 認証の不備。APIの認証メカニズムの実装が不適切であることが多く、これにより、攻撃者がユーザー アカウントや機密データに不正にアクセスしたり、不正なアクションを実行したりすることを許す恐れがあります。この脆弱性は通常、認証プロセスの実装や設定のミス、脆弱なパスワード ポリシー、セッション管理の欠陥、認証ワークフローのその他の弱点などが原因で発生します。
3. オブジェクト プロパティ レベルでの認可の不備。この脅威は、APIがオブジェクト プロパティ レベルでアクセス制御と認可チェックを適切に実施しない場合に発生します。機密性が高く、読み取られるべきでないとユーザーが見なすオブジェクトのプロパティがAPIエンドポイントで露出されている場合、APIエンドポイントはこれらの攻撃に対して脆弱になります。この脆弱性は「データの過度な露出」とも呼ばれます。またAPIエンドポイントで機密性の高いオブジェクトのプロパティの値をユーザーが変更、追加、削除できる場合も、APIエンドポイントはこれらの攻撃に対して脆弱になります。この脆弱性は「Mass Assignment」とも呼ばれます。
4. 制限のないリソース消費。この攻撃は、「リソース枯渇攻撃」とも呼ばれ、API実装の弱点を突いて、CPU、メモリ、帯域幅などのリソースやその他のシステム リソースを意図的に過剰に消費します。このサービス拒否（DoS）攻撃はAPIや基盤システムのパフォーマンスや可用性を低下させ、ダウンタイムを招く可能性があります。
5. 機能レベルでの認可の不備。この脅威は、APIが機能レベルや操作レベルで認可チェックを適切に実施しない場合に発生し、これによって、攻撃者が未認可の機能にアクセスするのを許す恐れがあります。適切な認可チェックの実装は複雑な作業です。それは、最新のアプリケーションでは、さまざまなタイプの機能的な役割やグループを定義することができ、ユーザー階層が複雑であるためであり、これらを攻撃者が操作する可能性があります。
6. 機密性の高いビジネス フローへの制限のないアクセス。この攻撃は、APIに適切なアクセス制御や認可チェックが欠落している場合に発生し、これによって、そのAPIを基盤とする機密性の高いビジネス フローへのアクセスを攻撃者が自動化することを許す恐れがあります。これらのビジネス フローが、チケットやスニーカーといった高額で希少な商品の大量購入に利用されると、二次市場で高値で転売される可能性があります。標的となったWebアプリケーションが自動化対策で適切に保護されていると、攻撃者は高度な自動化ツールキットを使用して攻撃の手口を変えることが多く、標的をAPIの背後にあるビジネス ロジックに変える場合があります。
7. Server-Side Request Forgery（SSRF）。この脆弱性は、ユーザー指定のURLを受け入れたり、外部リソースに対してサーバ側リクエストを実行したりする脆弱なAPIエンドポイントを攻撃者が特定した場合に発生します。攻撃者は、標的とする内部リソースやシステムのURLを指定した悪意のあるリクエストを作成します。サーバは、その悪意に気付くことなく、指定されたURLに対するサーバ側リクエストを実行して、機密情報やサービスを露出させてしまう可能性があります。
8. セキュリティの設定ミス。攻撃者は、パッチが適用されていない欠陥、共通のエンドポイント、安全性の低いデフォルト設定で実行されているサービス、保護対策が講じられていないファイルやディレクトリを見つけ出して、APIへの不正アクセスを試みます。この脆弱性は、ネットワーク レベルからアプリケーション レベルまで、APIスタックのいずれかのレベルでセキュリティが十分に強化されていない場合や、クラウド サービスの権限が適切に設定されていない場合に発生します。設定ミスはWebアプリケーションやAPIに影響を及ぼし、アーキテクチャが分散化してマルチクラウド環境全体に広がるにつれてリスクは増大します。
9. 不適切なインベントリ管理。APIは時間の経過とともに変更され更新されるものですが、APIの古いバージョンや安全でないバージョンが本番環境に残されている場合や、古いエンドポイントがパッチを適用されずに運用されていたり、脆弱なセキュリティ要件下で運用されていたりする場合があり、これらはセキュリティ侵害のリスクを高めます。適切なインベントリ管理が行われていないと、どのバージョンが使用されているのか、どのバージョンが古いのか、廃止予定なのか、どの脆弱性が対処済みなのかを追跡することが難しくなります。シャドーAPIやゾンビAPIは重大なリスクを引き起こすため、継続的な検出と保護の自動化が重要です。
10. APIの安全でない使用。開発者は、サードパーティのAPI、特に有名企業が提供するAPIから受け取ったデータを信頼する傾向があり、入力の検証やサニタイズ、トランスポート セキュリティの点でこのようなデータのセキュリティ要件が脆弱になりがちです。この脆弱性は、安全性の低いプロトコルを使用してAPIにアクセスした場合や適切な暗号化メカニズムを使用していない場合にも発生し、盗聴、データ傍受、機密情報への不正アクセスなどを招きます。