API脆弱性診断とは？Webアプリ診断との違いと実施すべき理由

APIとは何か――なぜ今、API診断が重要なのか

API（Application Programming Interface）とは、異なるソフトウェア・システム間でデータや機能をやり取りするための「接続口」です。スマートフォンアプリがサーバーからデータを取得する、ECサイトが決済サービスと連携する、SaaSが外部サービスとデータを同期する――これらすべての裏側でAPIが機能しています。

現代のWebサービスやモバイルアプリは、APIなしには成立しないといっても過言ではありません。実際、Akamai Technologies社の調査によれば、2023年のインターネットトラフィック全体の約83%がAPIトラフィックであるという統計があります。APIはデジタルビジネスの血管ともいえる存在です。

API経由の攻撃は急増している

しかし、APIの普及と表裏一体で、APIを標的にしたサイバー攻撃も急増しています。

Imperva社の「State of API Security 2024」レポートによれば、APIへの攻撃は2023年から2024年にかけて前年比で大幅に増加し、特に認証・認可の不備を悪用した攻撃と、データの過剰露出を狙った攻撃が増加しています。

Verizon社の「Data Breach Investigations Report 2024」でも、Webアプリケーション攻撃がすべてのインシデントカテゴリの中でトップに位置し、その多くはAPIエンドポイントへの攻撃が含まれています。

なぜWebアプリ診断だけでは不十分か

従来のWebアプリ脆弱性診断は、ブラウザを通じて操作できる画面ベースの機能を対象としていました。しかし現代のWebアプリは、フロントエンドとバックエンドが分離したSPA（Single Page Application）アーキテクチャや、マイクロサービス構成を採用するケースが増えており、裏側で動くAPIが直接外部に公開されています。

このような構成では、APIエンドポイントに対して直接リクエストを送ることで、画面UIを通じては到達できないデータや機能にアクセスできてしまうケースがあります。従来のWebアプリ診断ツールはブラウザ操作を前提としているため、このようなAPI固有の脆弱性を見落とすことがあります。

「Webアプリ診断を毎年実施しているからAPIは大丈夫」というのは誤解です。APIには専門の診断が必要です。

OWASP API Security Top 10（2023年版）を理解する

API固有のセキュリティリスクを体系化したものが、OWASP（Open Web Application Security Project）が公開する「OWASP API Security Top 10」です。最新版は2023年に更新され、現在もAPI診断の国際標準として参照されています。

API1:2023 — オブジェクトレベルの認可の不備（BOLA）

最も重大なAPIリスクとされているのが「Broken Object Level Authorization（BOLA）」です。例えば、/api/users/123/profile というエンドポイントで、自分のID（123）以外のID（456）に変更するだけで他ユーザーのデータにアクセスできてしまうケースです。

このリスクはツール診断ではほとんど検出できません。テスト対象のアプリケーションの仕様を理解した上で、手動で検証する必要があります。

API2:2023 — 認証の不備（Broken Authentication）

APIトークンの不適切な管理、期限切れトークンの有効化、弱いパスワードポリシー、不十分なブルートフォース対策など、認証機能全般の欠陥です。JWTトークンの改ざん、OAuth/OIDC実装の不備なども含まれます。

API3:2023 — オブジェクトプロパティレベルの認可の不備（BOPLA）

API2019のExcessive Data Exposure（過剰データ露出）とMass Assignmentを統合したリスクです。APIレスポンスに必要以上のデータが含まれる（パスワードハッシュや内部IDなど）、またはリクエストパラメータを大量に受け入れることで意図しない属性を更新できてしまうケースです。

API4:2023 — リソースとレートリミットの不備

APIにレートリミット（単位時間あたりのリクエスト数制限）が設定されていない場合、ブルートフォース攻撃やクレデンシャルスタッフィング攻撃、またはサービス拒否（DoS）攻撃が可能になります。

API5:2023 — 機能レベルの認可の不備（BFLA）

通常ユーザーには許可されていない管理機能（ユーザー削除、権限変更、システム設定の変更など）に、適切な認可確認なしにアクセスできてしまう脆弱性です。APIエンドポイントは画面UIから隠れているため、開発者が「どうせユーザーには見えない」と認可チェックを省略するケースがあります。

API6:2023 — サーバーサイドリクエストフォージェリ（SSRF）

APIがユーザー提供のURLを受け取ってリクエストを行う実装において、内部ネットワーク・クラウドメタデータへのアクセスや、内部サービスへのプロキシとして悪用される脆弱性です。クラウド環境（AWS、Azure、GCP）では特に深刻なリスクとなります。

クラウド環境の設定リスクについては クラウド設定ミスが招くリスクと対策：AWS・Azure事例解説 も参照してください。

