脅威エージェント / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 容易 普及度 一般的：検出可能性 容易 技術的 重大：特定のビジネスに依存 攻撃者はしばしば未修正の欠陥、一般的なエンドポイント、不安全なデフォルト構成で実行されているサービス、または保護されていないファイルおよびディレクトリを見つけ出して、システムへの未承認アクセスや情報収集を試みます。これらのほとんどは公開されており、その悪用可能性があるかもしれません。 セキュリティの誤構成は、APIスタックの任意のレベルで発生する可能性があります。不要なサービスやレガシーオプションなど、誤構成を検出および悪用するための自動化ツールが利用可能です。 セキュリティの誤構成は、敏感なユーザーデータだけでなく、システムの詳細を露呈し、完全なサーバーの妥協につながる可能性があります。 APIは脆弱ですか？ APIが脆弱である可能性があるのは、以下の場合です： APIスタックの任意の部分で適切なセキュリティの強化が欠けている場合、またはクラウドサービスの許可が不適切に構成されている場合 最新のセキュリティパッチが欠落しているか、システムが更新されていない場合 不要な機能が有効になっている場合（例：HTTP動詞、ログ機能） HTTPサーバーチェーン内のサーバーが入力リクエストを処理する方法に不一致がある場合 Transport Layer Security（TLS）が欠落している場合 セキュリティまたはキャッシュ制御の指令がクライアントに送信されていない場合 Cross-Origin Resource Sharing（CORS）ポリシーが欠落しているか、適切に設定されていない場合 エラーメッセージにスタックトレースが含まれているか、他の敏感な情報が露呈している場合 攻撃シナリオの例 シナリオ #1 APIバックエンドサーバーは、人気のあるサードパーティオープンソースのログ記録ユーティリティで保持されています。このユーティリティはデフォルトでプレースホルダーの展開とJNDI（Java Naming and Directory Interface）ルックアップのサポートを提供しています。各リクエストに対して、以下のパターンでアクセスログファイルに新しいエントリが書き込まれます：<method> &

脅威エージェント / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 容易 普及度 一般的：検出可能性 容易 技術的 中程度：特定のビジネスに依存 攻撃者はクライアントが提供するURIにアクセスするAPIエンドポイントを見つける必要があります。一般的なSSRF（レスポンスが攻撃者に返される場合）は、攻撃が成功したかどうかのフィードバックがないブラインドSSRFよりも容易に悪用できます。 現代のアプリケーション開発の概念では、開発者にクライアントが提供したURIにアクセスすることが推奨されています。そのようなURIの欠如または不適切な検証は一般的な問題です。問題の検出には定期的なAPIリクエストとレスポンスの分析が必要です。レスポンスが返されない（ブラインドSSRF）場合、脆弱性を検出するにはより多くの労力と創造力が必要です。 成功した悪用は、内部サービスの列挙（例：ポートスキャン）、情報開示、ファイアウォールの回避、またはその他のセキュリティメカニズムに影響を与える可能性があります。一部の場合、DoS攻撃や悪意の活動を隠すためにサーバーがプロキシとして使用されることがあります。 APIは脆弱ですか？ サーバーサイドリクエストフォージェリ（SSRF）の欠陥は、APIがユーザーが提供したURLを検証せずにリモートリソースを取得する場合に発生します。これにより、攻撃者はアプリケーションに対して意図しない宛先にクラフトされたリクエストを送信させることができます。それがファイアウォールやVPNに保護されていてもです。 現代のアプリケーション開発の概念により、SSRFはより一般的であり、より危険になっています。 より一般的な事例 – Webhook、URLからのファイル取得、カスタムSSO、およびURLプレビューに基づいて外部リソースにアクセスすることを開発者が推奨しています。 より危険な事例 – クラウドプロバイダーやKubernetes、Dockerなどの現代の技術は、HTTP経由で管理および制御チャンネルを予測可能で知られているパスで公開します。これらのチャンネルはSSRF攻撃の簡単な標的となります。 また、現代のアプリケーションの接続性のために、アプリケーションからのアウトバウンドトラフィックを制限することがより困難になっています

脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 容易 普及度 広範囲：検出可能性 平均的 技術的 中程度：特定のビジネスに依存 悪用は通常、APIに支えられたビジネスモデルを理解し、感度の高いビジネスフローを見つけ、これらのフローへの自動アクセスを行うことに関与します。これにより、ビジネスに害を与える可能性があります。 APIの全体像がないことで、ビジネス要件を十分にサポートできないことがこの問題の広がりに寄与します。攻撃者はターゲットのワークフローに関与するリソース（例：エンドポイント）とそれらがどのように連携して動作するかを手動で特定します。既に対策メカニズムが存在する場合、攻撃者はそれらを回避する方法を見つける必要があります。 一般的な技術的影響は予想されません。悪用はビジネスに異なる方法で害を与える可能性があります。たとえば、正規のユーザーが製品の購入を妨げられたり、ゲーム内経済のインフレを引き起こす可能性があります。 APIは脆弱ですか？ APIエンドポイントを作成する際に重要なのは、それがどのビジネスフローを公開するかを理解することです。一部のビジネスフローは他よりも感度が高く、それらに過剰なアクセスが行われるとビジネスに害を及ぼす可能性があります。 感度の高いビジネスフローとそれに関連する過剰なアクセスのリスクの一般的な例： 製品の購入フロー – 攻撃者は一度に高需要アイテムの在庫をすべて購入し、高い価格で再販する（スケーリング）ことができます コメント/投稿の作成フロー – 攻撃者はシステムにスパムを送り込むことができます 予約の作成 – 攻撃者は利用可能なすべての時間枠を予約し、他のユーザーがシステムを使用するのを妨げることができます 過剰なアクセスのリスクは業界やビジネスによって異なる場合があります。例えば、あるソーシャルネットワークではスクリプトによる投稿の作成がスパムのリスクと見なされるかもしれませんが、別のソーシャルネットワークでは推奨されています。 APIエンドポイントは、適切にアクセスを制限せずに感度の高いビジネスフローを公開している場合に脆弱です。 攻撃シナリオの例 シナリオ #1 技術企業が感謝祭に新しいゲーム機を発売すると発表しました。この製品は非常に高い需要があり

脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 容易 普及度 一般的：検出可能性 容易 技術的 深刻：特定のビジネスに依存 攻撃者は、匿名ユーザーまたは通常の権限を持つユーザーとしてアクセスするべきでないAPIエンドポイントに対して正当なAPIコールを送信する必要があります。公開されたエンドポイントは簡単に悪用されます。 関数またはリソースの認可チェックは、通常、構成またはコードレベルで管理されます。適切なチェックの実装は、現代のアプリケーションには多種多様な役割、グループ、複雑なユーザー階層（サブユーザー、複数の役割を持つユーザーなど）が含まれるため、混乱のもとになる場合があります。APIは構造化されており、異なる機能にアクセスすることが予測しやすいため、これらの欠陥を発見することが容易です。 このような欠陥により、攻撃者は認可されていない機能にアクセスできるようになります。管理機能はこの種の攻撃の主要なターゲットであり、データの開示、データの損失、またはデータの破損につながる可能性があります。最終的にはサービスの中断につながる可能性があります。 APIは脆弱ですか？ 壊れた関数レベルの認可問題を見つけるための最良の方法は、認可メカニズムの徹底した分析を行うことです。ユーザー階層、アプリケーション内の異なる役割やグループを考慮しながら、次のような質問をします： 通常のユーザーは管理エンドポイントにアクセスできますか？ ユーザーはHTTPメソッドを単純に変更することで、アクセスすべきでない機敏なアクション（例：作成、変更、削除）を実行できますか？ グループXのユーザーは、単にエンドポイントURLとパラメータを推測することでグループYのユーザーにのみ公開されるべき機能にアクセスできますか（例：/api/v1/users/export_all）？ APIエンドポイントがURLパスに基づいて通常または管理者専用であると仮定しないでください。 開発者が通常、管理エンドポイントのほとんどを特定の相対パス（例：/api/admins）の下に公開することを選択する一方で、これらの管理エンドポイントが通常のエンドポイントと一緒に他の相対パス（例：/api/users）に存在することが非常に一般的です。 攻撃シナリオの例 シナリオ #1 招待されたユーザ

脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 平均 普及度 広範：検出可能性 簡単 技術的 深刻：特定のビジネスに依存 悪用には簡単なAPIリクエストが必要です。単一のローカルコンピュータまたはクラウドコンピューティングリソースを使用して、複数の同時リクエストが行われることがあります。トラフィックの高負荷によるDoS攻撃を引き起こすために設計された自動化ツールのほとんどがAPIのサービスレートに影響を与えます。 クライアントの相互作用またはリソース消費を制限しないAPIを見つけるのは一般的です。リクエストのパラメータによってリソースの数を制御するものや、応答のステータス/時間/長さの分析を行うことで問題を特定できます。バッチ処理も同様です。脅威要因はコストの影響を直接見ることができないが、サービスプロバイダ（例：クラウドプロバイダ）のビジネス/価格モデルに基づいてそれを推定できます。 悪用によりリソース枯渇によるDoS攻撃が発生する可能性がありますが、それによりCPU需要が高まり、クラウドストレージの必要性が増加するなど、インフラ関連の運用コストも増加する可能性があります。 APIは脆弱ですか？ APIリクエストを満たすためには、ネットワーク帯域幅、CPU、メモリ、ストレージなどのリソースが必要です。これらの必要なリソースは、API統合を通じてサービスプロバイダによって提供され、リクエストごとに支払われます（例：電子メール/SMS/電話の送信、生体認証の検証など）。 少なくとも次のいずれかの制限が欠落しているか不適切に設定されている場合、APIは脆弱です： 実行タイムアウト 最大割り当て可能メモリ 最大ファイル記述子数 最大プロセス数 最大アップロードファイルサイズ 単一のAPIクライアントリクエストで実行する操作の数（例：GraphQLのバッチ処理） 単一のリクエスト-レスポンスで返すページごとのレコード数 サードパーティサービスプロバイダの支出限度額 攻撃シナリオの例 シナリオ #1 あるソーシャルネットワークはSMS検証を利用した「パスワードを忘れた」フローを実装し、ユーザーがパスワードをリセットするためにSMS経由でワンタイムトークンを受け取れるようにしています。 ユーザーが「パスワードを忘れた」をクリックすると、ユーザーのブ

脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 簡単 普及度 一般的：検出可能性 簡単 技術的 適度：特定のビジネスに依存 APIは通常、全てのオブジェクトのプロパティを返すエンドポイントを公開します。これは特にREST APIに対して有効です。GraphQLなどの他のプロトコルでは、どのプロパティを返すかを指定するために工夫が必要です。これらの操作可能な追加プロパティを識別するには、より多くの努力が必要ですが、このタスクを支援する自動化ツールもいくつかあります。 APIの応答を検査することで、返されたオブジェクトの表現に含まれる機密情報を識別することが十分です。通常、Fuzzingは追加の（隠された）プロパティを特定するために使用されます。それらを変更できるかどうかは、APIリクエストを作成して応答を分析することによって判断されます。ターゲットのプロパティがAPIの応答に Threat agents/Attack vectors Security Weakness Impacts API Specific : Exploitability Easy Prevalence Common : Detectability Easy Technical Moderate : Business Specific APIs tend to expose endpoints that return all object’s properties. This is particularly valid for REST APIs. For other protocols such as GraphQL, it may require crafted requests to specify which properties should be returned. Identifying these additional properties that can be manipulated requires more effort, but there are a few automated tools available to assist in this task. Inspecting API responses is enough to iden

認証の欠如（Broken Authentication） 脅威エージェント/攻撃ベクトル セキュリティの弱点 影響 API特有：悪用の容易さ 簡単 普及度 一般的：検出容易度 簡単 技術的影響 重大：ビジネス特有 認証機構はすべての人に公開されているため、攻撃者にとって容易な標的となります。いくつかの認証問題を悪用するには高度な技術スキルが必要かもしれませんが、悪用ツールは一般的に利用可能です。 ソフトウェアおよびセキュリティエンジニアの認証境界に関する誤解や、認証の実装の複雑さから、認証問題が広まっています。認証の欠如を検出する手法は利用可能であり、作成も容易です。 攻撃者はシステム内の他のユーザーのアカウントを完全に制御し、個人データを読み取り、代理で機密操作を実行できます。システムは攻撃者の操作と正当なユーザーの操作を区別できない可能性があります。 APIは脆弱ですか？ 認証エンドポイントとフローは保護する必要がある資産です。さらに、「パスワードの忘れ/リセット」も認証機構と同様に扱うべきです。 以下の場合、APIは脆弱です： 攻撃者が有効なユーザー名とパスワードのリストを使用してブルートフォース攻撃（クレデンシャルスタッフィング）を行うことができる。 攻撃者が同一ユーザーアカウントに対してブルートフォース攻撃を行うことができ、キャプチャ/アカウントロックアウトメカニズムが存在しない。 弱いパスワードを許可する。 認証トークンやパスワードなどの機密認証情報をURLに送信する。 ユーザーがメールアドレス、現在のパスワードを変更する、または他の機密操作を行う際にパスワード確認を要求しない。 トークンの真正性を検証しない。 署名されていない/弱い署名のJWTトークン（{“alg”:”none”}）を受け入れる。 JWTの有効期限を検証しない。 プレーンテキスト、非暗号化、または弱いハッシュ化されたパスワードを使用する。 弱い暗号鍵を使用する。 さらに、マイクロサービスが脆弱である場合： 他のマイクロサービスが認証なしでアクセスできる。 認証を強制するために弱いまたは予測可能なトークンを使用する。 攻撃シナリオの例 シナリオ #1 ユーザー認証を行うために、クライアントは以下のようにユーザー資格情報を含むAPIリクエストを発行する必要があります： POST /gra

