APIセキュリティとは？REST APIを狙う攻撃手法と防御策を現場目線で解説

「うちのAPIはHTTPS化しているから大丈夫」と思っていませんか。実際には認証の抜け穴・過剰なデータ返却・レート制限の欠如など、HTTPSだけでは防げない脆弱性が多数存在します。

スマートフォンアプリ、クラウドサービス、社内の業務システム。あらゆるシステムの裏側でREST APIが動いています。Webフロントエンドへの攻撃が難しくなった今、APIエンドポイントは攻撃者にとって格好の侵入口になっています。

この記事では、REST APIを狙う攻撃者の視点と、現場で今すぐ実践できる防御策を解説します。大企業向けの話だけではありません。中小企業の情シスが自社のAPIを守るための実用的な内容です。

APIセキュリティとは？

API（Application Programming Interface）とは、異なるソフトウェア同士がデータをやり取りするための仕組みです。現代のWebサービスでは、フロントエンドとバックエンドの通信、スマートフォンアプリとサーバーの通信、外部サービスとの連携など、あらゆる場面でAPIが使われています。

REST APIはその中でも最も広く採用されている設計方式です。HTTPプロトコルを使い、GETやPOSTなどのメソッドでリソースを操作します。シンプルで汎用性が高い反面、実装によっては深刻なセキュリティホールが生まれます。

APIセキュリティとは、APIエンドポイントを攻撃から保護するための考え方と対策の総称です。Webアプリケーションのセキュリティと重複する部分もありますが、APIには特有の脆弱性パターンが存在します。

なぜ今、APIセキュリティが重要かは明確です。APIはフロントエンドの外観（UI）を持たないため、ブラウザ越しの攻撃を防ぐ仕組みが効きにくい場合があります。また、APIのエンドポイントは一度設計すると長期間使われ続けるため、脆弱性を放置したまま運用されるケースが少なくありません。

攻撃者はREST APIをどう狙うか

防御を考える前に、攻撃者の視点を理解しましょう。OWASP（Open Web Application Security Project）はAPIに特化した脆弱性リスト「OWASP API Security Top 10」を公開しています。その中から現場で特に多く見られる攻撃パターンを紹介します。

【注意】認証・認可の欠陥

最も深刻な脆弱性が、認証と認可の問題です。APIエンドポイントに認証が設定されておらず、URLを知っていれば誰でもアクセスできるケースがあります。また、ログインはできても「ユーザーAがユーザーBのデータを取得できる」という横断的な認可ミス（IDORと呼ばれる安全でない直接オブジェクト参照）も頻繁に発生します。

具体例として、こんなAPIを考えてみます。

# 脆弱なAPI設計の例（概念的な説明）
GET /api/users/123/profile   # ← ユーザーID「123」のプロフィール取得
GET /api/users/124/profile   # ← IDを「124」に変えると別ユーザーのデータが取れてしまう

このようにAPIが内部IDをURLに含めている場合、攻撃者はIDを連番で変えながら大量のデータを収集できます。数字を1つずつ変えるだけで全ユーザーの情報が取れてしまう、という事故が実際に起きています。

【注意】過剰なデータ露出

APIがフロントエンドで必要な情報以上のデータを返してしまうケースです。「表示に必要な項目はフロントエンド側でフィルタリングすればいい」という設計で、ユーザーのメールアドレスやハッシュ化済みパスワード、内部管理IDなどが含まれたままになっていることがあります。

攻撃者はブラウザの開発者ツールやパケットキャプチャツールでAPIレスポンスを確認し、こうした漏洩データを収集します。画面上に表示されなくても、レスポンスに含まれていれば取得可能です。

【注意】レート制限の欠如

APIに呼び出し回数の制限がない場合、攻撃者は短時間に大量のリクエストを送り、総当たり攻撃（ブルートフォース）やクレデンシャルスタッフィングを仕掛けられます。ログイン用APIに制限がなければ、10分間で何千回もパスワードを試し続けることが可能です。

【注意】不要なHTTPメソッドの許可

本来GETリクエストのみを想定したエンドポイントが、PUTやDELETEメソッドも受け付けてしまうケースです。サーバーの設定ミスや開発時のデバッグ設定が本番環境に残ることで起こります。意図しないデータの更新・削除につながるリスクがあります。

【注意】APIキーの平文露出

フロントエンドのJavaScriptコード内にAPIキーを直書きしている場合、ブラウザの開発者ツールで誰でも確認できてしまいます。GitHubなどにソースコードを公開した際にシークレットが漏洩するケースも後を絶ちません。

具体的な防御手順

1. 認証・認可を適切に実装する

すべてのAPIエンドポイントに認証を設定するのは当然として、「誰が何にアクセスできるか」という認可の設計が特に重要です。

・全エンドポイントへの認証強制: 内部APIであってもAPIキーやBearerトークンを必須とし、認証なしのアクセスは一切拒否する
・オブジェクトレベルの認可チェック: リクエストしたユーザーがそのリソースにアクセスする権限があるかを、APIサーバー側で必ず検証する（ユーザーA向けのデータをユーザーBが取得できないようにする）
・最小権限の原則: 読み取り専用のクライアントには書き込み権限を与えない。APIキーごとにアクセス可能なエンドポイントを絞る
・JWTの適切な実装: JSON Web Tokenを使う場合、署名アルゴリズムの設定ミスや有効期限の未設定に注意する

