APIセキュリティ診断の12のチェックポイント｜REST API保護の必須項目

近年、API経由のセキュリティインシデントが急増しています。Gartner社の調査によると、2023年時点でWebアプリケーション攻撃の83%がAPIを標的としており、2019年の約2倍に増加しました。REST APIは多くのWebサービスやモバイルアプリで活用されていますが、適切なセキュリティ診断を行わないと、深刻な情報漏洩やサービス停止のリスクを抱えることになります。この記事では、実務ですぐに使えるAPIセキュリティ診断の12のチェックポイントを、基礎編と応用編に分けて具体的に解説します。

APIセキュリティ診断が必要な理由

API経由の攻撃が増加している背景

API経由の攻撃が急増している背景には、マイクロサービスアーキテクチャの普及とモバイルアプリの増加があります。従来のモノリシックなWebアプリケーションと異なり、現代のシステムでは複数のAPIが連携してサービスを提供するため、攻撃対象となるエンドポイントが飛躍的に増加しています。

Salt Security社の2024年版レポートでは、API攻撃が前年比で約400%増加したことが報告されています。特に注目すべき点は以下の3つです：

• 認証の脆弱性を狙った攻撃：不適切なトークン管理や認証バイパスを狙う攻撃が全体の42%を占める
• データスクレイピング：正規のAPIエンドポイントを大量に呼び出して個人情報を収集する攻撃が増加
• ビジネスロジックの悪用：API仕様の理解に基づく高度な攻撃が従来型の自動化攻撃を上回る

これらの攻撃は、従来のWebアプリケーションファイアウォール（WAF）だけでは防ぎきれないため、API特化型のセキュリティ診断が必要となっています。

REST APIに潜む代表的な脆弱性

OWASP（Open Web Application Security Project）が公開している「OWASP API Security Top 10」は、API特有のセキュリティリスクをまとめた権威ある資料です。2023年版では以下の脆弱性が上位にランクインしています：

これらの脆弱性は、従来のWebアプリケーションにも存在する課題ですが、APIではより深刻な影響をもたらします。APIは機械的にアクセスされるため、攻撃者が短時間で大量のリクエストを送り、被害が拡大しやすいという特徴があります。

API診断を怠った場合のリスク

APIセキュリティ診断を怠ると、企業にとって以下のような深刻なリスクが生じます：

情報漏洩による社会的信用の失墜

2023年に発生したある大手ECサイトの事例では、APIの認可不備により約500万人分の顧客情報が流出しました。この事例では、本来は自分の購入履歴のみを参照できるAPIエンドポイントで、IDパラメータを変更するだけで他の顧客の情報にアクセスできる状態になっていました。結果として、企業は約30億円の損害賠償と顧客離れという大きな代償を払うことになりました。

サービス停止による事業機会の損失

レート制限が設定されていないAPIは、DDoS攻撃の標的になりやすく、サービス全体が停止するリスクがあります。ある金融サービス企業では、APIへの大量アクセスによってサーバーが過負荷状態となり、約6時間のサービス停止が発生しました。この間の機会損失は約2億円と推定されています。

不正利用による経済的損害

API仕様が適切に保護されていない場合、ビジネスロジックの悪用による不正な取引が発生することがあります。実際に、あるポイントサービスでは、ポイント付与APIの仕様を解析され、本来の10倍のポイントを不正に取得される事件が発生しました。

APIセキュリティ診断の12のチェックポイント【基礎編】

①認証・認可の実装確認

APIセキュリティの最重要項目は、適切な認証（Authentication）と認可（Authorization）の実装です。認証は「誰がアクセスしているか」を確認し、認可は「そのユーザーが何をできるか」を制御します。

OAuth 2.0の適切な実装

REST APIでは、OAuth 2.0が広く採用されています。診断時には以下を確認してください：

• 認証フロー（Authorization Code、Client Credentials等）が用途に適しているか
• アクセストークンの有効期限が適切に設定されているか（推奨：60分以内）
• リフレッシュトークンが安全に管理されているか
• スコープ（権限範囲）が必要最小限に設定されているか

JWTの検証漏れ防止

JSON Web Token（JWT）を使用する場合、以下の検証が必須です：

• 署名の検証（alg: noneを許可していないか）
• 発行者（iss）と有効期限（exp）の確認
• トークンの改ざん検知（HMACまたはRSA署名の検証）

