| API1:2023 – 破損したオブジェクトレベル認可 |
APIはしばしばオブジェクト識別子を処理するエンドポイントを公開し、オブジェクトレベルのアクセス制御の問題の広範な攻撃面を作成します。オブジェクトレベルの認可チェックは、ユーザーからのIDを使用してデータソースにアクセスするすべての機能で考慮されるべきです。 |
| API2:2023 – 破損した認証 |
認証メカニズムはしばしば誤って実装され、攻撃者が認証トークンを妥協したり、実装の欠陥を悪用して一時的または永久的に他のユーザーの身分を偽装することを可能にします。クライアント/ユーザーの識別能力を妥協させることは、全体的なAPIセキュリティを損ないます。 |
| API3:2023 – 破損したオブジェクトプロパティレベルの認可 |
このカテゴリはAPI3:2019 過剰なデータ露出とAPI6:2019 – マスアサインメントを結合し、根本原因に焦点を当てます：オブジェクトプロパティレベルでの適切な認可検証の欠如または不適切な使用。これにより、不正な第三者による情報の露出や操作が引き起こされることがあります。 |
| API4:2023 – 制限のないリソース消費 |
APIリクエストの満足にはネットワーク帯域幅、CPU、メモリ、ストレージなどのリソースが必要です。その他のリソース（電子メール/SMS/電話、バイオメトリックス検証など）は、サービスプロバイダーによってAPI統合経由で利用可能にされ、リクエストごとに支払われます。成功した攻撃は、サービス不能（DoS）や運用コストの増加につながる可能性があります。 |
| API5:2023 – 破損した関数レベルの認可 |
複雑なアクセス制御ポリシー、異なる階層、グループ、役割、および管理機能と通常の機能の明確な分離の不明瞭さは、認可の欠陥につながる傾向があります。これらの問題を悪用することで、攻撃者は他のユーザーのリソースや管理機能にアクセスすることができます。 |
| API6:2023 – 機密ビジネスフローへの制限のないアクセス |
このリスクに対する脆弱なAPIは、チケットの購入やコメントの投稿などのビジネスフローを露出し、自動化された方法で過度に使用された場合にビジネスにどのように害を及ぼすかを考慮していません。これは必ずしも実装のバグから来るものではありません。 |
| API7:2023 – サーバーサイドリクエストフォージェリ |
サーバーサイドリクエストフォージェリ（SSRF）の欠陥は、APIがユーザー提供のURIを検証せずにリモートリソースを取得する場合に発生します。これにより、アタッカーはアプリケーションを強制して、ファイアウォールやVPNで保護されている場合でも予期しない宛先に作成されたリクエストを送信させることができます。 |
| API8:2023 – セキュリティ設定の誤構成 |
APIとそれをサポートするシステムは通常、APIをよりカスタマイズ可能にするための複雑な設定を含んでいます。ソフトウェアおよびDevOpsエンジニアは、これらの設定を見落とすことがあり、または設定に関するセキュリティベストプラクティスに従わないことで、さまざまなタイプの攻撃の可能性を開放することになります。 |
| API9:2023 – 適切でない在庫管理 |
APIは従来のWebアプリケーションよりも多くのエンドポイントを公開する傾向があり、正確で更新されたドキュメントの重要性が非常に高いです。ホストと展開されたAPIバージョンの適切な在庫管理も、廃止されたAPIバージョンや露出されたデバッグエンドポイントなどの問題を緩和するために重要です。 |
| API10:2023 – APIの安全でない利用 |
開発者は通常、ユーザー入力よりもサードパーティAPIから受け取ったデータを信頼しています。そのため、攻撃者は対象のAPIを直接妥協しようとする代わりに、統合されたサードパーティサービスを狙います。 |