認証と認可の違いとは？混同しやすい2つの概念を具体例でわかりやすく解説も合わせて確認してください。

2. 入力バリデーションとレート制限を設ける

APIに送信されるすべてのデータは「信頼できない外部入力」として扱います。フロントエンドでバリデーションしているからといって、APIサーバー側の検証を省略してはいけません。攻撃者はフロントエンドを迂回してAPIを直接叩いてきます。

・スキーマバリデーション: リクエストのパラメータ型・長さ・許容値をAPIサーバー側で検証する
・SQLインジェクション対策: クエリにパラメータを直接埋め込まず、プレースホルダーやORMを使用する
・レート制限の実装: IPアドレスごと・ユーザーごとに単位時間あたりのリクエスト数を制限し、上限を超えた場合は429（Too Many Requests）を返す
・ページネーションの必須化: 1回のリクエストで返すデータ件数の上限を設定し、大量データの一括取得を防ぐ

WAFの導入もAPIへの攻撃を補完的に防ぐ有効な手段です。WAFとは？Webアプリケーションファイアウォールの仕組み・選び方・導入手順をわかりやすく解説も参考にしてください。

3. 機密情報の露出を最小化する

APIのレスポンスには「表示に必要な情報だけ」を返す設計を徹底します。これはサーバー側で行う必要があり、フロントエンドのフィルタリングだけでは不十分です。

・フィールドフィルタリング: 内部ID、パスワードハッシュ、他ユーザーの個人情報はレスポンスに絶対含めない
・エラーメッセージの制御: 詳細なエラー情報（スタックトレース、SQLエラー等）は本番環境では返さない。汎用的なエラーメッセージのみ返す
・HTTPS通信の強制: HTTPでのアクセスは自動的にHTTPSにリダイレクトし、すべての通信を暗号化する
・シークレットの適切な管理: APIキーや接続文字列をソースコードやGitリポジトリに直書きせず、環境変数やシークレット管理サービスを使用する

シークレット管理の失敗事例と対策については、CAMPFIRE GitHub不正アクセスに学ぶシークレット管理｜認証情報の誤アップロードを防ぐ実務が参考になります。

中小企業でも今日からできること

大規模なシステム改修が難しい組織でも、明日から実施できる対策があります。

・APIエンドポイントの棚卸し: 社内・外部問わず、現在稼働中のAPIをリストアップし、認証が設定されているかを確認する。「認証なしでアクセスできるAPIがないか」を確認するだけで多くのリスクが見えてきます
・不要なエンドポイントの無効化: 使われていないAPIエンドポイントは即座に閉じる。開発時のテスト用エンドポイントが本番環境に残っていないかを確認する
・APIアクセスログの有効化と確認: APIへのアクセスログを有効化し、異常なリクエスト数・失敗続きのアクセス・通常と異なるIPからのアクセスを定期的に確認する
・レスポンスの目視確認: 主要なAPIエンドポイントのレスポンスをcurlなどで確認し、不必要な情報が含まれていないかをチェックする
・ライブラリの定期更新: APIサーバーで使用しているフレームワークやライブラリを定期的に更新し、既知の脆弱性を排除する

なお、GraphQL APIを採用している場合は、REST APIとは異なる固有の脆弱性パターンが存在します。GraphQL APIの脆弱性とは？スキーマ漏洩・インジェクション・過剰クエリの仕組みと防御策もあわせてご確認ください。

よくある誤解と注意点

誤解1: 「内部APIだから外部に公開されていない」
社内でのみ使用するAPIでも、攻撃者が社内ネットワークに侵入した際には狙われます。また、開発者のPCがマルウェアに感染してAPIトークンが盗まれるケースも現実に起きています。内部APIでも認証・認可は必須です。

誤解2: 「クライアント側で検証しているから大丈夫」
ブラウザやスマートフォンアプリのバリデーションは簡単にバイパスできます。curlやPostmanなど、どんなツールからでもAPIを直接叩けます。サーバー側の検証は絶対に省略できません。

誤解3: 「APIキーをURLに含めても見えないから安全」
URLに含めたAPIキーはサーバーのアクセスログ、ブラウザの履歴、プロキシのログなどに残ります。APIキーはHTTPSのリクエストボディかAuthorizationヘッダーに含める設計にしてください。

誤解4: 「OWASP Top 10さえ対策すれば完璧」
OWASPは重要な基準ですが、あくまでも「よく見られる脆弱性のリスト」です。OWASP Top 10の各項目を把握した上で、自社のシステム特性に応じた追加対策を検討してください。

本記事のまとめ

APIは現代システムの「縁の下の力持ち」です。見えにくい部分だからこそ後回しにされがちですが、攻撃者はそこを狙っています。まずはエンドポイントの棚卸しから始め、認証・認可・入力バリデーション・レート制限の4点を確認するところから始めてください。

最初から完璧を目指す必要はありません。現状を把握し、優先度の高いリスクから順番に手を打っていくことが、現場の情シスにできる現実的なアプローチです。