実際の診断では、無効なトークンや期限切れトークンでアクセスできないか、他ユーザーのトークンを使い回せないかを確認します。

②HTTPSの適切な使用

APIの通信は必ずHTTPS（TLS/SSL）で暗号化する必要があります。診断では以下の項目を確認してください：

TLSバージョンと暗号スイート

• TLS 1.2以上を使用しているか（TLS 1.0/1.1は脆弱性が指摘されており非推奨）
• 強力な暗号スイートが優先されているか（AES-GCM等）
• RC4やDESなどの弱い暗号が無効化されているか

証明書の妥当性

• 証明書が信頼できる認証局から発行されているか
• 証明書の有効期限が切れていないか
• サブジェクト代替名（SAN）が正しく設定されているか

HTTP→HTTPSリダイレクト

HTTPでアクセスされた場合、自動的にHTTPSにリダイレクトされるか確認してください。また、HSTS（HTTP Strict Transport Security）ヘッダーを設定し、ブラウザに常にHTTPS接続を強制させることも重要です。

③入力値検証とサニタイズ

APIへの入力値は、常に悪意のあるデータが含まれる可能性を想定して検証する必要があります。OWASP Top 10でも常に上位にランクインするインジェクション攻撃を防ぐため、以下を実施してください：

SQLインジェクション対策

• すべてのSQL文でプレースホルダ（パラメータ化クエリ）を使用
• 動的にSQL文を組み立てる場合は、入力値を厳格にエスケープ
• データベース接続ユーザーの権限を最小限に設定

NoSQLインジェクション対策

MongoDBなどのNoSQLデータベースを使用する場合も、JSON形式での攻撃に注意が必要です。特に、$whereや$regex演算子を使用する際は、入力値のバリデーションを徹底してください。

型・形式・範囲の検証

APIパラメータには、以下のような多層的な検証を実装します：

• データ型の検証（数値型、文字列型、真偽値型など）
• 文字列長の制限（最小・最大文字数）
• 許可する文字種の制限（英数字のみ、特殊文字の除外など）
• 数値の範囲チェック（負数の禁止、上限値の設定など）
• 正規表現によるフォーマット検証（メールアドレス、電話番号など）

④レート制限の設定

APIへの過度なリクエストを防ぐため、レート制限（Rate Limiting）は必須の対策です。これにより、DDoS攻撃やブルートフォース攻撃のリスクを大幅に低減できます。

適切なレート制限値の設定

レート制限は、APIの用途に応じて設定してください：

• 認証API：1IPあたり分間10リクエスト（ブルートフォース攻撃対策）
• データ参照API：1ユーザーあたり分間100リクエスト
• データ更新API：1ユーザーあたり分間30リクエスト
• 重要な操作（決済等）：1ユーザーあたり分間5リクエスト

429 Too Many Requestsの適切な返却

レート制限を超えた場合、HTTPステータスコード429を返し、Retry-Afterヘッダーでリトライ可能時刻を通知してください。また、レスポンスボディには制限内容を明記することで、正規ユーザーの混乱を防げます。

段階的な制限強化

初回の制限超過では警告のみ、繰り返す場合は一時的なアクセス制限、悪質な場合はIPブロックといった段階的な対応を検討してください。

⑤適切なHTTPメソッド使用

REST APIでは、HTTPメソッド（GET、POST、PUT、DELETE等）を適切に使い分けることが、セキュリティと可読性の向上につながります。

各メソッドの役割と制約

GETメソッドでの機密情報送信の禁止

パスワードやトークンなどの機密情報をGETリクエストのURLパラメータで送信すると、サーバーログやブラウザ履歴に平文で記録される危険があります。機密情報は必ずPOSTメソッドのリクエストボディで送信してください。

不要なメソッドの無効化

TRACEやOPTIONSなど、本番環境で不要なHTTPメソッドは無効化し、攻撃対象を減らすことが推奨されます。

⑥エラーメッセージの情報漏洩防止

APIのエラーレスポンスから、システム構成やデータベース構造などの機密情報が漏洩するケースが多く見られます。診断では以下を確認してください：

スタックトレースの非表示化

本番環境では、詳細なスタックトレースやデバッグ情報を返してはいけません。以下のような情報が含まれていないか確認してください：

