自社のシステムにAPI連携が増えてきたものの、「Webアプリの脆弱性診断は実施しているが、APIのセキュリティは十分なのか」と判断しかねている方は多いのではないでしょうか。APIはWebアプリとは異なるリスク特性を持ち、従来の診断だけではカバーしきれない脅威が存在します。
この記事では、APIが狙われる背景からOWASP API Security Top 10の要点、設計・開発・運用の各フェーズで取るべき対策、そしてAPIセキュリティテストの選び方までを整理しています。API脆弱性診断の進め方でお悩みの場合は、ユービーセキュアの無料相談も活用いただけます。
APIセキュリティが注目されている理由
API活用の広がりとアタックサーフェスの変化
企業システムではSaaS連携、モバイルアプリのバックエンド、マイクロサービス間通信など、あらゆる場面でAPIが使われるようになりました。1つのサービスが数十〜数百のエンドポイントを持つことも珍しくありません。
エンドポイントが増えるほど、攻撃者にとっての入口も増えます。とくに問題になりやすいのは、テスト用APIや旧バージョンのエンドポイントが公開されたまま残っているケースです。こうした"管理されていないAPI"は認証が甘い、あるいはそもそも認証がかかっていないことがあり、格好の標的になります。
Webアプリケーションであれば、公開画面からアクセスできる範囲がある程度限定されます。一方、APIは仕様さえわかれば外部から直接リクエストを投げられるため、公開範囲の管理が甘いとアタックサーフェスが想定以上に広がるのです。
API特有の攻撃パターンとは
Webアプリケーションへの攻撃がSQLインジェクションやXSSなど入力値の処理不備を突くのに対し、API攻撃の多くは認証・認可のロジックそのものを狙います。たとえば、ユーザーIDを差し替えてリクエストを送るだけで他人のデータが取得できてしまうケースがあります。これはOWASP API Security Top 10で1位に挙げられているBOLA（Broken Object Level Authorization）の典型例です。
もう1つの特徴は、攻撃の"見えにくさ"です。正規のリクエスト形式を使いながらパラメータだけを細工し、検出を逃れるために低頻度・低速でリクエストを送る「ロー＆スロー」型の攻撃は、WAFやログ監視でも検知が難しく、長期間気づかれずに被害が拡大するリスクをはらんでいます。
知っておきたいAPIのセキュリティリスク
OWASPが公開している「API Security Top 10（2023年版）」は、APIセキュリティのリスクを体系的に整理した指標です。とくに押さえておくべきリスクを以下の3つの領域に分けて解説します。
- 認証・認可まわりのリスク
- データの公開範囲とリソース制限の課題
- その他のリスク（インジェクション・セキュリティ設定ミスなど）
認証・認可まわりのリスク（BOLA・Broken Authentication）
API1:2023 BOLAは、リクエスト内のオブジェクトID（ユーザーID、注文番号など）を差し替えるだけで他人のデータにアクセスできてしまう脆弱性です。API2:2023 Broken Authenticationは、JWTトークンの有効期限未検証やAPIキーの使い回しなど、認証実装全般の不備を指します。
これら2つに共通するのは「ビジネスロジック層の問題」である点です。WAFのパターンマッチングでは検知できず、APIの仕様と実装を理解したうえでの検査が欠かせません。
データの公開範囲とリソース制限の課題
API3:2023 Broken Object Property Level Authorizationは、APIレスポンスに本来不要なプロパティ（内部ID、管理者フラグなど）が含まれていたり、書き換え禁止のプロパティを上書きできてしまったりする問題です。Webアプリでは画面側でデータを制御できますが、APIレスポンスのJSONには生データがそのまま載っていることがあり、攻撃者がレスポンスを直接確認すれば情報は筒抜けになります。
API4:2023 Unrestricted Resource Consumptionは、レート制限の欠如です。リクエスト回数に上限がないAPIはDoS攻撃やスクレイピングの標的になりやすくなります。
その他のリスク（インジェクション・セキュリティ設定ミスなど）
2023年版ではインジェクションが独立カテゴリから外れ、API8:2023 Security Misconfigurationの一部に位置づけられました。不要なHTTPメソッドの許可やCORSの過剰許可、デバッグモードの本番残存などが該当します。ほかにも、一般ユーザーが管理者向けエンドポイントを呼べてしまうAPI5:2023 Broken Function Level Authorization（BFLA）や、旧バージョンAPIの放置を指摘するAPI9:2023 Improper Inventory Managementは実務で見落としやすいリスクです。
※参考：OWASP｜API Security Top 10 – 2023
APIセキュリティ対策の進め方
対策を開発ライフサイクルの1か所に集中させるのではなく、設計・開発・テスト・運用の3フェーズに分散させることで、見落としを減らしコストも抑えられます。
設計フェーズでのセキュリティ要件
もっとも影響が大きいのは認証・認可方式の選定です。
外部公開APIではOAuth 2.0＋JWTの組み合わせが広く採用されていますが、用途によってはAPIキー認証で十分なケースもあります。重要なのは「誰が、どのリソースに、どの操作を許可されるか」を仕様段階で明示することです。曖昧なまま実装に入ると、BOLAやBFLAが生まれやすくなります。
このほか、設計フェーズで決めておくべき項目には以下があります。
- 最小権限の原則：レスポンスに含めるデータ項目を必要最小限に絞る
- レート制限：エンドポイントごとのリクエスト上限を設定する
- ペイロードサイズ上限：1リクエストあたりの送信データサイズに制限をかける
いずれも運用後の後付けは影響が大きいため、設計時に決めておくのが理想です。
開発・テストフェーズでのセキュリティテスト手法
設計で定めた要件が正しく実装されているかを確認するのが、APIセキュリティテストの役割です。主な手法は以下の3つです。
DAST（動的アプリケーションセキュリティテスト）
実行中のAPIに外部からリクエストを送信し、レスポンスから脆弱性を検出します。攻撃者と同じ視点でテストするため、認証バイパスや認可不備など実際に悪用されうるリスクを発見しやすい手法です。OpenAPI仕様書を読み込んで自動クロールする機能を持つツールが多く、ソースコード不要で外部APIの検査にも使えます。
SAST（静的解析セキュリティテスト）
ソースコードを直接解析し、ハードコーディングされた認証情報やバリデーション漏れなどをコードレベルで検出します。実行環境が不要なため開発の早い段階から導入でき、プルリクエスト時の自動スキャンとの相性が良い手法です。ただし、実行時の認可ロジック不備（BOLAなど）は検出しにくいため、DASTとの併用が推奨されます。
ファズテスト
APIの各パラメータに対して異常な入力を大量に送り込み、予期しないエラーやクラッシュを引き起こすテストです。DAST・SASTでは見つかりにくいエッジケースの発見に強みがありますが、実行に時間がかかるため、認証・決済など重要度の高い処理に対象を絞って実施するのが効率的です。
運用フェーズでのモニタリングと保護
APIゲートウェイによるレート制限・認証の一元管理、ログの可視化と異常検知（大量アクセスや認証失敗の急増へのアラート設定）が運用フェーズの柱です。新しいエンドポイントの追加やパラメータ変更に合わせてセキュリティポリシーを更新する変更管理ルールも定めておかないと、いつの間にか"管理されていないAPI"が生まれてしまいます。
Webアプリ診断とAPI脆弱性診断はどう違う？
「Webアプリケーション脆弱性診断を実施しているのだから、APIも対象に含まれているのでは？」と考える方は少なくありません。しかし、Webアプリ診断とAPI脆弱性診断は検査のアプローチが根本的に異なり、片方だけでは十分なカバレッジを確保できません。
検査のアプローチはどこが異なるか
Webアプリ診断は画面操作に沿ってフォーム入力やセッション管理を検査しますが、API脆弱性診断では画面が存在しないため、API仕様書やリクエストログをもとにパラメータ単位で検査します。認可テストも、画面遷移ベースではなくオブジェクトID差し替えやロール別アクセス制御の検証が中心です。レスポンスJSONの全プロパティ検査やOpenAPI定義との差異チェックなど、Webアプリ診断にはない観点が多く含まれます。
API脆弱性診断で見つかるリスクの例
API脆弱性診断では、BOLA（他ユーザーIDでのデータ取得可否）、レスポンスへの不要プロパティ混入、レート制限の欠如、認証バイパスなど、画面操作だけでは再現しにくいリスクを検出します。「Webアプリ診断は合格したが、API経由では情報が漏えいしていた」というケースは実際の診断現場でも珍しくありません。
API脆弱性診断の始め方と手法の選び方
ツール診断・手動診断・ハイブリッド診断の比較
ツール診断は自動スキャンで既知パターンを網羅的に検査でき、CI/CDへの組み込みに適しています。手動診断は専門家がAPI仕様を読み解き、BOLA/BFLAなどロジック系リスクまで深掘りできます。ハイブリッド診断はツールで広くスキャンしたうえで重要箇所を手動で検証する方式で、コストと精度のバランスが取りやすい選択肢です。
自社でどの手法が適切か判断しづらい場合は、ユービーセキュアの無料相談で診断方針からお気軽にご相談ください。
診断はいつ実施するのがよいか
優先度が高いのは、新規APIのリリース前、大規模な仕様変更時、そして年1回以上の定期診断です。リリース後に脆弱性が見つかった場合の修正コストと影響範囲を考えると、リリース前のタイミングがもっとも費用対効果が高くなります。PCI DSSなど監査要件への対応やインシデント発生後の緊急診断も重要なタイミングです。CI/CDにツール診断を組み込みつつ、年に1回は手動またはハイブリッド診断で深掘りする運用が、コストと網羅性のバランスを取りやすいパターンです。
まとめ
APIはWebアプリケーションとは異なるリスク特性を持ち、とくに認証・認可のロジック不備はWAFやWebアプリ診断だけではカバーしきれません。設計段階での認証・認可方針の策定、開発段階でのDAST・SAST・ファズテストの活用、運用段階での継続的なモニタリングを組み合わせることで、リスクの見落としを減らせます。
「自社のAPIにどの診断手法が適しているか」「どこから優先的に対策すべきか」と迷った場合は、ユービーセキュアの無料相談をご活用ください。API脆弱性診断の進め方や診断範囲について、専門家に直接相談できます。
APIの活用が広がるほど、セキュリティの死角も広がります。まずは自社のAPIがどのようなリスクにさらされているかを把握し、優先度の高い箇所から対策を進めていくことが、被害を未然に防ぐ第一歩です。
