自社でAPIを公開・運用していると、セキュリティ対策がどうしても「リリース直前の一発チェック」に寄りがちです。しかしAPIの脆弱性は、設計の段階で生まれるもの、コードに潜むもの、稼働して初めて現れるものと、作り込みの各段階で性質が変わります。どの段階で何を確かめるかを工程として押さえていないと、特にAPI固有の認可の欠陥を見落としたまま公開してしまいます。
特にAPIは、従来のWebアプリケーションとは検査の勘所が異なり、Webアプリケーション診断だけではカバーしきれない面があります（理由は後述します）。何を・いつ・どのテストで確かめるかを、ライフサイクル全体で設計する必要があります。
本記事では、API開発のライフサイクル（設計・開発・テスト・リリース前・運用）の各段階で行うべきセキュリティテストを一覧で示し、SAST・DAST・手動ペネトレーションテストといった各手法が「何を検出でき、何を検出できないか」をOWASP API Security Top 10 と対応づけて整理します。
そのうえで、自社の工程に組み込める範囲と、外部の脆弱性診断サービスに任せたほうがよい範囲の線引きまで解説します。
目次
一括ダウンロードする
APIセキュリティテストをライフサイクル段階別に一望する
はじめに、API開発の各段階で「どのテストを・何のために・手動か自動か・CI/CDとどう関わるか」を一枚にまとめます。段階の区分は特定のツールに依存しない一般的な工程（設計→開発→テスト→リリース前→運用）に沿っています。各セルの中身は次章以降で順に掘り下げます。
| 段階 | 設計 | 開発 | テスト | リリース前 | 運用 |
|---|---|---|---|---|---|
| 主なセキュリティテスト | 脅威モデリング・設計レビュー | SAST（静的診断）・セキュアコーディング | DAST（動的診断）・IAST・ファズテスト | 手動ペネトレーションテスト | 継続的な脆弱性検査・ランタイム保護・WAF |
| 主に見つける問題 | 認可設計の漏れ・仕様段階の欠陥（権限分離の甘さ等） | コード起因の欠陥（インジェクション・危険な実装・秘密情報の混入） | 稼働中に現れる欠陥（SQLインジェクション・XSS・異常入力への耐性） | ビジネスロジック・複合的な認可の欠陥（BOLA 等） | 公開後に見つかる新規脆弱性・設定の変化・実際の攻撃 |
| 手動/自動 | 手動中心 | 自動 | 自動中心 | 手動（専門家） | 自動 |
| CI/CDとの関わり | 設計レビューの工程に組み込む | IDE・コミット／プルリクエストごとに自動実行 | 定時スキャン（nightly）・CIに組み込み | リリース判定の前に実施 | 公開後も継続的に実行 |
ポイントは、どれか一つのテストで全てをまかなうのではなく、段階ごとに得意なテストを配置して「線」でつなぐことです。早い段階で見つけられる欠陥は早く・自動で、人の判断が要る複合的な欠陥はリリース前に専門家が、という役割分担になります。
各段階で行うセキュリティテストの中身と「いつ・何のために」
ここからは、一望表の各行を段階順に解説します。それぞれのテストが何を見つけるのか、手動か自動か、開発の流れ（CI/CD）にどう組み込むかを順に確認します。
設計段階：脅威モデリング・設計レビュー
APIの認可の欠陥の多くは、コードのバグというより設計段階の決め方に根があります。たとえば「どのエンドポイントで、誰が、どのオブジェクトにアクセスしてよいか」を仕様として詰めきれていないと、実装がいくら丁寧でも抜けが残ります。
そこで設計段階では、想定される攻撃の筋道を洗い出す脅威モデリングと、エンドポイント単位の認可方針・入力値の扱い・認証方式を見直す設計レビューを行います。ここは自動ツールではなく、設計者とセキュリティ担当の目による確認が中心です。後述するオブジェクトレベルの認可の不備（BOLA）は、ここで「IDを使ってデータにアクセスするたびに認可を確認する」という方針を固められるかが分かれ目になります。
開発段階：SAST（静的診断）・セキュアコーディング
開発段階では、ソースコードを実行せずに解析して欠陥を探すSAST（静的アプリケーションセキュリティテスト）を使います。OWASPはSASTを、プログラムを実行せずにコードを調べる手法だと説明しています。
Static Code Analysis or Source Code Analysis is usually part of a Code Review (white-box testing) and it is a method of computer program debugging that is done by examining the code without executing the program.
出典：Static Application Security Testing｜OWASP DevSecOps Guideline
SASTはインジェクションを招く危険な書き方や、秘密情報（APIキーなど）のコードへの混入といった、コードに起因する問題を早期に見つけるのが得意です。IDEやCIに組み込めば、コミットやプルリクエストのたびに自動で検査でき、欠陥を開発サイクルの後ろで見つけるより手間を減らせます。こうした「できるだけ早い段階で検査する・開発の流れに組み込む」考え方は、一般にシフトレフトと呼ばれます。
テスト段階：DAST（動的診断）・IAST・ファズテスト
テスト段階では、稼働中のアプリケーションを動かしながら検査します。代表がDAST（動的アプリケーションセキュリティテスト）で、OWASPはこれを、ソースコードを必要とせず外側からブラックボックスで検査し、悪意のある入力を送り込んでSQLインジェクションやクロスサイトスクリプティング（XSS）などの弱点を見つける手法だと説明しています。
DAST is a “Black-Box” testing, can find security vulnerabilities and weaknesses in a running application by injecting malicious payloads to identify potential flaws that allow for attacks like SQL injections or cross-site scripting (XSS), etc.
出典：Dynamic Application Security Testing｜OWASP DevSecOps Guideline
IAST（インタラクティブアプリケーションセキュリティテスト）は、アプリの中にセンサーを組み込み、動作している最中に内側から挙動を追う手法です。コードを静的に見るSASTと、外側から動かすDASTの中間に位置づけられます。
実行時に実際のデータの流れを内側から観測するため、検出した欠陥がソースコードのどの箇所に由来するかを特定しやすく、誤検知を抑えやすいのが利点です。一方で、検査中に実際に通ったコード経路しか見られないため、検出できる範囲は、テストがどれだけ機能を実行して網羅するかに左右されます。
ファズテスト（ファジング）は、無効な値や極端な入力を大量に送り込み、アプリがどう反応するかから弱点をあぶり出す手法で、想定外の入力への耐性を確かめるのに向きます。
APIでは、OpenAPIなどの仕様をもとに、各エンドポイント・各パラメータへ想定外の型や境界値のリクエストを自動生成して送れます。入力検証の抜け漏れや、処理しきれずに500エラー・異常終了を起こす箇所を網羅的に検査できます。DAST・IAST・ファズテストはいずれも、設定すれば定時スキャンとしてCIに組み込めます。
出典・参考資料（3件）
リリース前：手動ペネトレーションテスト
自動ツールが拾いにくいのが、ビジネスロジックの隙や、複数の権限・ユーザーをまたいで初めて成立する認可の欠陥です。こうした箇所は、専門家が実際に攻撃者の立場で突破を試みる手動ペネトレーションテストで確かめます。NISTはペネトレーションテストを、評価者が制約の下でシステムのセキュリティ機能を回避・突破しようとする手法だと定義しています。
A test methodology in which assessors, typically working under specific constraints, attempt to circumvent or defeat the security features of a system.
出典：penetration testing（NIST SP 800-53 Rev. 5 ほか）｜NIST Computer Security Resource Center
自動スキャンが「幅広く・繰り返し」を得意とするのに対し、手動ペネトレーションテストは「深く・文脈を踏まえて」を担います。公開前の最終確認として、リリース判定の前に実施するのが定石です。
運用段階：継続的な脆弱性検査・ランタイム保護・WAF
APIは公開して終わりではありません。新しい脆弱性が後から公表されたり、設定変更で思わぬ穴が開いたり、仕様から外れた未管理のエンドポイント（シャドウAPI）が増えたりします。そこで運用段階では、DASTの定時スキャンなどで継続的に検査しつつ、不正なリクエストを実行時に検知・遮断するランタイム保護やWAF（Webアプリケーションファイアウォール）を併用します。
ここまでをまとめると、設計から運用までの各段階に適したテストを配置し、自動化できるものはCIに組み込んで継続的に回すのが、API全体を守る現実的な進め方になります。
一括ダウンロードする
OWASP API Security Top 10 と各テストの検出範囲
APIに特有の脆弱性を体系的に整理した代表的な基準が、OWASPが公開する「OWASP API Security Top 10」です。最新版は2023年版で、公式には英語のみが公開されています（以下の日本語名は本記事の訳で、英語の正式名称を併記します）。まず主要な項目を押さえたうえで、各テストがどの項目を拾えるのかを対応表で整理します。
OWASP API Security Top 10 の筆頭（API1）に挙げられているのが、オブジェクトレベル認可の不備（Broken Object Level Authorization、以下BOLA）です。OWASPは次のように説明しています。
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.
出典：API1:2023 – Broken Object Level Authorization｜OWASP API Security Top 10 2023
ほかにも、認証の仕組みの実装不備を突く API2:2023 認証の不備（Broken Authentication）や、オブジェクトのプロパティ単位で認可確認が欠ける API3:2023 オブジェクトプロパティレベル認可の不備（Broken Object Property Level Authorization、旧「過剰なデータ公開」と「一括割り当て」を統合）が挙げられます。
さらに、大量リクエストでサービス妨害やコスト増を招く API4:2023 リソース消費の制限不備（Unrestricted Resource Consumption）などが並びます。いずれも、IDやリクエストを使ってデータや機能にアクセスする、API固有の作りに根ざしたリスクです。
このほか、管理者機能などへのアクセス制御が崩れる API5:2023 機能レベル認可の不備（Broken Function Level Authorization）や、自動化された大量操作で業務フローを悪用される API6:2023 業務フローへの無制限アクセス（Unrestricted Access to Sensitive Business Flows）があります。
また、複雑な設定の見落としによる API8:2023 設定ミス（Security Misconfiguration）なども、各テストの検出範囲を考えるうえで押さえておきたい項目です。
各テストが「何を検出し、何を検出できないか」
テスト手法には、それぞれ原理上の得意・不得意があります。重要なのは、どれが優れているかではなく、何を拾えて何を拾えないかを理解して組み合わせることです。特に押さえたいのが、SASTはコードを実行せずに解析するため、実行時にしか現れない認可の欠陥（BOLAなど）を拾えないという点です。OWASPもSASTについて、実行時の可視性を欠くと述べています。
Static Application Security Testing method examine source code in a non-runtime environment early in the SDLC. … they lack visibility during runtime.
出典：Interactive Application Security Testing｜OWASP DevSecOps Guideline
| テスト手法 | SAST（静的診断） | DAST（動的診断） | IAST | ファズテスト | 手動ペネトレーションテスト |
|---|---|---|---|---|---|
| 検出が得意な脆弱性 | コード起因の欠陥（インジェクションを招く実装・秘密情報の混入） | 稼働中に外部から確認できる欠陥（SQLインジェクション・XSS 等） | 実行中に内側から観測する欠陥（SAST／DASTの中間） | 異常入力への耐性・想定外の挙動（堅牢性） | ビジネスロジック・複合的な認可の欠陥 |
| 苦手・検出しにくい脆弱性／主な制約 | 実行時にしか現れない認可の欠陥（BOLA＝API1 等）。コードを実行しないため | 複数ユーザー・権限をまたぐ認可の欠陥（BOLA＝API1）。有効なIDや権限を使い分けた検証が要るため拾いにくい | アプリへのセンサー組み込みが前提（制約） | 設計・ロジック起因の欠陥 | 網羅性・実施頻度（人手のためコストと時間がかかる＝制約） |
| 主に関わるOWASP API項目 | API8（設定ミス）の一部ほか、コード品質に関わる横断的な項目 | API8（設定ミス）など稼働時に現れる項目 | 実行時に現れる項目（横断的） | API4（リソース消費の制限不備）ほか | API1（BOLA）・API5（機能レベル認可の不備）・API6（業務フローへの無制限アクセス） |
この表からわかるのは、BOLAのような実行時の認可の欠陥の扱いにくさです。コードを静的に見るSASTでは原理的に拾えず、DASTでも稼働中に複数の権限を使い分ける必要があるため自動だけでは取りこぼしやすく、最終的には手動ペネトレーションテストで深く確かめる必要があります。だからこそ、段階ごとにテストを配置して組み合わせる意味があります。
なぜWebアプリケーション診断だけではAPIの欠陥を拾えないのか
「既存のWebアプリケーション診断は入れているから大丈夫」と考えがちですが、API固有の欠陥はそれだけでは拾いきれないことがあります。理由は、APIが画面を持たず、エンドポイント単位でデータをやり取りする作りにあります。OWASPもAPI9:2023（不適切なインベントリ管理）で、次のように指摘しています。
APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important.
出典：API9:2023 – Improper Inventory Management｜OWASP API Security Top 10 2023
画面を巡回して検査する従来型の診断は、リンクやフォームをたどって検査範囲を広げます。ところがAPIには人がたどる画面がないため、仕様書（OpenAPIなどの定義）から検査すべきエンドポイントを洗い出さないと、そもそも診断の対象に入りません。結果として、ドキュメントに載っていない未管理のエンドポイントや、IDを差し替えると他人のデータが見えてしまうBOLAのような欠陥が、検査の網から漏れます。
シングルページアプリケーション（SPA）やスマートフォンアプリのバックエンドとしてAPIを多数公開している場合、あるいは機能追加でエンドポイントが増え続けている場合は、API固有の観点を持った診断が特に必要になります。自社が当てはまるかは、「公開しているエンドポイントを正確に把握できているか」「IDやパラメータを変えたときの認可を確かめているか」で判断できます。
API固有の脆弱性診断そのものの中身や、ツール・手動・ハイブリッドといった診断手法ごとの費用、サービスの選び方まで踏み込んで知りたい場合は、以下の記事で詳しく解説しています。
自社でやる範囲と外部診断に任せる範囲
ここまでの各テストは、すべてを自社だけで抱える必要はありません。どこまで内製でき、どこから外部の専門サービスに任せるのが現実的かを整理します。
SASTや日常的なDASTのような自動ツールは、CI/CDに組み込んで開発チームが継続的に回すのに向きます。一方、公開前の網羅的な動的API診断や、ビジネスロジックまで踏み込む手動ペネトレーションテストは、専門知識と工数が要るため、外部の脆弱性診断サービスに委託するほうが品質と効率の両面で現実的です。
自社は「工程に組み込む継続的な検査」を担い、専門家は「公開前の深い確認」を担う、という分担が一つの型になります。
各テストを「自社の工程で内製する」か「外部の脆弱性診断サービスに委託する」かの現実的な目安を整理すると、次のとおりです。
| 区分 | 自社で内製する | 外部の診断サービスに委託する |
|---|---|---|
| 該当するテスト | 設計レビュー・脅威モデリング SAST（静的診断） 日常的なDAST（動的診断） 運用段階の継続的な検査 | 公開前の網羅的な動的API診断 手動ペネトレーションテスト |
| 向いている理由 | ツールでCI/CDに組み込め、継続的に回せる | 専門知識と工数が要り、公開前に深く確認する必要がある |
API診断に使える脆弱性診断サービスの比較
API診断に対応したサービスを、診断の進め方（自動ツール中心か、専門家の手動診断か、両者を組み合わせるか）という軸で整理します。
| サービス名 | Aikido Security | CoWorker 脆弱性診断サービス |
|---|---|---|
| 診断の進め方 | 自動ツール（SaaS） 継続スキャンを自社で実行 | AI解析＋専門家確認 診断を委託するハイブリッド型 |
| API診断への対応 | ●製品にAPI Scanningを含む | ●動的診断（Web／API）に対応 |
| 主な診断手法 | SAST・SCA・DAST クラウド設定診断（CSPM） | ソースコードAI診断 動的診断（Web／API） ペネトレーションテスト |
| 手動ペネトレーションテスト | △日本窓口（AndGo）の別サービス | ●実践攻撃シミュレーション診断 |
| CI/CD・開発工程への組み込み | ●Slack・Jira・IDE拡張等で組込可 | ×委託型のため非該当 |
| 料金の目安 | Basicプラン 年額3,780ドル〜 （利用者10人まで・参考価格） 無料プランあり | ソースコードAI診断 15万円〜 動的診断を含むLite 50万円〜 （CoWorker提供情報・2026年11月時点） |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
自社の状況に合うサービスをさらに幅広く比較検討したい場合は、脆弱性診断サービス全体の診断方法・費用相場・選び方を解説した記事もあわせて参考にしてください。
1. Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・稼働中のWebアプリを一つの管理画面で検査するSaaS型の診断ツールです。開発元はベルギーのAikido Security BVで、日本では株式会社AndGoが販売・問い合わせの窓口を担っています。人が診断して報告書を納める受託型ではなく、自動スキャンを継続的に回して使う形態が特徴です。
API診断の観点では、公式の製品一覧にAPI Scanningが含まれ、DAST（動的診断）やSAST・SCA（依存関係の診断）・CSPM（クラウド設定診断）まで幅広くカバーします。Slack・Teams・Jira・AWSなどと連携でき、CI/CDに組み込んで開発工程で継続的に検査する「自社でやる範囲」の受け皿になります。
無料のDeveloperプランがあり、導入前に試せる点も、まず内製で自動化を始めたいチームに向きます。
日本窓口（株式会社AndGo）の参考料金は、Basicプランが年額3,780ドル、Proプランが年額7,560ドル、Customは要問い合わせです（いずれも年間契約・利用者10人までの場合の参考価格で、請求は為替を考慮した日本円での案内となります。2026年11月時点）。正式な見積りはAndGoへの確認が必要です。
本記事で見てきたとおり、セキュリティ対策は開発の初期段階から流れに組み込むのが現実的な進め方になります。この開発現場での扱い方の変化について、日本窓口を務める株式会社AndGoの原氏は、インタビューで次のように述べています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。だから開発の初期からセキュリティを組み込むDevSecOps（開発（Dev）、セキュリティ（Sec）、運用（Ops））が現実解になってきていて、Aikido Securityはその“回し方”を作るためのツールだと考えています。
2. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker株式会社が提供する脆弱性診断サービスは、AIによる自動解析と専門家による最終確認を組み合わせた診断が特徴です。診断メニューは、ソースコードをAIが解析する「ソースコードAI診断」、稼働中のWebアプリ・APIを対象に攻撃者視点で検査する「動的脆弱性診断（Web／API診断）」、専門家が攻撃を試みる「実践攻撃シミュレーション診断（ペネトレーションテスト）」が用意されています。
稼働中のAPIに対する動的診断と、専門家による手動の確認を組み合わせられるため、前章で触れた「公開前の深い確認」を外部に委託したい場合の受け皿になります。動的診断はAPIの診断対象件数に応じた料金設定で、公開前のAPI診断を段階的に依頼しやすいのも特徴です。
料金は、ソースコードAI診断が150,000円、ソースコードと動的診断（Web／API、API 150件まで）をセットにしたLiteが500,000円です。
上位プランは、再診断1回・API 300件までのStandardが1,000,000円、詳細レポートと再診断2回・API 500件までのProfessionalが1,500,000円です（CoWorker提供のプラン情報。2026年11月時点。最新の料金は公式サイトでご確認ください）。
出典・参考資料（1件）
APIの脆弱性を公開後も継続して確かめる必要性について、CoWorker株式会社の一ノ瀬氏は、インタビューで攻撃側の変化を踏まえて次のように話しています。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
まとめ
APIのセキュリティテストは、リリース直前にまとめて行うものではなく、設計・開発・テスト・リリース前・運用の各段階に適したテストを配置し、工程全体でつないで実施するものです。設計では脅威モデリングと設計レビュー、開発ではSAST、テストではDAST・IAST・ファズテスト、リリース前には手動ペネトレーションテスト、運用では継続的な検査とランタイム保護、という役割分担になります。
各テストには原理上の得意・不得意があり、SASTでは拾えないBOLAのような実行時の認可の欠陥は手動ペネトレーションテストで深く確かめる、といった組み合わせが欠かせません。自動化できる検査はCIに組み込んで内製し、公開前の網羅的な動的API診断や手動ペネトレーションテストは外部の脆弱性診断サービスに任せる、という線引きで、無理なく継続できる体制を作れます。
まずは自社のAPIがどの段階のどのテストを満たせているかを棚卸しし、不足する部分から着手してください。
公開前の動的API診断や手動ペネトレーションテストを外部に委託する選択肢を検討する場合は、API診断に対応した脆弱性診断サービスの資料をまとめて請求し、診断範囲や料金を比べてみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. APIセキュリティテストとは何ですか？
A. APIセキュリティテストとは、APIに潜むセキュリティ上の欠陥を、設計から運用までの開発ライフサイクル全体を通じて検出・検証する一連のテストです。設計段階の脅威モデリングや設計レビュー、開発段階の静的診断（SAST）、テスト段階の動的診断（DAST）、リリース前の手動ペネトレーションテスト、運用段階の継続的な検査までを含み、段階ごとに得意なテストを配置して組み合わせます。
Q. APIのセキュリティテストはいつから始めるべきですか？
A. APIのセキュリティテストは、リリース直前にまとめて行うのではなく、設計段階から始めるのが基本です。API固有の認可の欠陥の多くは設計段階の決め方に根があるため、脅威モデリングや設計レビューで早期に芽を摘み、開発段階ではSASTをIDEやCIに組み込んでコミットのたびに自動検査するのが有効です。
できるだけ早い段階で検査して開発の流れに組み込む考え方はシフトレフトと呼ばれ、欠陥を後工程で見つけるより修正の手間を抑えられます。
Q. APIセキュリティテストのSASTとDASTはどう使い分けますか？
A. SASTはコードを実行せずに解析する開発段階向けのテスト、DASTは稼働中のアプリを外部から動かして検査するテスト段階向けのテストで、段階に応じて使い分けます。SAST（静的診断）はインジェクションを招く危険な書き方や秘密情報の混入などコード起因の欠陥を早期に見つけるのが得意な一方、実行時にしか現れない認可の欠陥（BOLA）は原理上拾えません。
DAST（動的診断）はSQLインジェクションやXSSなど稼働中に外部から確認できる欠陥を検出します。優劣ではなく、適材適所で組み合わせるものです。
Q. 自動の脆弱性スキャンと手動ペネトレーションテストは何が違いますか？
A. 自動スキャンは「幅広く・繰り返し」検査し、手動ペネトレーションテストは「深く・文脈を踏まえて」検査する点が違います。SASTやDASTなどの自動ツールはCIに組み込んで継続的に回せますが、ビジネスロジックの隙や、複数の権限・ユーザーをまたいで初めて成立する認可の欠陥（BOLAなど）は拾いにくいです。
こうした箇所は、専門家が攻撃者の立場で突破を試みる手動ペネトレーションテストで深く確かめ、公開前の最終確認としてリリース判定の前に実施するのが定石です。
Q. OWASP ZAPなどの無料ツールだけでAPIのセキュリティテストは足りますか？
A. 無料の自動ツールは日常的な検査の自動化には有効ですが、それだけでAPIのセキュリティテストを完結させるのは難しいです。自動スキャンは既知のパターンを幅広く検出できる一方、実行時に複数の権限を使い分けて確かめる必要があるBOLAのような認可の欠陥や、ビジネスロジックの欠陥は取りこぼしやすいためです。
自社でCIに組み込む継続的な検査は内製しつつ、公開前の網羅的な動的API診断や手動ペネトレーションテストは、専門知識と工数が要るため外部の脆弱性診断サービスに委託するのが現実的です。
Q. API脆弱性診断を外部に委託する場合の費用はどのくらいですか？
A. API脆弱性診断の外部委託費用は、診断の進め方や対象エンドポイント数によって幅があり、数十万円から数百万円規模までさまざまです。たとえば本記事で紹介したCoWorker脆弱性診断サービスでは、ソースコードAI診断が15万円、動的診断（Web／API）をセットにしたプランが50万円からで、API件数や再診断回数に応じて上位プランが用意されています。
一方、Aikido SecurityのようにSaaS型で継続的に自動スキャンを回す形態もあり、「公開前の単発診断か、継続的な内製検査か」という使い方で選び方が変わります。正確な費用は各サービスへの見積り確認が必要です。
Q. WebアプリケーションのセキュリティテストをしていればAPIのセキュリティテストは不要ですか？
A. いいえ、従来のWebアプリケーション診断だけではAPI固有の欠陥を拾いきれないため、API向けのセキュリティテストは別途必要です。画面を巡回して検査するWebアプリ診断はリンクやフォームをたどりますが、APIは画面を持たずエンドポイント単位でデータをやり取りするため、仕様書（OpenAPIなどの定義）から対象を洗い出さないと診断範囲に入りません。
その結果、ドキュメントにない未管理のエンドポイントや、IDを差し替えると他人のデータが見えてしまうBOLAのような欠陥が、Webアプリ診断の網から漏れます。
API・Webの脆弱性診断サービスの資料を一括チェック
MCB FinTechカタログでは、API診断に対応した脆弱性診断サービスの最新資料を無料で一括請求できます。診断範囲や料金、対応する診断手法を比べて、自社に合うサービスを選べます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