• データベースのテーブル名やカラム名
• ファイルパスやディレクトリ構造
• 使用しているフレームワークやライブラリのバージョン
• SQL文の内容

適切なエラーメッセージ設計

エラーは一般的なメッセージに統一し、詳細はログファイルに記録します：

• 良い例：「入力内容に誤りがあります。再度ご確認ください。」
• 悪い例：「emailカラムにユニーク制約違反が発生しました。値'test@example.com'は既に存在します。」

攻撃者への情報提供回避

認証失敗時に「ユーザーIDが存在しません」「パスワードが間違っています」と個別のメッセージを返すと、有効なユーザーIDを特定される恐れがあります。「ユーザーIDまたはパスワードが正しくありません」という統一メッセージを使用してください。

APIセキュリティ診断の12のチェックポイント【応用編】

⑦CORSポリシーの設定確認

CORS（Cross-Origin Resource Sharing）は、異なるオリジン（ドメイン）からのAPIアクセスを制御する仕組みです。設定不備があると、悪意のあるWebサイトから不正なAPI呼び出しが可能になります。

Access-Control-Allow-Originの適切な設定

最も重要なのは、許可するオリジンを明確に指定することです：

• 推奨：特定のドメインのみ許可（例：Access-Control-Allow-Origin: https://example.com）
• 非推奨：ワイルドカード（*）の使用（すべてのドメインからのアクセスを許可してしまう）

複数のドメインを許可する必要がある場合は、サーバー側でリクエストのOriginヘッダーをチェックし、ホワイトリストに含まれる場合のみ該当ドメインを返却してください。

認証情報を含むリクエストの制御

Access-Control-Allow-Credentials: trueを設定する場合は、Access-Control-Allow-Originでワイルドカードを使用できません。Cookie等の認証情報を含むAPIでは、必ず特定のオリジンを指定してください。

プリフライトリクエストへの対応

カスタムヘッダーやPUT/DELETEメソッドを使用する場合、ブラウザはプリフライトリクエスト（OPTIONSメソッド）を送信します。これに適切に応答し、Access-Control-Allow-MethodsやAccess-Control-Allow-Headersで許可する項目を明示してください。

⑧APIキーの安全な管理

APIキーは、サービス間の認証に使用される重要な情報ですが、適切に管理されていないケースが多く見られます。診断では以下を確認してください：

コードへのハードコード禁止

ソースコードに直接APIキーを記述すると、GitHubなどのリポジトリ経由で漏洩するリスクがあります。実際に、GitHub上で公開されたAPIキーをボットが自動検出し、数分以内に悪用される事例が多数報告されています。

APIキーは環境変数や専用のシークレット管理サービス（AWS Secrets Manager、Azure Key Vault等）で管理してください。

APIキーの種類と用途の分離

• 本番環境用キー：厳格に管理、定期的なローテーション
• 開発環境用キー：本番環境とは別のキーを使用、アクセス範囲を制限
• テスト用キー：一時的な使用に限定、テスト終了後は無効化

APIキーの定期的なローテーション

APIキーは最低でも90日ごとにローテーション（更新）することが推奨されます。自動ローテーション機能を実装し、古いキーの猶予期間を設けることで、サービス停止を避けながら安全性を高められます。

キー漏洩時の迅速な対応

APIキーの漏洩が判明した場合、即座に無効化できる仕組みを用意してください。また、過去のアクセスログを確認し、不正利用の有無をチェックします。

⑨ログ記録と監視体制

APIへの攻撃を早期に検知し、事後調査を可能にするため、適切なログ記録と監視が不可欠です。

記録すべきログ項目

• アクセス元IPアドレス
• リクエスト日時（タイムスタンプ）
• HTTPメソッドとエンドポイント
• 認証情報（ユーザーID、APIキー等。ただしパスワードは記録禁止）
• レスポンスステータスコード
• 処理時間
• エラー内容（詳細はアプリケーションログに記録）

異常検知のための監視設定

以下のような異常パターンをリアルタイムで検知し、アラートを発する仕組みを構築してください：

• 短時間での大量リクエスト（DDoS攻撃の兆候）
• 認証失敗の連続（ブルートフォース攻撃の兆候）
• 404エラーの大量発生（エンドポイント探索の兆候）
• 通常とは異なる時間帯のアクセス
• 海外IPからの不審なアクセス（サービスが国内限定の場合）

ログの保管期間と保護