オブジェクトレベル認可の欠如（BOLA） 脅威エージェント/攻撃ベクトル セキュリティの弱点 影響 API特有：悪用の容易さ 簡単 普及度 広範：検出容易度 簡単 技術的影響 中程度：ビジネス特有 攻撃者は、リクエスト内で送信されるオブジェクトのIDを操作することで、オブジェクトレベル認可が欠如しているAPIエンドポイントを悪用できます。オブジェクトIDは連続した整数、UUID、または一般的な文字列など、何でもかまいません。データ型に関係なく、それらはリクエストターゲット（パスまたはクエリ文字列パラメータ）、リクエストヘッダ、またはリクエストペイロードの一部として簡単に識別できます。 この問題は、サーバーコンポーネントが通常、クライアントの状態を完全に追跡せず、代わりにオブジェクトIDなどのクライアントから送信されるパラメータに依存してアクセスするオブジェクトを決定するため、APIベースのアプリケーションでは非常に一般的です。サーバーレスポンスは通常、リクエストが成功したかどうかを理解するのに十分です。 他のユーザーのオブジェクトへの不正アクセスにより、機密データの漏洩、データの損失、またはデータの改ざんが発生する可能性があります。特定の状況下では、オブジェクトへの不正アクセスがアカウント全体の乗っ取りに繋がることもあります。 APIは脆弱ですか？ オブジェクトレベル認可は、ユーザーがアクセス権を持つべきオブジェクトにのみアクセスできるように検証するために通常コードレベルで実装されるアクセス制御メカニズムです。 オブジェクトのIDを受け取り、オブジェクトに対してアクションを実行するすべてのAPIエンドポイントは、オブジェクトレベルの認可チェックを実装する必要があります。チェックは、ログインしているユーザーが要求されたオブジェクトに対して要求されたアクションを実行する権限を持っているかどうかを検証する必要があります。 このメカニズムの失敗は、通常、不正な情報開示、改ざん、またはデータの破壊につながります。 現在のセッションのユーザーIDを（例：JWTトークンから抽出して）脆弱なIDパラメータと比較することは、オブジェクトレベル認可の欠如（BOLA）を解決するのに十分ではありません。このアプローチは、ケースの一部を解決するだけです。 BOLAの場合、設計上、ユーザーは

OWASP APIセキュリティトップ10 – 2023 リスク 説明 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は、チケットの購入やコメントの投稿などのビジネスフローを露出し、自動化された方法で

APIセキュリティリスク リスク分析にはOWASPリスク評価方法論が使用されました。 以下の表は、リスクスコアに関連する用語を要約しています。 脅威エージェント 悪用可能性 弱点の普及度 弱点の検出可能性 技術的影響 ビジネスへの影響 API固有 容易：3 広範囲：3 容易：3 重大：3 ビジネス固有 API固有 平均：2 一般的：2 平均：2 適度：2 ビジネス固有 API固有 困難：1 困難：1 困難：1 軽微：1 ビジネス固有 注意: このアプローチでは、脅威エージェントの発生確率を考慮していません。また、特定のアプリケーションに関連するさまざまな技術的詳細も考慮していません。これらの要因のいずれもが、攻撃者が特定の脆弱性を見つけて悪用する全体的な確率に大きく影響する可能性があります。この評価は、実際のビジネスへの影響を考慮していません。組織は、文化、業界、および規制環境に応じて、アプリケーションとAPIからのセキュリティリスクをどれだけ受け入れるかを決定する必要があります。OWASP APIセキュリティトップ10の目的は、このリスク分析を代行することではありません。この版はデータ駆動ではないため、普及度の結果はチームメンバーの合意に基づいています。 参考文献 OWASP OWASPリスク評価方法論 脅威／リスクモデリングに関する記事 外部 ISO 31000：リスク管理標準 ISO 27001：ISMS NISTサイバーフレームワーク（米国） ASD戦略的緩和策（オーストラリア） NIST CVSS 3.0 Microsoft脅威モデリングツール