APIの脆弱性診断とは？対象範囲・診断内容を解説
Webサービスやスマートフォンアプリの多くは、画面の裏側でAPIを呼び出してデータをやりとりしています。近年は画面側の作り込みが進むほど、処理の実態がAPIに寄っていく傾向にあり、ユーザーに表示される範囲だけを確認する脆弱性診断では、APIに残った不備を見落とすことがあります。
単なるシステム間連携の枠を超えたAPIは、ビジネス成長を牽引する戦略的資産へと進化した一方で、サイバー攻撃の主要なアタックサーフェス（攻撃対象領域）になりました。脆弱性の放置は情報漏えいやサービス停止に直結します。
本記事では、企業のアプリケーション開発者やセキュリティ担当者に向けて、APIの脆弱性診断について概要や対象範囲、確認すべき代表的な脆弱性、適切な実施タイミングを解説します。
目次
APIの脆弱性診断とは
APIの脆弱性診断とは、Webサービスやアプリケーション同士をつなぐAPIに対し、脆弱性がないか、検証を行い評価するプロセスです。
画面を通じた操作だけでなく、その裏側でやりとりされるリクエストとレスポンスに至るまで直接検証します。
APIとは何か
API（Application Programming Interface）とは、異なるシステムやプログラム同士で、機能やデータをやりとりさせるインターフェイスのことです。
Webシステムの領域では、外部地図の表示や、スマートフォンアプリからサーバー内データベースへの接続・連携などのシーンで、幅広く活用されています。
マイクロサービス化やクラウド連携、AI活用が進む現代のシステム開発において、APIはシステム同士をつなぐ不可欠な基盤技術となっています。
API脆弱性診断の対象範囲
APIの脆弱性診断では、概ね以下のような三種類に分類されます。
① Webサイトを通じて呼ばれるAPI
シングルページアプリケーション（SPA）など、ブラウザ上で動作するJavaScriptから非同期通信（Ajaxなど）で呼び出されるAPIです。ユーザーのブラウザ操作にともなって裏側で通信が発生します。
② クライアントアプリ（スマホ・ネイティブアプリ）から呼ばれるAPI
iOSやAndroidなどのスマホアプリ、またはPC向けのデスクトップアプリから、バックエンドのサーバーと通信する際に利用されるAPIです。
③ 画面から直接呼ばれないAPI（仕様書ベースで診断）
外部の提携企業向けに提供しているBtoB向けのAPIや、バックエンドのシステム間連携でのみ使用されるAPIです。利用者の画面には現れず、画面上での操作フローが存在しないため、API仕様書（OpenAPI／Swagger形式など）をベースに、リクエストとレスポンスのサンプルをもとに診断を行います。
Webアプリ診断とAPI診断の関係
多くのセキュリティベンダーでは、API診断を「Webアプリケーション診断」の一部として提供しています。画面操作に伴い呼び出されるAPIも検証対象となるためです。
HTTP/HTTPS通信を行う「Web API」であれば、スマホアプリやシステム間連携も同様の手法で診断できます。そのためAPI診断を単独で探すよりも、Webアプリケーション診断の対象範囲としてどこまで含まれるかを確認するほうが実態に合います。
なお、画面から呼ばれないAPIは別途指定が必要です。
API脆弱性診断の主な手法
APIの脆弱性診断の手法は、大きく2つに分かれます。
- ツール診断
自動リクエストで既知の不備を迅速かつ広範囲に検出。改修ごとの定期確認に適しています。 - 手動診断
診断員が仕様を踏まえながら、ツールでは検出困難な認証・認可やビジネスロジックの不備まで精査します。
実務では、広範囲の一次確認をツールで行い、重要処理を手動で深く見る併用運用が最適です。
脆弱性診断の選び方・進め方を詳しく解説
なぜ脆弱性診断が必要なのか？どのように手法を選べばいいのか？といった疑問をお持ちの方へ向けて、その理由や方法を解説する資料です。
資料ダウンロードAPIの脆弱性診断が重要になっている背景
APIの公開範囲が広がるほど攻撃面も増える
DX（デジタルトランスフォーメーション）の推進やマイクロサービスアーキテクチャーの普及により、企業が公開・運用するAPIの数は爆発的に増加しています。
Akamaiの調査リポートによると、2025年における企業1社あたり1日平均API攻撃件数は258件でした。2024年の121件から113%の増加です。同リポートでは、APIが企業の環境で最も外部にさらされている入口の1つになっていると指摘しています。
出典：Akamai「State of the Internet／Apps, APIs, and DDoS 2026」（2026年3月公開）
APIはプログラムから自動的かつ連続的にアクセスしやすい性質を持つため、ひとたび脆弱性が発見されると、短時間で大量のデータが不正に抽出されてしまうリスクがあります。
他方で、APIは追加や改修の頻度が高く、公開したまま管理台帳に載っていないものが生まれやすい点も大きな課題です。自社の公開資産を把握するASM（Attack Surface Management）の取り組みと併せて考える必要があります。
APIの脆弱性による情報漏えい・不正アクセスの例
実際に、APIの脆弱性を突かれたことによる大規模なセキュリティインシデントは多数発生しています。
海外の大手通信会社では、約3,700万の現行ポストペイド／プリペイド顧客アカウントに関するデータが漏えいする事件が起きました。流出した情報には、氏名、請求先住所、メールアドレス、生年月日、電話番号、アカウント番号、回線数、料金プランおよびその機能に関する情報などが含まれていたことが報告されています。同社は米国証券取引委員会（SEC）への提出書類で、単一のAPIを通じて権限なくデータを取得されていたと説明しています。
2025年には、ある採用プラットフォームで、APIのアクセス制御不備により、本来は閲覧権限のない応募者情報に不正アクセスできる状態になっていることが研究者によって発見されました。APIリクエスト内の応募者識別子を変更すると、別の応募者情報を取得できたと報じられています。これは、認証済みの利用者に対するデータ単位の権限確認が不十分なIDORの事例です。提供事業者は、報告を受け速やかに対応し、研究者による限定的な確認を除いて外部流出・公開の事実は確認されていないと説明しています。
APIの脆弱性診断で確認する主な脆弱性
近年のAPIはREST型に限らず、GraphQLやWebSocket、gRPCなど通信方式が多様化しています。方式が変われば、脆弱性の現れ方も異なります。
| 通信方式 | 特徴 | 固有の確認観点 |
|---|---|---|
| REST | ・HTTPベースの標準的な方式 ・シンプルで広く利用 | ・認証や認可の設定 ・不正なパラメータの検証 |
| GraphQL | ・1つのエンドポイントで複数取得 ・柔軟なクエリ指定が可能 | ・クエリの複雑性・深さの制限 ・情報漏えい（過剰取得）の防止 |
| WebSocket | ・双方向のリアルタイム通信 ・長時間のコネクションを維持 | ・メッセージの妥当性検証 ・切断・再接続時の挙動確認 |
| gRPC | ・Protocol Buffersによる高効率な通信 ・マイクロサービスで多用 | ・server reflectionの確認 ・サービス間の認証・認可の確認 |
本章では、通信方式を問わず共通して確認される代表的なAPIの脆弱性・セキュリティリスクを挙げます。以下の分類は、「OWASP API Security Top 10 2023」で挙げられている観点を中心に、実務上の確認項目として整理したものです。
認可の不備（BOLA・機能レベル認可）
APIの脆弱性の中でも特に多く、かつ影響が甚大なのが「認可」の不備です。
認可の不備とは、認証（本人確認）は正しく行われているのに、他人のデータや本来使えない機能にアクセスできてしまう状態です。代表的なものにBOLA（Broken Object Level Authorization）が挙げられます。
管理者用の機能を一般の利用者が呼び出せる機能レベルの認可不備も、併せて確認する必要があるでしょう。
過剰なデータ返却
過剰なデータ返却とは、画面には表示されない情報まで、レスポンスに含めて返してしまう状態です。
画面上は問題なく見えても、データベースから取得したオブジェクトの全データ（パスワードのハッシュ値、内部ID、個人情報など）をひとまとめにしてレスポンスとして返してしまう脆弱性です。APIの診断では画面の表示ではなく、レスポンスそのものを見て確認します。
ビジネスロジックの悪用
クーポンやプロモーションコードの不正連続適用や在庫の買い占めのように、機能そのものは正常でも業務上の想定を超えた使われ方ができないかを確認します。
認証機能の不備
認証機能の不備とは、APIを呼び出すユーザーが正規の人物かを確認する「認証」の仕組みに欠陥がある状態を指します。
認証トークン（JWTなど）の署名検証が行われていない、有効期限が極端に長い、認証情報のパスワードが平文で送信されているなどの問題が該当します。認証が突破されると、攻撃者に正規ユーザーとしてシステムを完全に操作されるおそれがあるため注意が必要です。
APIは画面を持たないぶん認証処理を独自に実装している場合も多く、設計と実装の両面から確認します。
入力値・パラメーターの改ざん
入力値の検証不備とは、クライアント側から送信されるリクエストのパラメーター、HTTPヘッダー、JSONの入力値などに対して、サーバー側で適切な検証（バリデーション）が行われていない脆弱性です。
SQLインジェクションやOSコマンドインジェクションなどのように古くから知られた攻撃は、APIでも成立し、深刻なサイバー攻撃を許す原因となります。また、意図しないパラメーターを送信して権限やデータを書き換える「マスアサインメント」も含まれます。
画面側でしか入力チェックを行っていない場合、APIへ直接リクエストを送られると検証を通過するため、サーバー側での検証を確認します。
サーバーサイドリクエストフォージェリ（SSRF）
サーバーサイドリクエストフォージェリ（SSRF）とは、利用者が指定したURLを、サーバー側が適切に検証せずに取得することで、本来は外部から直接アクセスできない内部システムやクラウドサービスへリクエストが送信される脆弱性です。
画像のURL取得、外部サイトからのコンテンツ取り込み、URLプレビュー、Webhookの登録・送信など、URLを受け取ってサーバー側で通信するAPIが対象になります。クラウド環境では、設定情報や一時的な認証情報を提供するメタデータサービスにアクセスされるおそれがあります。
SSRFの確認では、URLを受け取るAPIが、許可先以外や内部IP、リンクローカルアドレス、意図しないポートへの通信制限ができているかを確認します。
設定不備
設定不備とは、動作はするものの安全でない設定のまま公開されている状態です。
たとえば、本来不要なHTTPメソッド（PUT、DELETEなど）が許可されていたり、詳細なエラーメッセージ（スタックトレースやデータベースの構造）がレスポンスにそのまま表示されたりするケースが代表的です。これらの情報は、攻撃者がさらなる攻撃を計画するためのヒントを与えてしまいます。
APIの脆弱性診断を実施すべきタイミング
自社のAPIの数が少ない場合であっても、たった1つの脆弱性が致命的なインシデントに直結するため、API脆弱性診断は必須です。
ここでは、APIの脆弱性診断を実施すべき具体的なタイミングを解説します。
新規API公開前・大規模改修後
最も重要で確実なタイミングは、新規開発がテストまで完了し、APIを本番環境へ公開する前です。
認可の判定やエラー処理は、実際にリクエストを送って確かめなければなりません。設計や実装の段階で入り込んだ脆弱性を、サービスが稼働する前に洗い出して修正します。既存のAPIでも、機能追加やアーキテクチャーの変更など、システムに大規模な改修を加えたあとであれば、新たな脆弱性が発生している可能性が高いため、リリース前の診断が不可欠です。
外部連携・認証方式の変更時
外部サービスとの連携を追加したときや、OAuth、SAMLといった認証・認可の仕組みを新たに導入・変更した際も診断が必要です。
例として、サービス利用者が外部のSNSアカウントなどでログインできるような機能では、実装の不備によりアカウントの乗っ取りにつながるような脆弱性も考えられます。
外部システムとの境界でありセキュリティ上の重要性が高いため、 専門家による詳細な検証を通じた安全確認が強く推奨されます。
ISMS/SOC 2など監査対応前
ISMS（情報セキュリティマネジメントシステム）、プライバシーマーク、SOC2などの第三者認証を取得・更新する際、システムの安全性を客観的に証明するエビデンスとして脆弱性診断のリポートが求められるケースがあります。
取引先からのセキュリティ評価でも、第三者による診断の実施記録は確認されやすい項目です。監査の直前は日程に余裕がないため、必要な範囲を早めに整理しておくと進めやすくなります。
インシデントが発生したあとの総点検
不正アクセスや情報漏えいが起きたあとは、間違いなく診断を行うタイミングです。
原因になったAPIを直すだけでは、同じ設計上の問題がほかのAPIに残っている可能性があります。公開中のAPIをまとめて確認し、同種の不備がないかを洗い出すことで、再発の余地を減らすことができます。
取引先への説明でも、範囲を絞らずに点検した記録は説得力のある材料となりえます。
脆弱性診断・API棚卸しのタイミング
APIは追加と改修が続くため、一度の診断で終わりにはできません。運用の中で新たな脆弱性が生まれる可能性があるためです。また、使われなくなった古いAPI（ゾンビAPI）が放置され、攻撃の起点となるケースも少なくありません。
定期的な脆弱性診断と併せて公開中のAPIを診断し、システムに存在するAPIの棚卸しと脆弱性診断を継続的に行うことが重要です。
関連記事：脆弱性管理とは？実施プロセスや運用のポイント、脆弱性診断との違いを解説
APIセキュリティを強化するための基本対策
API脆弱性診断により発覚した不備を直すだけでなく、同じ問題を作り込まない仕組みを組み込んでいく必要があります。
ここでは開発と運用の両面で取り組める、基本的な対策について解説します。
認証・認可を設計段階から見直す
認証・認可の設計は開発の初期段階から行い（シフトレフト）、 リクエストごとにサーバー側で行う設計にします。適切な認証方式の選定と、オブジェクトレベル・機能レベルでの厳格な認可チェックのロジックを実装する仕組みを構築しておきましょう。
画面の出し分けやクライアント側の制御だけに頼らないことが前提です。誰がどのデータに触れてよいかを設計段階で整理しておくと、実装後の手戻りを減らせます。
キー・トークン・通信を適切に管理
APIキーやトークンは、パスワードと同等の機密情報です。ソースコード内へのハードコーディングを避け、安全なストレージで管理するとともに、権限の範囲と有効期限を絞って発行します。
また、漏えいが判明したときにすぐ失効できる手順を用意しておくことも重要です。通信はすべて暗号化し、平文でのやりとりを残さない運用を基本とします。
ログ監視とAPI台帳で継続管理
システム内にどのようなAPIが存在するかを可視化するため、APIごとにアクセスログを取得し、通常と異なる呼び出しに気づける状態にします。
併せて公開中のAPIを一覧化した台帳を維持し、追加や廃止のたびに更新しましょう。把握できていないAPIには対策も診断も届かないため、台帳の整備が出発点です。
GMOイエラエのAPIを含めた脆弱性診断サービス／ツール
GMOサイバーセキュリティ byイエラエでは、システムの特性や運用フェーズに合わせて、最適なサービス／ツールをご提案しています。
公開APIサーバーを対象にするなら
インターネットに公開しているサーバーをスピーディーに幅広く把握したい場合は、GMOサイバー攻撃 ネットde診断 ASMが向いています。
自社のドメインをもとに公開資産を自動で洗い出し、Webアプリケーション、ネットワーク、CMSの観点で定期的に診断するサービスです。位置づけとしては健康診断にあたり、広く浅く状態を確認する用途です。
個々のAPIを詳しく調べる精密検査は、後述のWebアプリケーション診断が担います。
WebアプリケーションからAPIまで詳しく診断するなら
APIの詳細な検証に適しているのは、ホワイトハッカーが診断するWebアプリケーション診断です。REST以外の通信方式も、GraphQL、gRPC、WebSocketを対象とした診断実績があります。
ブラウザ上の操作やスマートフォンアプリから呼び出されるAPIは、画面をたどって通信を確認できるため、通常のWebアプリケーション診断の範囲に含められます。
画面上の操作フローが存在しないBtoB向けAPIなどの場合は、API仕様書（OpenAPI／Swagger形式など）をご提出いただき、リクエストとレスポンスのサンプルをもとに診断します。
Webアプリケーション診断及びネットde診断 ASMは、経済産業省が定める「情報セキュリティサービス基準」に適合したサービスでもあります。同基準に適合するサービスとして「情報セキュリティサービス台帳」に登録されています。第三者による脆弱性診断であることを、社内や取引先へ説明する材料としても使えます。
どのサービスが自社のAPIに合うか判断が難しい場合は、対象範囲の整理からご相談いただけます。APIの脆弱性診断をご検討の際は、GMOイエラエへお問い合わせください。
監修：GMOサイバーセキュリティ byイエラエ 編集部
企業の情報セキュリティ担当者や開発者向けに、サイバーセキュリティに関する情報を発信しています。