ログは最低6ヶ月、重要なサービスでは1年以上保管することが推奨されます。また、ログ自体への不正アクセスや改ざんを防ぐため、書き込み専用の権限設定や暗号化を実施してください。

⑩バージョン管理とセキュリティパッチ

APIのライフサイクル管理は、セキュリティ維持に直結します。古いバージョンのAPIを放置すると、既知の脆弱性を狙われるリスクが高まります。

APIバージョニング戦略

APIのバージョン管理には以下の方法があります：

• URLパスでのバージョン指定：https://api.example.com/v1/users
• ヘッダーでのバージョン指定：Accept: application/vnd.example.v1+json
• クエリパラメータでのバージョン指定：https://api.example.com/users?version=1

一般的には、URLパスでの指定が最もわかりやすく、広く採用されています。

旧バージョンの段階的な廃止

新バージョンリリース後も、旧バージョンを即座に廃止せず、以下のような段階的な移行期間を設けます：

1. 新バージョンのリリースと並行運用開始
2. 旧バージョンの非推奨化（Deprecated）の告知
3. 十分な移行期間（通常6ヶ月〜1年）の提供
4. 旧バージョンへのアクセスに警告レスポンスを追加
5. 旧バージョンの完全廃止

セキュリティパッチの迅速な適用

使用しているフレームワークやライブラリに脆弱性が発見された場合、可能な限り24時間以内にパッチを適用してください。脆弱性情報の公開から数時間で攻撃が開始される事例もあるため、迅速な対応が重要です。

⑪機密データの暗号化

APIで扱うデータは、通信時と保存時の両方で適切に保護する必要があります。

通信時の暗号化（TLS/SSL）

すでに②で解説したHTTPSに加え、以下も実施してください：

• 証明書のピンニング（モバイルアプリ等で中間者攻撃を防ぐ）
• Perfect Forward Secrecy（PFS）対応の暗号スイート使用
• TLS 1.3への移行検討（より高速で安全）

保存時の暗号化

データベースに保存する機密情報は、以下のように暗号化してください：

• パスワード：bcryptやArgon2などの適切なハッシュ関数で不可逆的に変換
• 個人情報：AES-256等の強力な暗号化アルゴリズムで暗号化
• 暗号鍵：専用の鍵管理サービスで保護（AWS KMS、Azure Key Vault等）

機密情報のマスキング

ログや管理画面に機密情報を表示する際は、部分的なマスキングを実施します：

• クレジットカード番号：**** **** **** 1234
• メールアドレス：t***@example.com
• 電話番号：090-****-5678

⑫API仕様の公開範囲制限

OpenAPI（Swagger）などのAPI仕様書は、開発効率を高める一方で、攻撃者にとっても有益な情報源となります。適切な公開範囲の制限が必要です。

内部向けと外部向けの仕様書分離

• 外部公開用：パブリックAPIのみ記載、詳細な実装情報は除外
• 内部開発用：すべてのエンドポイント、認証方法、エラー詳細を記載

仕様書へのアクセス制御

Swagger UIなどのドキュメント生成ツールは、本番環境では以下のように保護してください：

• Basic認証やIP制限で社内からのみアクセス可能にする
• 本番環境ではSwagger UIを完全に無効化し、別途静的なドキュメントを提供
• 開発環境と本番環境で異なる設定を使用

機密情報の除外

API仕様書には以下の情報を含めないでください：

• 実際のAPIキーやトークンのサンプル
• 内部システムのホスト名やIPアドレス
• データベーススキーマの詳細
• 未公開の機能やエンドポイント

APIセキュリティ診断の進め方と外部委託のポイント

自社でできる基本診断の手順

専門業者に依頼する前に、自社で実施できる基本的な診断手順を紹介します。これにより、明らかな問題を事前に解決し、外部診断の効果を高められます。

ステップ1：診断対象APIのリストアップ

まず、自社で運用しているすべてのAPIエンドポイントを洗い出します。特に、統合や買収で引き継いだシステムや、担当者が異動したプロジェクトで、管理されていないAPIが残っている可能性があります。

ステップ2：自動診断ツールの活用

以下のようなツールで基本的な脆弱性をスキャンできます：

• OWASP ZAP：無料のWebアプリケーション脆弱性診断ツール
• Postman：APIテスト機能で基本的なセキュリティチェック
• Burp Suite Community Edition：通信の傍受と改ざんテスト