API7:2023 — セキュリティの設定ミス

デフォルト設定のまま運用、不必要なHTTPメソッドの有効化、CORSの過度に緩い設定、エラーメッセージへの機密情報の混入、不要なエンドポイントの公開などが含まれます。

API8:2023 — 自動化された脅威への脆弱性

ビジネスフロー（会員登録、購入、コンテンツ投稿等）を自動化された手段で悪用することを可能にする脆弱性です。チケットの大量買い占め、スパムアカウントの作成、プロモーションコードの不正利用などが典型例です。

API9:2023 — 不適切なインベントリ管理

ドキュメント化されていないAPIエンドポイント（シャドーAPI）、古いバージョンのAPIの放置、テスト用APIの本番環境残存などです。管理されていないエンドポイントはセキュリティパッチが適用されないまま残ることが多く、攻撃者にとって格好の標的となります。

API10:2023 — APIの安全でない利用

外部APIやサードパーティサービスを呼び出す際に、そのレスポンスを適切に検証せずに利用することで生じる脆弱性です。信頼された外部APIが侵害された場合、自社システムへの連鎖攻撃が可能になります。

WebアプリとAPI診断の違い：5つの重要な差異

Webアプリ診断とAPI診断は、どちらもWebアプリケーションのセキュリティ評価ですが、技術的アプローチと診断項目に明確な違いがあります。

差異1：認証・認可の検証方法

Webアプリ診断では、画面ログイン後のセッション管理やCSRF対策を主に評価します。一方、API診断ではJWT（JSON Web Token）、OAuth 2.0、APIキーなど、API固有の認証メカニズムの実装を検証します。特に「あるユーザーのAPIトークンで別ユーザーのリソースにアクセスできるか」（BOLA）の検証はAPI診断の核心です。

差異2：オブジェクトレベルの認可テスト

APIのリソース操作（CRUDオペレーション：作成・読み取り・更新・削除）のすべてに対して、適切な認可が実装されているかを個別に検証します。画面UIには表示されない内部APIエンドポイントも診断対象に含める必要があります。

差異3：レートリミット・スロットリングの検証

APIは自動化されたリクエストの標的となりやすいため、レートリミットの実装を検証します。認証エンドポイントへのブルートフォース攻撃、ビジネスロジックエンドポイントへの自動化された悪用（API8）の検証はAPI診断特有の項目です。

差異4：データ露出の詳細検証

APIレスポンスに含まれるデータを精査し、不要な情報（パスワードハッシュ、内部ID、個人情報など）が含まれていないかを確認します。特にGraphQL APIではクエリの柔軟性が高いため、過剰なデータ取得（Introspection攻撃、Deep Query攻撃）への対策も評価します。

差異5：APIドキュメントとインベントリの確認

診断前にAPIのエンドポイント一覧（Swagger/OpenAPI仕様書）を収集し、ドキュメント化されていないエンドポイントが存在しないかを確認します。シャドーAPIの発見はAPI診断の重要な目的の一つです。

REST・GraphQL・gRPCそれぞれの診断ポイントの違い

REST APIの診断ポイント

RESTful APIは現在最も広く使われているAPIアーキテクチャです。以下のポイントが診断の中心となります。

• HTTPメソッドの適切な使用：GETリクエストで状態変更が発生しないか、DELETEリクエストに認可チェックがあるか
• パラメータの検証：URLパラメータ、クエリパラメータ、リクエストボディの入力検証（SQLインジェクション、コマンドインジェクションを含む）
• HATEOASとリソース設計：リソースIDの予測可能性（連番IDによるBOLA）
• エラーレスポンスの検証：エラーメッセージに内部情報（スタックトレース、DB情報）が含まれていないか
• CORSポリシー：過度に緩いCORSヘッダーの設定（Access-Control-Allow-Origin: *）

GraphQL APIの診断ポイント

GraphQLは柔軟なクエリ言語を提供するため、RESTとは異なる固有のリスクがあります。

• Introspectionの制御：本番環境でIntrospectionクエリが有効になっており、スキーマ全体が外部に公開されていないか
• クエリの深さ・複雑度制限：深くネストされたクエリやフィールドを大量取得するクエリによるDoS攻撃への対策
• バッチングとN+1問題の悪用：クエリのバッチ化を利用したレート制限回避
• ミューテーションの認可：データ変更・削除操作に適切な認可チェックがあるか
• フィールドレベルの認可：特定のフィールドへのアクセスに権限チェックが実装されているか

gRPC APIの診断ポイント

gRPCはProtocol Buffersを使ったバイナリプロトコルで、マイクロサービス間通信で多く使われます。

