APIを介してサービス同士がデータをやり取りするのが当たり前になり、攻撃者もAPIを主要な標的にするようになっています。そのAPI固有のリスクを体系的にまとめたのが「OWASP API Security Top 10」です。
名前は見聞きするものの、「具体的にどの10項目なのか」「Web版のOWASP Top 10と何が違うのか」が整理できていない方も多いのではないでしょうか。公式ドキュメントは英語で、各項目を読み込むのは負担が大きい面があります。
本記事では、OWASP API Security Top 10（2023年版）の全10項目を日本語で一覧にし、各リスクの意味・典型的な攻撃例・自社での確認観点・対策までを一つずつ解説します。実際に起きたAPIの情報漏えい事例や、自社のAPIの弱点を洗い出す方法（脆弱性診断）も紹介します。
目次
一括ダウンロードする
OWASP API Security Top 10とは
OWASP API Security Top 10とは、APIに特有の重大なセキュリティリスクを10項目にまとめた啓発文書です。ソフトウェアのセキュリティ向上に取り組む非営利団体OWASP（Open Worldwide Application Security Project）のAPIセキュリティプロジェクトが公開しています。
開発・設計・運用に関わる人に、API特有の弱点を知ってもらうことを目的としています。
初版は2019年に公開され、現在の最新版は2023年に公開された第2版です。後述するように、Webアプリケーション全般を対象とする「OWASP Top 10」とは別の文書で、APIならではのリスクに焦点を当てています。
なぜAPI固有のリスク対策が必要なのか
ここでは、Webアプリ一般の対策だけでは足りず、API固有の視点が必要になる理由を整理します。
APIは、マイクロサービスやSPA（シングルページアプリケーション）、モバイルアプリ、IoTなど、現代のアプリケーションの基盤として重要な役割を担っています。多くのシステムやデータをつなぐ分、攻撃者にとっても価値の高い標的になります。
実際に、認可を欠いたAPIアクセスで大量の顧客データが取得された事例があります。携帯通信大手のT-Mobileは2023年1月、単一のAPIから認可なしにデータが取得されていたことを公表しました。約3,700万件の顧客アカウントについて、氏名・請求先住所・メールアドレス・電話番号・生年月日・アカウント番号・契約プラン情報などが取得され得たとしています。
一方で同社は、決済カード情報・社会保障番号・運転免許証などの政府発行ID・パスワードは当該APIからは取得できず、漏えいしていないとしています。取得は2022年11月25日頃に始まり、2023年1月5日に検知されたとされています。APIの認可やデータの扱いの不備は、このように大きな影響につながるため、API固有の観点で体系立てたOWASP API Security Top 10が役立ちます。
出典・参考資料（3件）
【2023年版】OWASP API Security Top 10 一覧
まず、2023年版の全10項目を一覧で確認します。IDと英語名はOWASP公式の表記に合わせ、日本語での呼ばれ方と一言の意味を添えました。各項目の詳しい解説は次の章で一つずつ扱います。
| リスク | API1:2023 | API2:2023 | API3:2023 | API4:2023 | API5:2023 | API6:2023 | API7:2023 | API8:2023 | API9:2023 | API10:2023 |
|---|---|---|---|---|---|---|---|---|---|---|
| 英語名 | Broken Object Level Authorization（BOLA） | Broken Authentication | Broken Object Property Level Authorization | Unrestricted Resource Consumption | Broken Function Level Authorization | Unrestricted Access to Sensitive Business Flows | Server Side Request Forgery（SSRF） | Security Misconfiguration | Improper Inventory Management | Unsafe Consumption of APIs |
| 日本語での呼ばれ方 | オブジェクトレベル認可の不備 | 認証の不備 | オブジェクトプロパティレベル認可の不備 | リソース消費の無制限 | 機能レベル認可の不備 | 重要なビジネスフローへの無制限アクセス | サーバーサイドリクエストフォージェリ | セキュリティの設定ミス | 不適切なインベントリ管理（資産の棚卸し） | APIの安全でない利用 |
| 一言でいうと | IDを差し替えると他人のデータにアクセスできてしまう | 認証の実装不備でなりすまし・トークン窃取を許す | 項目単位の認可漏れで、見せるべきでないデータを読み書きされる | 回数・量に上限がなく、サービス停止や高額請求につながる | 一般利用者が管理機能や他人の機能にアクセスできる | 業務フローを自動化で過剰利用され、事業に損害が出る | 未検証のURLで、サーバーに意図しない宛先へ要求させる | 設定漏れ・安全でない設定が攻撃の入口になる | 古いバージョンや公開中のデバッグ用APIが放置される | 連携先のサードパーティAPIを信用しすぎて侵害経路になる |
10大リスクを一つずつ解説（API1〜API10）
ここからは、各リスクの意味を初見でも分かる言葉でかみ砕き、具体例・影響、自社での確認観点、対策の方向性の順に解説します。対策はOWASP公式が示す「How To Prevent（防止策）」に基づいています。
詳細に入る前に、10項目を観点で整理すると全体像がつかみやすくなります。
API1:2023 Broken Object Level Authorization（BOLA：オブジェクトレベル認可の不備）
APIがユーザーから渡されたID（オブジェクト識別子）をもとにデータを返すとき、「そのIDのデータを、いまアクセスしている利用者が見てよいか」を確認し損ねると、IDを別の値に差し替えるだけで他人のデータにアクセスできてしまう問題です。OWASPはこれをAPIで非常に多く見られるリスクとしています。
具体例・影響：リクエストに含まれる注文IDや利用者IDが連番や推測しやすい値だと、値を1つずらすだけで他人の情報を取得される恐れがあります。個人情報の漏えいやデータの改ざんにつながります。
自社での確認観点：利用者が指定したIDでデータを読み書きするすべての処理に、ログイン中の利用者がそのレコードにアクセスしてよいかを検証する仕組みがあるかが、まず押さえたい確認観点です。
対策の方向性：利用者のポリシーと権限階層に基づく認可の仕組みを用意し、クライアント入力のIDでレコードにアクセスするすべての関数でチェックします。IDには推測しにくいランダムな値（GUID）を使い、認可の抜けを検知するテストを書いて、失敗する変更はデプロイしない、といった対策がOWASPで挙げられています。
API2:2023 Broken Authentication（認証の不備）
認証の仕組みが正しく実装されていないと、攻撃者が認証トークンを盗んだり、実装上の欠陥を突いて他人になりすましたりできてしまいます。APIがクライアントを正しく識別できなければ、API全体の安全性が崩れます。
具体例・影響：ログイン試行を1分あたり数回に制限していても、バッチ処理やGraphQLのように複数の操作を1回のリクエストにまとめて送ると、制限がリクエスト単位のため、多数のパスワードを短時間で試されることがあります。
自社での確認観点：パスワード再設定やトークン発行をログインと同等に扱っているか、総当たり攻撃への対策（アカウントロックやCAPTCHA）があるかが点検のポイントになります。
対策の方向性：認証やトークン生成、パスワード保管を自作せず標準に従います。重要な操作では再認証を求め、可能な場合は多要素認証を導入し、総当たりやクレデンシャルスタッフィングを防ぐ仕組みを入れます。APIキーをユーザー認証に使わないことも挙げられています。
API3:2023 Broken Object Property Level Authorization（オブジェクトプロパティレベル認可の不備）
オブジェクト単位では権限を確認していても、その中の個々のプロパティ（項目）に対する認可が抜けていると、本来見せる・変更させるべきでない項目まで読まれたり書き換えられたりします。2019年版の「過剰なデータ公開」と「マスアサインメント」を統合した項目です。
具体例・影響：予約の承認APIに料金フィールドを追加して再送すると、サーバーが変更権限を確認せずに受け付け、利用者が合意額より高く請求される、といった例があります。
自社での確認観点：APIが返す項目・受け付ける項目を、その利用者のアクセス・変更してよいものだけに限定できているかが確認観点です。
対策の方向性：公開・変更してよいプロパティかを必ず確認し、クライアントが更新してよい項目だけに変更を許します。汎用的な変換メソッドや、クライアント入力を自動でコード変数に束ねる関数を避け、スキーマに基づくレスポンス検証を追加することが有効です。
API4:2023 Unrestricted Resource Consumption（リソース消費の無制限）
APIの処理には、帯域・CPU・メモリ・ストレージといった資源が必要です。SMS送信や外部API呼び出しのように、1回ごとに課金される処理もあります。これらに上限がないと、サービス停止（DoS）や費用の増大につながります。
具体例・影響：パスワード再設定エンドポイントを繰り返し呼ぶと、その都度、有料のSMS送信が走り、短時間で多額の費用が発生することがあります。
自社での確認観点：リクエスト回数やペイロードサイズの上限、外部連携の利用回数や費用の上限が設定されているかを見直すとよいでしょう。
対策の方向性：メモリ・CPU・プロセス数などを制限できる仕組みを使い、すべての入力にデータサイズの上限を設けます。業務に合わせてレート制限（一定時間内の利用回数制限）を実装し、外部サービスには費用上限や請求アラートを設定することが対策になります。
API5:2023 Broken Function Level Authorization（機能レベル認可の不備）
管理者用と一般利用者用の機能の区別が曖昧だったり、権限の階層が複雑だったりすると、一般利用者が管理機能や他人のリソースにアクセスできてしまいます。
具体例・影響：管理者専用の利用者一覧エンドポイントのパスを推測して呼ぶと、サーバーが管理者権限を確認しないため、全利用者の情報が見えてしまう、という例があります。
自社での確認観点：一般利用者のアカウントで管理者用のエンドポイントや他人向けの機能を呼び出せてしまわないか、管理用と一般用の機能の境界が明確かが確認のポイントです。
対策の方向性：既定ですべて拒否し、機能ごとに役割に応じた明示的な許可を求めます。業務ロジックと権限階層を踏まえてエンドポイントを点検し、管理機能のコントローラーに認可チェックを継承させる方法が示されています。
API6:2023 Unrestricted Access to Sensitive Business Flows（重要なビジネスフローへの無制限アクセス）
チケット購入やコメント投稿のような業務フローが、自動化で過剰に利用されたときの影響を考慮せずに公開されていると、プログラムによって大量に実行され、事業に損害が出ます。技術資源や費用の枯渇を狙うAPI4とは異なり、ここではコードのバグではなく業務フローそのものが悪用されます。
具体例・影響：多数のIPアドレスから動くボットが、発売直後の数量限定品をほぼ買い占め、高値で転売する、といった例があります。
自社での確認観点：過剰に利用されると事業に害が及ぶフローを洗い出せているか、自動化を抑止する仕組みがあるかが論点になります。
対策の方向性：害を及ぼし得る業務フローを特定したうえで、デバイスフィンガープリント、人間判定（CAPTCHAなど）、非人間的な利用パターンの検知といった保護を選びます。機械が直接利用するAPIはアクセスを制限することも挙げられています。
API7:2023 Server Side Request Forgery（SSRF：サーバーサイドリクエストフォージェリ）
APIが、利用者から渡されたURLを検証せずに外部リソースを取得すると、攻撃者がサーバーに意図しない宛先へリクエストを送らせることができます。ファイアウォールやVPNの内側でも起こり得ます。
具体例・影響：画像URLを指定するとサーバーがその画像を取得する機能で、内部ホストのアドレスを指定し、応答速度の差から内部で開いているポートを調べられる、という例があります。
自社での確認観点：外部リソースを取得する処理が分離され、許可した宛先・URLスキーム・ポートだけを通す仕組みがあるかが確認観点です。
対策の方向性：リソース取得の仕組みをネットワーク上で分離し、宛先・スキーム・ポート・メディアタイプを許可リストで制限します。HTTPリダイレクトを無効にし、クライアントからの入力を検証・サニタイズする必要があります。
API8:2023 Security Misconfiguration（セキュリティの設定ミス）
APIやそれを支えるシステムは設定が複雑になりがちで、設定漏れや安全でない設定があると、さまざまな攻撃の入口になります。
具体例・影響：非公開メッセージを返すAPIにキャッシュ制御のヘッダーがなく、ブラウザがディスクに保存した結果、キャッシュにアクセスできる攻撃者に読まれてしまう、という例があります。
自社での確認観点：環境を素早く安全な状態にできる堅牢化の手順や、設定を継続的に点検する仕組みがあるかを見直すとよいでしょう。
対策の方向性：繰り返し実施できる堅牢化のプロセスを設け、API全体の設定を定期的に見直します。通信はTLSで暗号化し、利用するHTTPメソッドを限定し、ブラウザ向けAPIにはCORSポリシーとセキュリティヘッダーを適切に設定することが求められます。
API9:2023 Improper Inventory Management（不適切なインベントリ管理：API資産の棚卸し）
APIは従来のWebアプリより多くのエンドポイントを公開しがちで、文書やバージョンの管理が不十分だと、廃止したはずの古いバージョンや、公開中のデバッグ用エンドポイントが残り、攻撃の入口になります。
具体例・影響：本番APIはレート制限で守っていたものの、放置されたベータ版の同じAPIには保護がなく、攻撃者がそこを見つけて再設定コードを総当たりし、アカウントを乗っ取る、という例があります。
自社での確認観点：稼働中のAPIホスト・バージョン・連携サービスを棚卸しし、文書化と公開範囲の管理ができているかが確認のポイントです。
対策の方向性：APIホストと連携サービスを棚卸しして文書化し、認証・エラー・リダイレクト・レート制限まで記録します。文書は認可された相手だけに公開し、非本番環境では本番データを使わないことが推奨されています。
API10:2023 Unsafe Consumption of APIs（APIの安全でない利用）
開発者は、利用者入力よりもサードパーティAPIから受け取ったデータを信用しがちで、検証が甘くなります。攻撃者は、標的のAPIを直接狙う代わりに、連携先のサービスを侵害し、そこを経由して攻撃します。
具体例・影響：医療情報をHTTPSで外部サービスに送るAPIで、攻撃者がその連携先を侵害し、攻撃者のサーバーへのリダイレクトを返すと、APIが検証せずリダイレクトに従い、患者データを攻撃者に再送してしまう、という例があります。
自社での確認観点：連携先のセキュリティ水準を評価できているか、連携先から受け取ったデータも検証・サニタイズしているか、リダイレクトを無条件に追っていないかが確認観点になります。
対策の方向性：サービス提供者のセキュリティ姿勢を評価し、連携は必ずTLSで行います。連携APIから受け取ったデータも検証・サニタイズし、リダイレクト先を許可リストで管理して、盲目的に追わないことが推奨されています。
出典・参考資料（11件）
- 出典：OWASP Top 10 API Security Risks – 2023（一覧）｜OWASP API Security Project
- 出典：API1:2023 Broken Object Level Authorization（具体例・How To Prevent）｜OWASP
- 出典：API2:2023 Broken Authentication｜OWASP
- 出典：API3:2023 Broken Object Property Level Authorization｜OWASP
- 出典：API4:2023 Unrestricted Resource Consumption｜OWASP
- 出典：API5:2023 Broken Function Level Authorization｜OWASP
- 出典：API6:2023 Unrestricted Access to Sensitive Business Flows｜OWASP
- 出典：API7:2023 Server Side Request Forgery｜OWASP
- 出典：API8:2023 Security Misconfiguration｜OWASP
- 出典：API9:2023 Improper Inventory Management｜OWASP
- 出典：API10:2023 Unsafe Consumption of APIs｜OWASP
OWASP API Security Top 10 の位置づけ（他の版・Web版との関係）
各リスクを押さえたら、この文書が他の枠組みの中でどこに位置するのかも確認しておくと、対策の範囲を取り違えずに済みます。ここでは、Web版との違いと、2019年版からの変更点を整理します。
Web版 OWASP Top 10 との違い
OWASPには、Webアプリケーション全般を対象とする「OWASP Top 10」もあります。API Security Top 10は、これを置き換えるものではなく、API固有の弱点に焦点を当てた別の文書です。オブジェクト・プロパティ・機能といった各レベルの認可、業務フローの濫用、サードパーティAPIの利用など、APIならではの論点を扱います。
OWASPは、APIで動くアプリ（モバイルアプリやWebアプリなど）を扱う場合は、両方のTop 10を読むことを勧めています。守備範囲が別なので、どちらか一方だけでは抜けが生じます。
2019年版から2023年版での主な変更点
2023年版は、2019年の初版からちょうど4年を経て公開された第2版です。OWASPが挙げている主な変更は次の4点です。
- 2019年版の「過剰なデータ公開（Excessive Data Exposure）」と「マスアサインメント（Mass Assignment）」を、共通する原因であるオブジェクトプロパティレベルの認可の失敗に着目して統合し、API3:2023 とした
- リソースの消費そのものを重視する形に整理し、API4:2023「リソース消費の無制限」とした
- 新たな脅威に対応するため、API6:2023「重要なビジネスフローへの無制限アクセス」を新設した
- 連携先のサービスを侵害する攻撃の増加を受け、API10:2023「APIの安全でない利用」を新設した
このほか、2019年版で単独項目だった「インジェクション」と「不十分なログ記録とモニタリング」は、2023年版の単独項目からは外れています。また、API2は「Broken User Authentication」から「Broken Authentication」へと名称が変わりました。
出典・参考資料（2件）
一括ダウンロードする
自社APIの弱点を確かめる方法（脆弱性診断）
ここまでのリスクを踏まえると、次に気になるのは「自社のAPIは大丈夫か」です。ここでは、APIの弱点を実際に洗い出す主な方法と、国内で使えるサービスを紹介します。
API Scanning・DAST・ペネトレーションテストの違い
自社APIを確かめる手段は、大きく自動スキャンと人手による検証に分かれます。それぞれの性質を押さえると、組み合わせ方を判断しやすくなります。
DAST（動的アプリケーションセキュリティテスト）：稼働中のアプリに外部から疑似的な攻撃リクエストを送り、SQLインジェクションやクロスサイトスクリプティングなどの脆弱性を検出する、ブラックボックス型の自動テストです。ソースコードがなくても実施できます。
APIに特化してREST APIなどを自動で検査するものは、このDASTをAPI向けに適用したもので、「API Scanning」と呼ばれることがあります。
ペネトレーションテスト：評価者が実際の攻撃者と同じ手法で本物の攻撃を試み、セキュリティ機能を回避できるかを検証するテストです。自動スキャンが既知のパターンを網羅的に調べるのに対し、人の判断で業務ロジックの穴（認可の不備など）を深く掘り下げられるのが特徴です。
自動スキャン（DAST・API Scanning）は速く広く、ペネトレーションテストは深く、という違いがあります。本記事で解説したBOLAや機能レベル認可の不備のように、業務ロジックに依存する弱点は人手の検証が効きやすく、両者を組み合わせると漏れを減らせます。
出典・参考資料（2件）
APIに絞って診断の手法（ツール・手動・ハイブリッド）や費用相場、サービスの選び方をもう一段詳しく知りたい方は、以下の記事で、BOLAなどOWASP API Security Top 10の認可欠陥を踏まえた診断の観点とあわせて整理しています。
API診断に対応する脆弱性診断サービス
ここからは、数ある脆弱性診断サービスの中でも、APIを明確な診断対象として掲げるサービスを紹介します。まず2つのサービスの特徴を比較表で確認し、続けて個別に解説します。
| サービス | Aikido Security | CoWorker 脆弱性診断サービス |
|---|---|---|
| 提供形態 | ツール型（SaaS） 自動スキャンを自社で継続運用 | 委託型 AI診断＋専門家が報告書を納品 |
| API診断の方式 | DAST・API Scanning （自動スキャン） | 動的脆弱性診断 （Web/API診断） |
| ソースコード診断 | ●（SAST・SCA） | ●（ソースコードAI診断） |
| ペネトレーションテスト対応 | △（人手の診断はAndGoの別サービス） | ●（Webペネトレは60万円〜） |
| 料金の目安 | 月額5万円台〜 （年間契約・利用者10人まで） | 動的（Web/API）診断30万円〜 （ソースコード診断は15万円〜） |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
※上記は2026年11月時点の各社公開情報にもとづく整理です（CoWorkerの料金・提供範囲は2026年10月時点の公開情報）。最新の対応範囲・料金・提供形態は各社にご確認ください。
ここで挙げた2サービスに限らず、脆弱性診断サービスを幅広く比較して自社に合うものを選びたい場合は、以下の記事で診断方法・費用相場・選び方を解説しています。
1. Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・稼働中のWebアプリ・APIまでを1つの管理画面で検査できる脆弱性診断SaaSです。ベルギーのAikido Securityが開発し、日本では株式会社AndGoが販売・導入支援の窓口を担います。
APIに関しては、稼働中のアプリに外部から検査を行うDASTや、API向けの自動スキャンに対応します。ソースコード診断（SAST・SCA）やクラウド設定診断（CSPM）も統合しているため、設定ミスやインベントリ管理のように構成に関わるリスクまで横断的に点検できます。
料金は月額のサブスクリプション型で、利用するエンジニアの人数に応じてプランが決まります。日本窓口の案内では月額5万円台から（年間契約・利用者10人までの参考価格、2026年11月時点）とされています。アラートの自動トリアージで誤検知を抑え、修正案をプルリクエストとして提示する機能もあります。
日本窓口である株式会社AndGoの原氏は、開発現場におけるセキュリティの位置づけの変化について、次のように述べています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。だから開発の初期からセキュリティを組み込むDevSecOps（開発（Dev）、セキュリティ（Sec）、運用（Ops））が現実解になってきていて、Aikido Securityはその“回し方”を作るためのツールだと考えています。
2. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker 脆弱性診断サービスは、CoWorker株式会社が提供する、自社開発のAI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせた脆弱性診断です。
診断メニューは、ソースコードAI診断、動的脆弱性診断（Web/API診断）、実践攻撃シミュレーション診断（ペネトレーションテスト）の3つで、稼働中のWebアプリ・APIやソースコード・設計書を対象にします。自動スキャンだけでは拾いにくい認可の不備なども、専門家の確認とペネトレーションテストで深く検証できる点が特徴です。
料金は、同社によると、ソースコード診断が15万円から、動的な診断（Web/API。APIのエンドポイント数に応じる）が30万円から、Webアプリケーションのペネトレーションテストが60万円からとされています（2026年10月時点）。APIのエンドポイント数に応じて動的診断の費用が決まるため、診断の規模を見積もりやすいのが特徴です。
CoWorker株式会社の一ノ瀬氏は、脆弱性診断を取り巻く近年の変化について、次のように述べています。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
まとめ
OWASP API Security Top 10（2023年版）は、APIを狙う代表的な10のリスクを体系立てた啓発文書です。
認可の不備（API1・API3・API5）、認証の不備（API2）、リソース消費（API4）、業務フローの濫用（API6）、SSRF（API7）、設定ミス（API8）、インベントリ管理（API9）、サードパーティAPIの利用（API10）という観点で、自社のAPIを点検する出発点になります。
まずは全10項目を自社のAPIに当てはめ、特に認可の確認がすべてのエンドポイントで漏れていないかを見直すことが第一歩です。そのうえで、API ScanningやDAST、ペネトレーションテストといった診断で実際の弱点を洗い出すと、より確実に備えられます。
一括ダウンロードする
よくある質問（FAQ）
Q. OWASP API Security Top 10はどのくらいの頻度で更新されますか？
A. OWASP API Security Top 10に決まった更新周期はなく、これまでは2019年の初版から2023年の第2版まで約4年の間隔で改訂されています。現在の最新版は2023年版で、次の改訂時期は公表されていません。常に最新の内容を確認したい場合は、OWASP API Security Projectの公式サイトで版の情報をチェックするのが確実です。
Q. 自社のAPIがOWASP API Security Top 10の10項目に該当するかは、どう確認すればよいですか？
A. 各項目の「自社での確認観点」を自社APIに当てはめて点検したうえで、API ScanningやDAST、ペネトレーションテストで実際の弱点を洗い出すのが基本です。まずは、利用者が指定したIDでデータを読み書きする処理や管理機能などで、認可チェックが全エンドポイントで漏れていないかを設計・コードの観点から確認します。
そのうえで、自動スキャン（DAST・API Scanning）で広く速く、ペネトレーションテストで業務ロジックの穴を深く確かめると、BOLAや機能レベル認可の不備のように人手の検証が効きやすい弱点も拾いやすくなります。
Q. OWASP API Security Top 10に沿って対策すれば、APIのセキュリティは万全になりますか？
A. OWASP API Security Top 10はあくまで代表的なリスクを体系立てた啓発文書で、これに従えばすべての脅威を防げるわけではありません。自社APIを点検する出発点として優れていますが、ここに挙がっていない固有のリスクもあり得ます。10項目で全体を見直したうえで、脆弱性診断による実地の確認や、設定・在庫管理の継続的な見直しを組み合わせることで、より確実に備えられます。
Q. OWASP API Security Top 10はどこで確認できますか？
A. OWASP API Security Top 10は、OWASP API Security Projectの公式サイトで無料で公開されています。各リスクの説明に加え、OWASPが推奨する防止策（How To Prevent）まで記載されています。ただし公式ドキュメントは英語で提供されているため、全項目を日本語で把握したい場合は、本記事のような日本語の解説と併せて読むと負担を減らせます。
脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、API診断に対応する脆弱性診断サービスの最新資料を無料で一括請求できます。診断範囲や料金、対応するリスクを比べて、自社のAPIに合うサービスを選べます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
