APIは現代のWebサービスやモバイルアプリに欠かせない存在ですが、その普及に伴い、APIを狙ったサイバー攻撃も急増しています。認証・認可の不備やデータの過剰公開といったAPI固有の脆弱性は、情報漏えいや不正アクセスに直結するため、APIに特化したセキュリティ対策が欠かせません。
本記事では、APIが狙われる背景からOWASP API Security Top 10の要点、開発ライフサイクルを通じた対策、脆弱性診断の進め方まで、実務で押さえておきたいポイントを整理しています。
APIへのサイバー攻撃は年々増加しています。その背景にあるのが、API活用の急速な拡大です。なぜ今APIが狙われやすいのか、API攻撃にはどのような特徴があるのかを押さえておきましょう。
マイクロサービスアーキテクチャの普及やモバイルアプリ・SaaS連携の増加に伴い、企業が運用するAPIの数は急速に増えています。フロントエンドとバックエンドの分離が進んだことで、かつてはサーバー内部で完結していたデータのやり取りがAPI経由で行われるようになりました。
APIの数が増えれば、攻撃者がアクセスできるエンドポイントも増えます。これが「アタックサーフェス（攻撃対象領域）の拡大」です。Impervaの調査レポートでは、APIトラフィックがWebトラフィック全体の過半数を占めるまでに成長していると報告されており、攻撃対象としてのAPIの存在感が年々大きくなっていることがわかります。
参考：The State of API Security in 2024｜Imperva
加えて、開発スピードを優先するあまり、セキュリティ設計が後回しになるケースも少なくありません。IT部門やセキュリティチームが把握していない「シャドウAPI」が存在することもあり、管理されていないAPIが脆弱なまま放置されるリスクも指摘されています。
APIを狙う攻撃は「ビジネスロジックの悪用」が中心です。たとえば、リクエストパラメータを改ざんして他のユーザーのデータにアクセスする「BOLA（Broken Object Level Authorization）」は、リクエスト自体は正常な形式であるため、WAFでは検知が困難です。正規のリクエストを少し変えるだけで機密情報にたどり着けてしまうため、従来のセキュリティ対策では防ぎきれないケースがあります。
実際に、米CISAが公開するKEVカタログ（実際に悪用が確認された脆弱性のリスト）にも、APIの認可不備や認証バイパスに起因する脆弱性が継続的に追加されています。APIを経由した攻撃が実環境で発生し続けている証拠であり、もはやAPIセキュリティは「やったほうがいい対策」ではなく「やらなければならない対策」になっています。
参考：Known Exploited Vulnerabilities Catalog｜CISA
このように、APIは「外部から見えやすく、かつWAFをすり抜けやすいビジネスロジックの脆弱性を抱えがち」という特徴があります。
運用フェーズに入ってからWAFや監視だけで防ぐことには限界があるため、開発段階やリリース前の「テスト」のフェーズで、APIに潜在するビジネスロジックの不備や認可の欠陥を洗い出しておくことが重要です。
APIのセキュリティリスクを体系的に把握するうえで欠かせないのが、OWASPが公開している「OWASP API Security Top 10」です。2023年に改訂された最新版では、API特有のリスクが10項目にまとめられています。とくに影響が大きいリスクを中心に確認していきましょう。
OWASP API Security Top 10の上位を占めるのが、認証・認可に関するリスクです。
API1:2023 Broken Object Level Authorization（BOLA）は、リクエスト内のオブジェクトIDを変更するだけで、本来アクセスできないはずの他ユーザーのデータを取得できてしまう脆弱性です。たとえば、/api/users/123/ordersというURLの「123」を「456」に書き換えるだけで別のユーザーの注文履歴が見えてしまうケースが該当します。サーバー側でリクエストごとにアクセス権限を検証していないことが原因です。
API2:2023 Broken Authenticationは、認証メカニズム自体の不備を指します。脆弱なパスワードポリシー、トークンの有効期限管理の不備、ブルートフォース対策の欠如などが原因で、攻撃者が正規ユーザーになりすましてAPIにアクセスできてしまうリスクです。
これらは「誰がアクセスしているか（認証）」と「その人が何にアクセスできるか（認可）」というセキュリティの根幹にあたる問題であり、一度突破されると情報漏えいや権限の不正利用に直結します。
API3:2023 Broken Object Property Level Authorizationは、2019年版で別々に挙げられていた「過剰なデータ公開」と「一括割当（Mass Assignment）」が統合されたカテゴリです。
データの読み取り時（旧：過剰なデータ公開）
APIのレスポンスが表示に必要な項目だけでなく、内部ID・メールアドレス・権限情報などを含んでしまうケースが典型的な例です。画面上では非表示にしていても、APIレスポンスを直接確認すれば機微情報が見えてしまいます。
データの書き込み時（旧：一括割当）
ユーザープロフィールの更新APIなどで、本来変更できないはずの「is_admin: true（管理者フラグ）」といったパラメータをリクエストに含めて送信すると、サーバー側でそのまま書き換えられてしまうケースがあります。
API4:2023 Unrestricted Resource Consumptionは、APIへのリクエスト回数や処理量に上限が設けられていない状態を指します。レート制限がなければ、短時間に大量のリクエストを送信するだけでサービス停止に追い込めます。DDoS攻撃だけでなくパスワード総当たり攻撃にも悪用されるため、エンドポイントごとの適切な制限設計が重要です。
上位4項目以外にも、以下のリスクがOWASP API Security Top 10（2023年版）に含まれています。
| リスク番号 | リスク名 | 概要 |
|---|---|---|
| API5:2023 | Broken Function Level Authorization | 管理者向け機能に一般ユーザーがアクセスできてしまう認可の不備 |
| API6:2023 | Unrestricted Access to Sensitive Business Flows | 自動化による大量購入やスクレイピングなど、ビジネスフローの悪用（2023年版で新設） |
| API7:2023 | Server Side Request Forgery（SSRF） | 外部入力を使ってサーバーから内部リソースへリクエストを送信させる攻撃（2023年版で新設） |
| API8:2023 | Security Misconfiguration | デバッグモードの有効化、不要なHTTPメソッドの許可などの設定ミス |
| API9:2023 | Improper Inventory Management | 古いバージョンのAPIやドキュメント化されていないエンドポイントの放置 |
| API10:2023 | Unsafe Consumption of APIs | サードパーティAPIからのデータを検証せず信頼してしまうリスク（2023年版で新設） |
2023年版では、2019年版から3つのカテゴリ（API6・API7・API10）が新設されました。とくにAPI6の「ビジネスフローの悪用」とAPI10の「外部APIの安全でない利用」は、マイクロサービス化やサードパーティ連携の増加を反映した追加項目です。現在のAPI活用環境を踏まえると見逃せないリスクといえるでしょう。
参考：OWASP API Security Top 10 - 2023｜OWASP Foundation
APIのセキュリティリスクは、特定のフェーズだけで対処できるものではありません。ポイントは、設計・開発・テスト・運用の各段階で対策を積み重ねること、そしてセキュリティ対策を開発の早期フェーズから組み込む「シフトレフト」の考え方を実践することです。それぞれのフェーズで取るべきアクションを整理していきます。
APIセキュリティの土台は設計段階で決まります。開発が始まってから認証方式を変更したり、レスポンスのデータ構造を見直したりするのは、手戻りコストが大きくなるためです。
設計フェーズでとくに検討すべき項目は次の4つです。
| 検討項目 | 内容 |
|---|---|
| 認証・認可方式の選定 | OAuthやJWTなど、APIの用途に適した仕組みを選び、オブジェクトレベルでのアクセス制御を設計に組み込む |
| レスポンスデータの最小化 | レスポンスには画面表示や処理に必要な最小限の項目だけを含め、バックエンドのテーブル構造がそのまま見えてしまうような、内部IDや不要な機微情報を返さない設計にする。 |
| レート制限・リソース制御 | エンドポイントごとにリクエスト上限を定め、大量データ取得による負荷を防ぐため、ページネーションや1回あたりの最大取得件数の上限も設定する。 |
| API仕様の文書化 | OpenAPI（Swagger）などの標準仕様でAPIの入出力を定義し、仕様と実装の乖離を防ぐ |
開発・テストフェーズでは、設計段階で定めたセキュリティ要件が実装に反映されているかを検証します。主な手法は以下の3つです。
DAST（動的アプリケーションセキュリティテスト）は、実際に稼働しているAPIにリクエストを送信し、応答から脆弱性を検出する手法です。API仕様書（OpenAPIなど）をインポートできるツールを選ぶと、テスト範囲の漏れを防げます。
SAST（静的解析セキュリティテスト）は、ソースコードを実行せずに解析し、コードレベルの問題を早期に発見する手法です。ただし、認可ロジックの不備やレスポンスの過剰公開など、実行時の振る舞いは検出対象外のため、DASTとの併用が前提になります。
ファズテストは、APIに対してランダムなデータや異常な入力値を大量に送信し、予期しないエラーやクラッシュを引き起こすことでセキュリティ上の弱点を探り出す手法です。開発者が想定していない入力パターンに対する脆弱性の発見に効果的です。
手動ペネトレーションテストは、動ツール（SAST/DAST）では検知が難しい「ビジネスロジックの隙を突いた攻撃（例：他人の注文IDに書き換えてデータを盗むなど）」を、専門のエンジニアが手動で検証するテストです。重要なデータを扱うAPIでは、ツールテストに加えて手動テストの実施が推奨されます。
APIのセキュリティは、リリース前のテストで完結するものではありません。
運用段階ではAPIトラフィックの継続的なモニタリングに加え、APIインベントリの管理が重要です。古いバージョンのAPIやドキュメント化されていないエンドポイントが放置されていると、それが攻撃の入口になります。運用中のAPIを定期的に棚卸しし、不要なエンドポイントを廃止する仕組みを整えておきましょう。
「Webアプリケーション脆弱性診断を実施しているから、APIもカバーできているのでは？」と考える方もいるかもしれません。しかし、Webアプリ診断とAPI脆弱性診断では検査の対象や観点が異なり、片方だけでは十分とはいえないのが実情です。
Webアプリケーション診断は、主にブラウザからアクセスするユーザーインターフェースを介して検証を行います。これに対してAPI脆弱性診断では、画面という情報がなく、エンドポイントに対するリクエストとレスポンスの構造が直接的な検査対象になります。API診断に特有の観点は次のとおりです。
| 診断観点 | 検証内容 |
|---|---|
| オブジェクトレベルの認可検証（BOLA対策） | リクエスト内のIDを変更した際に、サーバー側でアクセス権限を正しく検証しているか |
| レスポンスデータの過剰公開 | 画面で非表示にしている項目がAPIレスポンス上に含まれていないか |
| ビジネスロジックの検証 | APIの処理順序やパラメータの組み合わせを操作した場合に、意図しない動作が発生しないか |
| API仕様との整合性 | OpenAPIなどで定義した仕様どおりにAPIが動作しているか。仕様外の不正なリクエストを送った際に、安全にエラー処理されるか。 |
Webアプリ診断のスコープにAPIのエンドポイントが含まれていたとしても、上記のようなAPI固有の検証項目は通常のWebアプリ診断では十分にカバーされません。
API脆弱性診断を実施することで、実際にどのような問題が見つかるのでしょうか。よくある検出事例を紹介します。
| 検出事例 | 内容 |
|---|---|
| 他ユーザーの情報取得・改ざん | リクエストのURLやJSON内のIDパラメータを他人のものに変更するだけで、本来アクセスできない個人情報が返却されたり、勝手に書き換えられたりした。 |
| 管理者用APIへの不正アクセス | 一般ユーザーのトークンで管理者向けエンドポイントが実行できた |
| エラーレスポンスからの情報漏えい | 意図的に不正なデータを送信してエラー（500 Internal Server Error）を起こした際、レスポンスにプログラムのスタックトレースや内部のDB構造、SQL文が含まれていた。 |
| レート制限の未設定による悪用 | ログインAPIやOTP（ワンタイムパスワード）検証APIに対して、短時間に数万回の総当たり攻撃（ブルートフォース）を仕掛けても、制限なくすべて処理されてしまった。 |
これらはいずれも、Webアプリの画面からの操作では気づきにくい問題です。API脆弱性診断を独立して実施する意義がここにあります。
APIのセキュリティリスクを把握し、対策の必要性を理解したら、次は実際の脆弱性診断をどう進めるかという実務的な判断です。ポイントは、診断手法の選定と実施タイミングの見極め。この2つを押さえておきましょう。
API脆弱性診断の手法は、大きく「ツール診断」「手動診断」「ハイブリッド診断」の3つに分かれます。それぞれの特徴を表で整理しました。
| 診断手法 | 特徴 | コスト | 得意領域 | 課題 |
|---|---|---|---|---|
| ツール診断 | 自動化ツールでAPIの脆弱性を検出 | 低コスト | 既知の脆弱性パターンの網羅的なスキャン、短時間での広範囲チェック | ビジネスロジックの不備やAPI固有の認可設計ミスは検出が難しい |
| 手動診断 | セキュリティ専門家が手作業で検証 | 高コスト | BOLA・認可ロジックの検証、ビジネスフローの悪用リスク、複合的な攻撃シナリオ | 時間・コストがかかり、エンドポイントの網羅的な検証は難しい |
| ハイブリッド診断 | ツール診断と手動診断を組み合わせ | 中～高コスト | ツールで一次スクリーニングを行い、専門家がビジネスロジックを重点的に検証 | 診断計画の設計が必要、両方のリソースを確保する必要がある |
OWASP API Security Top 10で上位に挙がるBOLAやBroken Authenticationは、リクエストの形式自体は正常であるため、自動スキャンだけでは見落とされやすい傾向があります。そのため、ツール診断で広く一次チェックを行い、認可ロジックやビジネスフローに関わる部分は専門家が手動で検証するハイブリッド型のアプローチが、費用対効果の面でもバランスが取りやすい選択肢です。
API脆弱性診断は「問題が起きてから」ではなく、リスクが変化する節目で実施するのが効果的です。とくに検討すべきタイミングは以下の4つです。
| タイミング | 確認すべきポイント |
|---|---|
| 新規APIのリリース前 | 設計意図どおりの動作をしているか、認可チェックの抜け漏れがないかを検証する |
| 既存APIの仕様変更・改修時 | パラメータ追加やレスポンス項目の変更による認可判定漏れやデータ過剰公開を確認する |
| ISMS・SOC2などの監査対応前 | 診断結果を是正記録の根拠資料として活用し、セキュリティ統制の実効性を説明する |
| インシデント発生後の再点検 | 同種の脆弱性が他のAPIに残っていないか横断的に確認する |
いずれのタイミングでも共通して重要なのは、API仕様書やサンプルリクエスト・レスポンスを事前に整備しておくこと。画面がないAPIの診断では、こうした資料が診断の精度と効率を大きく左右します。API脆弱性診断をスムーズに進めるための事前準備については、以下の記事で詳しく解説しています。
APIはWebアプリケーションとは異なるリスク特性を持ち、認証・認可の不備やデータの過剰公開といったAPI固有の脆弱性が、情報漏えいや不正アクセスの原因になり得ます。APIを安全に運用するためには、OWASP API Security Top 10を指標としてリスクを把握し、設計段階からセキュリティ要件を組み込んだうえで、API固有の脆弱性診断を実施することが不可欠です。
自社のAPIのセキュリティ状況に不安がある方は、まず運用中のAPIのインベントリを整理し、リスクの高いエンドポイントから優先的に診断を進めてみてください。
「何から始めればいいかわからない」「自社のAPIにどんなリスクがあるのか把握できていない」という方は、ユービーセキュアにご相談ください。脆弱性検査ツール「Vex」の開発元であり、ツール診断だけでなくセキュリティコンサルタントによる手動診断にも対応しています。お客様の状況に合わせた最適な診断プランをご提案しますので、まずはお気軽に無料相談をご活用ください。