• TLS/SSL設定の検証：通信の暗号化が適切に実装されているか
• 認証メカニズム：メタデータによる認証（Authorization ヘッダー相当）の実装
• サービス定義ファイル（.proto）の保護：プロトコル定義が外部に漏洩していないか
• エラーハンドリング：gRPCのステータスコードに内部情報が含まれていないか
• ストリーミングの悪用：双方向ストリーミングを悪用したリソース枯渇攻撃

API診断で発見できる主な脆弱性の例

実際のAPI診断でよく発見される脆弱性を具体的に紹介します。

事例1：他ユーザーの注文情報が閲覧可能（BOLA）

ECサイトのAPI /api/orders/{order_id} において、自分の注文ID以外のIDを入力しても認可チェックが行われず、他ユーザーの注文詳細（氏名・住所・決済情報の一部）が閲覧できる状態。ツール診断ではほぼ検出不可能で、マニュアル診断によって発見。

事例2：管理者APIが認証なしで公開（BFLA）

ドキュメント化されていない管理用APIエンドポイント /api/admin/users が認証なしで公開されており、全ユーザーの個人情報一覧が取得可能。フロントエンドの画面には表示されないため、Web診断では発見されなかった。

事例3：JWTの署名検証が無効化されていた（認証の不備）

JWTトークンのアルゴリズムを RS256 から none に変更することで署名検証をバイパスし、任意のユーザーとして操作できる状態。実装ライブラリの設定ミスが原因。

事例4：レートリミット未設定でパスワードリセットを悪用

パスワードリセット用のAPIにレートリミットが設定されておらず、特定メールアドレスに対して大量のリセットメールを送信することが可能。スパム攻撃のベクトルとなりえた。

事例5：GraphQL Introspectionが本番環境で有効

本番APIでGraphQLのIntrospectionが有効であり、攻撃者がスキーマ全体（エンドポイント名・引数・データ型）を取得できる状態。攻撃の準備段階として悪用されうる。

API診断の実施タイミング

タイミング1：リリース前（最重要）

新規APIのリリース前は、API診断を実施する最も重要なタイミングです。本番公開後に重大な脆弱性が発見された場合、修正・再デプロイのコストはリリース前の修正の数十倍になることがあります。特に外部公開APIや個人情報を扱うAPIはリリース前の診断を必須としてください。

開発プロセスにセキュリティテストを組み込む「シフトレフト」アプローチとして、APIの設計・開発段階から診断を計画することが理想的です。

タイミング2：定期実施（年1回以上）

既存APIも継続的な診断が必要です。理由は以下のとおりです。

• 依存するライブラリ・フレームワークの更新により新たな脆弱性が生まれる
• ビジネス要件の変更に伴うAPIの仕様変更で、既存の認可ロジックが崩れる場合がある
• OWASP API Security Top 10などのリスクリストが更新される

PCI DSS準拠が必要な場合は、カード情報を扱うAPIについて年1回以上の診断が義務付けられています。

タイミング3：メジャーバージョンアップ時

APIのメジャーバージョンアップ（v1からv2へなど）は、大規模な仕様変更を伴うため、必ず診断を実施してください。古いバージョンのAPIを廃止せずに並行稼働させる場合、古いバージョンがセキュリティパッチの対象外になるリスクも検証が必要です。

タイミング4：サードパーティAPIとの新規連携時

外部APIとの連携を追加する際も診断のチャンスです。自社APIが外部システムとの連携により、意図しない脆弱性が生まれることがあります（SSRF、インジェクション攻撃の連鎖など）。

Webアプリ診断とAPI診断の組み合わせ方

現代のWebアプリケーションでは、フロントエンドのWebアプリ診断とバックエンドのAPI診断を組み合わせることが重要です。

推奨される組み合わせは以下のとおりです。

診断費用の詳細な相場については Webアプリ脆弱性診断の費用相場と会社の選び方【2026年版】 を参照してください。

また、ペネトレーションテストとの使い分けについては ペネトレーションテストと脆弱性診断の違い――どちらを選ぶべきか で詳しく解説しています。

API診断のプロセス：何が行われるのか

AEVUSのAPI脆弱性診断では、以下のプロセスで実施されます。

フェーズ1：情報収集・仕様確認

APIの仕様書（OpenAPI/Swagger、GraphQLスキーマなど）を収集し、エンドポイントのインベントリを作成します。ドキュメント化されていないエンドポイントの探索も実施します。

フェーズ2：認証・認可の検証

すべての認証メカニズムを検証し、認可バイパスの可能性を評価します。各エンドポイント・HTTPメソッドに対して水平権限昇格・垂直権限昇格のテストを実施します。

フェーズ3：ビジネスロジックのテスト

APIが意図しない方法で使用された場合のリスクを検証します。レートリミット、ワークフローのバイパス、データの整合性チェックなどを確認します。

