認証の欠如（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脅威モデリングツール

このOWASP APIセキュリティトップ10の第2版は、初版からちょうど4年後にリリースされました。API（セキュリティ）のシーンでは多くの変化がありました。APIトラフィックは急速に増加し、一部のAPIプロトコルがさらに注目されるようになり、多くの新しいAPIセキュリティベンダー／ソリューションが登場し、もちろん、攻撃者もAPIを侵害するための新しいスキルや技術を開発しました。この10の最も重大なAPIセキュリティリスクのリストを更新する時期となりました。 APIセキュリティ業界がより成熟している今回、初めてデータの公開呼びかけが行われました。残念ながらデータの提供はありませんでしたが、プロジェクトチームの経験、注意深いAPIセキュリティ専門家のレビュー、そしてリリース候補に対するコミュニティのフィードバックを基に、この新しいリストを作成しました。この版がどのようにして作成されたかについての詳細は方法論とデータセクションでご確認いただけます。セキュリティリスクの詳細については、APIセキュリティリスクセクションをご参照ください。 OWASP APIセキュリティトップ10 2023は、急速に進化する業界向けの先進的な意識向上ドキュメントです。他のトップ10を置き換えるものではありません。今回の改訂では以下の点に注力しています： 過剰なデータ露出とマスアサインメントを統合し、共通の根本原因であるオブジェクトプロパティレベルの認可検証の不備に焦点を当てました。 リソース消費により重点を置き、その消費のペースに過度に焦点を当てるのを避けました。 新たな脅威を取り込むために、”重要なビジネスフローへの無制限アクセス”という新しいカテゴリを作成しました。これには、レート制限を使用して緩和できる脅威の大部分が含まれます。 “APIの安全でない利用”を追加しました。攻撃者はターゲットの直接的なAPIを狙う代わりに、ターゲットの統合サービスを狙い始めていることが増えてきたため、この増加しているリスクについて意識を高めるのに適した時期です。 現代のマイクロサービスアーキテクチャ、シングルページアプリケーション（SPA）、モバイルアプリ、IoTなどでAPIはますます重要な役割を果たしています。OWASP APIセキュリティトップ10は、

Welcome to the OWASP API Security Top 10 – 2023! Welcome to the second edition of the OWASP API Security Top 10! This awareness document was first published back in 2019. Since then, the API Security industry has flourished and become more mature. We strongly believe this work has positively contributed to it, due to it being quickly adopted as an industry reference. APIs play a very important role in modern application architecture. But since innovation has a different pace than creating security awareness, we believe it’s important to focus on creating awareness for common API security weaknesses. The primary goal of the OWASP API Security Top 10 is to educate those involved in API development and maintenance, for example, developers, designers, architects, managers, or organizations. You can know more about the API Security Project visiting the project page. If you’re not familiar with the OWASP top 10 series, we recommend checking at least the following top 10 pr

今日のアプリ駆動型の世界における革新の基礎要素は、アプリケーションプログラミングインターフェース（API）です。銀行、小売、交通からIoT、自動運転車、スマートシティに至るまで、APIは現代のモバイル、SaaS、およびWebアプリケーションの重要な部分であり、顧客向け、パートナー向け、および内部アプリケーションで見つけることができます。 APIはアプリケーションロジックや個人を特定できる情報（PII）などの機密データを公開するため、APIは攻撃者のターゲットとなることが増えています。安全なAPIがなければ、迅速な革新は不可能です。 一般的なWebアプリケーションセキュリティリスクのトップ10リストは依然として意味がありますが、その特異な性質のために、API特有のセキュリティリスクリストが必要です。APIセキュリティは、APIに関連する独自の脆弱性とセキュリティリスクを理解し、軽減するための戦略とソリューションに焦点を当てています。 OWASP Top 10プロジェクトに精通している場合、両方の文書の類似点に気付くでしょう。これらは読みやすさと採用を意図しています。OWASP Top 10シリーズに不慣れな場合は、トップ10リストに飛び込む前にAPIセキュリティリスクと方法論とデータセクションを読むと良いでしょう。 OWASP APIセキュリティトップ10に質問、コメント、アイデアをGitHubプロジェクトリポジトリで寄稿することができます： https://owasp.org/www-project-api-security/ https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md OWASP APIセキュリティトップ10は以下で見つけることができます： https://owasp.org/www-project-api-security/ https://github.com/OWASP/API-Security このプロジェクトを実現するために尽力してくれたすべての寄稿者に感謝します。彼らはすべて謝辞セクションに記載されています。ありがとうございます！

オープン・ワールドワイド・アプリケーション・セキュリティ・プロジェクト（OWASP）は、組織が信頼できるアプリケーションやAPIを開発、購入、維持することを支援するためのオープンなコミュニティです。 OWASPでは、無料でオープンな以下のものが見つかります：   アプリケーションセキュリティツールと標準。 アプリケーションセキュリティテスト、安全なコード開発、安全なコードレビューに関する完全な書籍。 プレゼンテーションとビデオ。 多くの一般的なトピックに関するチートシート。 標準的なセキュリティコントロールとライブラリ。 世界中の地域支部。 最先端の研究。 広範な世界中の会議。 メーリングリスト（アーカイブ）。     詳細はhttps://www.owasp.orgをご覧ください。 OWASPのツール、ドキュメント、ビデオ、プレゼンテーション、地域支部はすべて、アプリケーションセキュリティの向上に関心のある方なら誰でも無料で利用できます。 私たちは、アプリケーションセキュリティを人、プロセス、技術の問題としてアプローチすることを提唱しています。最も効果的なアプローチは、これらの分野での改善を必要とするからです。 OWASPは新しいタイプの組織です。商業的な圧力から自由であるため、アプリケーションセキュリティに関する偏りのない実用的で費用対効果の高い情報を提供することができます。 OWASPは、技術会社と提携しているわけではありませんが、商業的なセキュリティ技術の有益な利用を支援しています。OWASPは、多くの種類の資料を協力的、透明かつオープンな方法で作成しています。 OWASP財団は、プロジェクトの長期的な成功を確保するための非営利団体です。OWASPに関わるほぼすべての人がボランティアであり、OWASPの理事会、地域支部のリーダー、プロジェクトリーダー、プロジェクトメンバーが含まれます。私たちは、助成金とインフラを提供して革新的なセキュリティ研究を支援しています。 ぜひ参加してください！

目次 目次 OWASPについて 前書き はじめに リリースノート APIセキュリティリスク OWASP APIセキュリティトップ10 – 2023 API1:2023 破損したオブジェクトレベル認可 API2:2023 破損した認証 API3:2023 破損したオブジェクトプロパティレベルの認可 API4:2023 制限のないリソース消費 API5:2023 破損した関数レベルの認可 API6:2023 機密ビジネスフローへの制限のないアクセス API7:2023 サーバーサイドリクエストフォージェリ API8:2023 セキュリティ設定の誤構成 API9:2023 適切でない在庫管理 API10:2023 APIの安全でない利用 開発者にとっての次のステップ DevSecOpsにとっての次のステップ 手法とデータ 謝辞