これらのツールを使用し、SQLインジェクション、XSS、CSRF等の一般的な脆弱性を検出します。

ステップ3：チェックリストによる手動確認

本記事で紹介した12のチェックポイントをリスト化し、各APIについて確認します。特に以下は手動確認が効果的です：

• 認証トークンの有効期限切れ時の挙動
• 他ユーザーのIDを指定した場合のアクセス制御
• レート制限の動作確認
• エラーメッセージの内容確認

ステップ4：結果の記録と優先順位付け

発見した問題を重要度別に分類します：

• 緊急（Critical）：情報漏洩やサービス停止に直結、即座に対応
• 高（High）：攻撃成功の可能性が高い、1週間以内に対応
• 中（Medium）：条件次第で攻撃可能、1ヶ月以内に対応
• 低（Low）：理論的リスクのみ、次回改修時に対応

専門業者に依頼すべき診断項目

自社診断で検出できない高度な攻撃手法や、ビジネスロジックの脆弱性は、専門業者によるペネトレーションテスト（侵入テスト）が必要です。

専門業者が実施する高度な診断内容

• OWASP API Top 10に基づく網羅的なテスト
• 実際の攻撃シナリオを想定した侵入テスト
• レースコンディション等のタイミング依存の脆弱性検証
• ビジネスロジックの悪用可能性の検証（価格改ざん、権限昇格等）
• APIキーやトークンの安全性検証
• サードパーティ連携部分のセキュリティ評価

業者選定のポイント

APIセキュリティ診断を依頼する際は、以下を確認してください：

• OWASP API Security Top 10に準拠した診断項目があるか
• REST API特有の診断実績があるか
• 診断後の改善支援（修正方法の助言）が含まれるか
• 再診断が無償または低価格で実施できるか
• 秘密保持契約（NDA）の締結が可能か

診断報告書で確認すべき内容

診断後に受け取る報告書には、以下が含まれているべきです：

• 発見された脆弱性の詳細（再現手順、影響範囲）
• CVSS等の標準的な評価基準による重要度分類
• 具体的な修正方法の提案
• 経営層向けのサマリー（リスク評価、対応優先度）

診断後の改善サイクル

APIセキュリティ診断は一度実施すれば終わりではなく、継続的な改善サイクルとして運用することが重要です。

定期診断のスケジュール設定

以下のタイミングで診断を実施してください：

• 新規API公開前：必須の事前診断
• 大規模な機能追加・変更後：影響範囲の診断
• 定期診断：最低年1回、重要なAPIは四半期ごと
• インシデント発生後：原因調査と再発防止の確認

脆弱性対応のワークフロー確立

診断で発見された問題への対応フローを明確にします：

1. 脆弱性の確認と再現テスト
2. 影響範囲の特定と暫定対策の実施
3. 恒久対策の設計・実装
4. 再診断による修正確認
5. 類似箇所の横展開チェック

セキュリティ教育の実施

開発チーム全体のセキュリティ意識を高めるため、以下のような教育を定期的に実施します：

• OWASP API Security Top 10の勉強会
• 過去の脆弱性事例の共有
• セキュアコーディング研修
• 診断結果のレビュー会議

ツールとプロセスの継続的改善

診断で使用するツールや手法も、最新の脅威に対応できるよう定期的に見直してください。新しい攻撃手法が発見された場合、それに対応した診断項目を追加します。

まとめ

この記事では、APIセキュリティ診断の12のチェックポイントを、基礎編と応用編に分けて解説しました。重要なポイントは以下の3つです：

• 認証・認可の徹底：OAuth 2.0やJWTの適切な実装により、不正アクセスのリスクを大幅に低減できます
• 入力値検証とレート制限：インジェクション攻撃やDDoS攻撃など、多くの攻撃手法を防ぐ基本対策です
• 継続的な診断と改善：一度の診断で終わらせず、定期的な見直しと最新脅威への対応が不可欠です

APIセキュリティは、開発段階から本番運用、そして継続的な改善まで、すべてのフェーズで意識すべき課題です。まずは利用中のAPIをリストアップし、本記事のチェックリストで現状を確認することから始めてみてください。自社での基本診断と専門業者による高度な診断を組み合わせることで、APIのセキュリティレベルを効果的に向上させることができます。