フェーズ4：入力値・データ検証

各エンドポイントへのインジェクション攻撃（SQLi、コマンドインジェクション、XXE、SSRF等）のテストと、レスポンスデータの過剰露出の確認を実施します。

フェーズ5：報告書作成・修正支援

発見された脆弱性をOWASP API Security Top 10に基づいて分類し、重大度（Critical/High/Medium/Low）を評価。具体的な修正方法とテストコードを含む詳細な報告書を提供します。

AEVUS のAPI脆弱性診断サービスについて

AEVUSは、大手金融機関からSaaSプロダクトまで、幅広いAPI診断実績を持つセキュリティ専門ブランドです。

Webアプリ・API脆弱性診断サービス では、OWASP API Security Top 10（2023年版）に準拠した網羅的な手動診断を提供しています。REST・GraphQL・gRPCすべてに対応しており、OpenAPI仕様書ベースの体系的な診断から、シャドーAPIの探索まで実施します。

API脆弱性診断のご相談・お見積もりは サービスページ からお気軽にお問い合わせください。

よくある質問（FAQ）

Q1. REST APIとGraphQL APIのどちらがセキュリティリスクが高いですか？

一概にどちらが高いとは言えません。RESTは設計のシンプルさゆえに認可の実装漏れが起きやすく、GraphQLはクエリの柔軟性ゆえにIntrospectionやDeep Query攻撃などGraphQL固有のリスクがあります。どちらのAPIも適切な診断が必要です。

Q2. 内部APIも診断が必要ですか？

内部APIであっても診断を推奨します。理由は以下のとおりです。外部に直接公開されていない内部APIも、SSRFやマイクロサービス間のトラフィックを経由して攻撃される可能性があります。また、内部不正者によるアクセスのリスクも考慮する必要があります。

Q3. API診断の費用はWebアプリ診断と比べて高いですか？

API診断は通常、エンドポイント数・機能の複雑さをベースに費用が算出されます。一般的にWebアプリ診断と同程度か、APIの複雑さ・数が多い場合はそれ以上になることがあります。詳細な費用については Webアプリ脆弱性診断の費用相場と会社の選び方【2026年版】 をご覧ください。

Q4. APIキーが漏洩した場合、どんなリスクがありますか？

APIキーが漏洩すると、攻撃者はそのAPIキーに紐付いた権限を持つすべての操作を実行できます。データの取得・変更・削除、課金の発生（クラウドAPIの場合）、スパムメールの送信などが典型的な被害です。APIキーはGitHubなどの公開リポジトリに誤ってコミットされるケースも多く、定期的なローテーションと漏洩検知の仕組みが重要です。

Q5. 開発中のAPIに対して診断を実施できますか？

可能です。開発環境・ステージング環境でのAPI診断も対応しています。本番リリース前に診断を実施することで、修正コストを大幅に削減できます。Swagger/OpenAPIの仕様書だけで診断を開始することも可能ですので、早期段階でのご相談をおすすめします。

Q6. マイクロサービスアーキテクチャの場合、どのAPIを診断すればよいですか？

まず外部（インターネット）に公開されているAPIゲートウェイ・エンドポイントを優先的に診断してください。次に、個人情報・決済情報・認証情報を扱うサービスへの診断を実施します。内部サービス間のgRPC通信については、プラットフォーム診断との組み合わせが効果的です。

Q7. OWASP API Security Top 10は毎年更新されますか？

OWASP API Security Top 10は定期的に更新されており、直近では2019年版から2023年版に大幅改訂されました。2019年版と2023年版では一部のリスク項目の名称・内容が変更されているため、「以前の診断でOWASP対応済み」という認識がある場合も、最新版への対応確認が必要です。

まとめ

API脆弱性診断について、重要なポイントをまとめます。

• APIトラフィックはWebトラフィック全体の83%以上を占め、攻撃者の標的としても急増している
• OWASP API Security Top 10（2023年版）がAPI固有リスクの国際標準。BOLA（オブジェクトレベル認可不備）が最重要リスク
• Webアプリ診断では不十分：認証・認可・レートリミット・データ露出など、API固有の検証項目がある
• REST・GraphQL・gRPCそれぞれに固有の診断ポイントがあり、対象に合わせたアプローチが必要
• 実施タイミング：リリース前・定期実施・メジャーバージョンアップ時・サードパーティ連携時

APIを公開しているすべての事業者にとって、API脆弱性診断は「あれば良い」ではなく「必要なセキュリティ対策」となっています。特にSaaS、フィンテック、ヘルスケア、EC領域では、APIの脆弱性が直接的なデータ漏洩・サービス悪用につながるリスクがあります。