自社で開発・公開しているAPIについて、「守るための対策に抜けがないか」を確信を持って言えるでしょうか。APIは社内外のシステムをつなぐ入り口であり、Webアプリの画面を経由せずデータへ直接アクセスできるぶん、認証や認可の設定が甘いと情報漏えいや不正操作に直結します。APIの利用が広がるにつれて、攻撃者が狙う対象も拡大しています。
「認証を適切に」「ゼロトラストを導入しましょう」といった方針は分かっても、具体的に何をどう設定すればよいかは、自社で手を動かす段になると迷いがちです。自社の現状と突き合わせて「やれていること・抜けているかもしれないこと」を棚卸ししたい担当者には、対策が漏れなく並んだ一覧と、各対策の具体的な中身が必要です。
本記事では、APIを守るための対策を「対策項目 × 防ぐ主な攻撃 × 具体的な実装ポイント」のチェックリストとして整理し、各対策で実際に何をするかを、OAuth 2.0やTLSのバージョンといった具体的な中身まで解説します。
あわせて、各対策がどのリスクに対応するかをOWASP API Security Top 10（APIに特化した代表的な脅威の一覧）にひも付け、自社環境に合わせた着手の優先順位、そして自前でカバーしきれない部分を外部の脆弱性診断やWAF/WAAPで補う考え方まで扱います。
目次
一括ダウンロードする
APIセキュリティとは・なぜ対策が必要か
APIセキュリティとは、API（アプリケーション同士がデータや機能をやり取りするための接続口）を、不正アクセスやデータの窃取、サービス妨害といった攻撃から守るための対策の総称です。Webアプリケーションが画面（ブラウザ）を通じて人が操作するのに対し、APIはプログラムが直接データをやり取りします。
画面上のチェックを経由しないため、認証・認可やレート制限といった制御をAPI側で正しく設計しておく必要があります。
対策が必要とされる背景には、APIの利用拡大があります。クラウドサービスやスマートフォンアプリ、外部サービスとの連携が一般的になり、企業が公開・運用するAPIの数は増え続けています。APIは仕様が公開されていることも多く、攻撃者にとっては狙いを定めやすい対象です。
とりわけ、本来アクセスできないはずのデータに権限の設定不備を突いてアクセスされる「認可の不備」は、APIで繰り返し問題になってきた代表的なリスクです。
ここからは、APIを守るために押さえるべき対策を一覧で確認したうえで、各対策の具体的な実装ポイントへと進みます。
APIセキュリティ対策チェックリスト
APIを守るための主な対策を、「対策項目 × 防ぐ主な攻撃 × 具体的な実装ポイント」の形で一覧にまとめました。自社で「できていること・抜けているかもしれないこと」を突き合わせる棚卸しにご活用ください。各項目の詳しい実装ポイントは次のセクションで解説します。
| 対策項目 | 防ぐ主な攻撃・リスク（該当するOWASP API項目） | 具体的な実装ポイントの要点 |
|---|---|---|
| 認証（利用者の確認） | 認証の不備（API2:2023 Broken Authentication） | OAuth 2.0・JWT・mTLS・APIキーを用途で使い分け、トークンは短命かつ失効できる設計にする |
| 認可・アクセス制御 | オブジェクトレベル認可の不備（API1:2023 BOLA）／機能レベル認可の不備（API5:2023） | 最小権限を徹底し、リクエストごとに「誰が・どのデータに」アクセスしてよいかをサーバー側で検証する（ゼロトラスト） |
| 通信の暗号化（TLS） | 通信の盗聴・改ざん／設定不備（API8:2023 Security Misconfiguration） | TLS 1.2を最低ライン、TLS 1.3に対応し、SSLや古いTLSは無効化する |
| レート制限・重要業務フローの保護 | リソースの過剰消費（API4:2023 Unrestricted Resource Consumption）／重要業務フローへの無制限アクセス（API6:2023 Unrestricted Access to Sensitive Business Flows） | 利用者・APIキー・IP単位で上限を設け、超過時は429で応答する。予約・購入・送金などの重要業務フローはボット対策とフロー単位の制限で自動化濫用を防ぐ |
| 入力検証／機微情報の非公開 | プロパティレベル認可の不備（API3:2023）／サーバーサイドリクエストフォージェリ（API7:2023 Server Side Request Forgery）／インジェクション | 入力を信頼せず検証し、サーバーが外部URLを取得する処理は宛先を許可リストで制限する。URLに機微情報を含めず、レスポンスで返す項目を必要最小限に絞る |
| APIの棚卸し | 不適切な資産管理（API9:2023 Improper Inventory Management） | シャドーAPI・ゾンビAPIを洗い出し、公開中のエンドポイントとバージョンを一覧で管理する |
| 監視・ログ・異常検知 | 監視・ログの不足による侵害の検知漏れ（2019年版では独立項目のAPI10 Insufficient Logging & Monitoringだったが、2023年版では独立項目から外れた） | アクセスログを取得し、異常なアクセスを検知・アラートできるようにする |
| 自前で補えない部分の補強 | 外部APIの安全でない利用（API10:2023 Unsafe Consumption of APIs）／実装の抜け・運用中の攻撃への横断的リスク | 外部APIを利用する際はレスポンスを検証し、WAF/WAAPで運用中の攻撃を緩和、外部の脆弱性診断・APIセキュリティテストで実装の抜けを検証する（詳しくは「自前で足りない部分を補う方法」節） |
リスク区分はOWASP API Security Top 10（2023）の項目名に対応。
各対策の具体的な実装ポイント
チェックリストの各項目について、「適切に」で終わらせず、具体的に何をするかを解説します。
認証：APIの利用者をどう確かめるか
認証は「リクエストを送ってきたのが誰か」を確かめる仕組みです。公開APIや外部連携では、業界標準であるOAuth 2.0（The OAuth 2.0 Authorization Framework）に基づくアクセストークンでの認可委譲が広く使われます。
トークン形式としては、利用者やアクセス権の情報を含むJWT（JSON Web Token）が一般的で、サーバー間の強固な相互認証が必要な場面ではmTLS（クライアント証明書を使った相互TLS認証）を用います。簡易なAPIキーだけに頼る方式は、識別はできても強固な認証とは言えないため、APIキーは用途を限定して扱うのが基本です。
トークンの扱いにも注意が必要です。OAuth 2.0のBearerトークンは「そのトークンを持っている者なら誰でも使える」性質を持つため、漏えいすればそのまま悪用されます。そのため、後述する通信の暗号化を前提に、アクセストークンの有効期限は短め（用途によるが数分〜十数分程度）に設定し、継続利用はリフレッシュトークンで更新する形にして、漏えい時に失効（無効化）できる仕組みをあわせて用意します。
出典・参考資料（3件）
認可・アクセス制御：誰に何を許すか
認証で「誰か」を確かめたら、次は「その人に何を許すか」を制御します。APIで最も繰り返し問題になってきたのが、オブジェクトレベルの認可不備です。たとえば利用者IDやデータIDをリクエストのパラメータで指定する設計で、他人のIDに差し替えると他人のデータが取得できてしまう、といった不備がこれにあたります。
OWASP API Security Top 10では、これをAPI1:2023 Broken Object Level Authorization（BOLA）として筆頭に挙げています。
対策の基本は、リクエストのたびにサーバー側で「このトークンの利用者が、この対象データ・この操作にアクセスしてよいか」を必ず検証することです。クライアント側の制御や画面の出し分けだけに頼らず、最小権限（必要な範囲のみ許可する）を徹底します。社内ネットワークだから信頼する、といった前提を置かず、すべてのリクエストを検証するゼロトラストの考え方が、APIのアクセス制御では有効です。
通信の暗号化：TLSのバージョンをどう設定するか
APIの通信は、盗聴や改ざんを防ぐためにTLSで暗号化します。OWASPのREST Security Cheat Sheetも「Secure REST services must only provide HTTPS endpoints.（安全なRESTサービスはHTTPSエンドポイントのみを提供すべき）」と、HTTPS必須を明記しています。
設定の際は、使用するTLSのバージョンに注意します。広く参照される米国NISTのガイドライン（SP 800-52 Rev.2）では、利用者・企業向けのサーバーはTLS 1.2を使えるように設定すること、TLS 1.3への対応が望ましいこと、そしてSSL 2.0・SSL 3.0は使用を許可しないことが示されています。
古いTLS 1.0・1.1も無効化し、TLS 1.2以上に揃えるのが実務上の基本方針です。
出典・参考資料（2件）
レート制限：過剰なリクエストをどう抑えるか
レート制限は、一定時間あたりのリクエスト数に上限を設け、リソースの過剰消費を防ぐ対策です。上限がないと、総当たりでの認証情報の試行や、大量リクエストによるサービス妨害（DoS）、ボットによる自動アクセスを受けやすくなります。
OWASP API Security Top 10でも、API4:2023 Unrestricted Resource Consumption（リソース消費の無制限）として独立した項目になっています。
実装では、利用者やAPIキー単位、IPアドレス単位など「何を基準に数えるか」を決めます。認証やログインのような悪用されやすいエンドポイントは厳しめ、一般的な参照系は緩めに、と用途ごとに上限を変えるのが基本です。
上限を超えたリクエストにはHTTPステータス429（Too Many Requests）で応答し、再試行までの待機時間をRetry-Afterヘッダーで知らせると、正規の利用者が制限に達した際の挙動が予測しやすくなります。
単純なリクエスト数の制限だけでなく、予約・購入・送金・ポイント交換といった重要な業務フローへの対策も必要です。OWASP API Security Top 10はこれをAPI6:2023 Unrestricted Access to Sensitive Business Flows（重要なビジネスフローへの無制限アクセス）として挙げています。
こうしたフローが自動化・大量実行で濫用されると、在庫の買い占めや不正なポイント取得などの実害につながります。ボットによる自動アクセスの検知や、業務フロー単位での実行回数の制限で、人間の通常利用を超えた使われ方を防ぎます。
入力検証と機微情報の非公開
APIが受け取る入力は、信頼せずに検証するのが原則です。OWASPのREST Security Cheat Sheetも「Do not trust input parameters/objects.（入力のパラメータやオブジェクトを信頼しない）」としています。想定する型・桁・形式に合っているかをサーバー側で確認し、SQLインジェクションやコマンドインジェクションといった攻撃の入り口をふさぎます。
入力検証は、サーバーが外部のURLにアクセスする処理でも重要です。利用者が指定したURLをサーバー側が取得する作りだと、社内システムやクラウドのメタデータなど本来アクセスできない先を代わりに叩かせる攻撃を受けることがあります。OWASP API Security Top 10はこれをAPI7:2023 Server Side Request Forgery（SSRF）として挙げています。
対策として、サーバーが取得してよい宛先を許可リストで限定し、受け取ったURLの形式やアクセス先を検証します。内部ネットワークやクラウドのメタデータ領域へのアクセスは遮断しておきます。
出力側にも注意が必要です。レスポンスで必要以上の項目を返すと、本来見せるべきでない属性まで露出します。返すデータは必要最小限に絞り込むことが重要です。
あわせて、同Cheat Sheetが「Passwords, security tokens, and API keys should not appear in the URL（パスワード・セキュリティトークン・APIキーをURLに含めない）」と述べるとおり、機微情報はURLではなくリクエストボディやヘッダーで扱います。
URLはサーバーのログに残るため、そこに認証情報が記録されるのを避けるためです。
出典・参考資料（1件）
APIの棚卸し：シャドーAPI・ゾンビAPIをなくす
守るべき対象を把握できていなければ、対策の抜けは避けられません。管理外で公開されている「シャドーAPI」や、使われなくなったのに稼働し続ける「ゾンビAPI」は、対策が及ばないまま攻撃の経路になります。OWASP API Security Top 10では、これをAPI9:2023 Improper Inventory Management（不適切な資産管理）として挙げています。
対策として、公開中のAPIエンドポイントとそのバージョンを一覧化し、古いバージョンや不要になったAPIは計画的に停止します。仕様書（OpenAPIなどのドキュメント）と実際に稼働しているエンドポイントを突き合わせ、ドキュメントにない「野良API」が存在しないかを定期的に確認することが、棚卸しの基本です。
監視・ログ・異常検知
対策を講じても、攻撃を完全に防ぎきることはできません。だからこそ、アクセスログを取得し、異常なアクセスを早期に検知できる体制が重要になります。認証の失敗が短時間に多発する、特定のエンドポイントへのアクセスが急増するといった兆候を捉え、アラートを上げられるようにしておきます。ログは攻撃の検知だけでなく、問題が起きた際の調査（どのデータにいつアクセスがあったか）にも欠かせません。
取得したログには認証情報などの機微情報を残さないよう、記録内容にも配慮します。
API固有のリスクとOWASP API Security Top 10との対応
ここまでの対策が「どの攻撃を防ぐのか」を整理するうえで、拠り所になるのがOWASP API Security Top 10です。これは、Webアプリケーション全般を対象としたOWASP Top 10とは別に、API特有のリスクをまとめたもので、非営利団体OWASPが公開しています。最新版は2023年版で、以下の10項目が挙げられています。
API1:2023 – Broken Object Level Authorization
OWASP API Security Top 10 2023｜OWASP API Security Project（https://owasp.org/API-Security/editions/2023/en/0x11-t10/）
API2:2023 – Broken Authentication
API3:2023 – Broken Object Property Level Authorization
API4:2023 – Unrestricted Resource Consumption
API5:2023 – Broken Function Level Authorization
API6:2023 – Unrestricted Access to Sensitive Business Flows
API7:2023 – Server Side Request Forgery
API8:2023 – Security Misconfiguration
API9:2023 – Improper Inventory Management
API10:2023 – Unsafe Consumption of APIs
前のセクションで解説した対策は、このリストの各項目に対応しています。認証の対策はAPI2（認証の不備）、認可・アクセス制御はAPI1のBOLAとAPI5（機能レベル認可の不備）、レート制限はAPI4（リソース消費の無制限）とAPI6（重要なビジネスフローへの無制限アクセス）に対応します。
入力検証は、返す項目の絞り込みがAPI3（プロパティレベル認可の不備）、サーバーの外部URL取得の検証がAPI7（SSRF）に対応します。APIの棚卸しはAPI9（不適切な資産管理）、通信の暗号化や権限・公開範囲などの設定の見直しはAPI8（設定不備）に対応します。
残るAPI10（外部APIの安全でない利用）は、自社が外部のAPIを呼び出す際に、そのレスポンスを無条件に信頼せず検証する対策に対応します。このように、ここまでの対策で10項目を一通りカバーできます。
自社の対策を点検する際は、この10項目を基準に「どの項目にどの対策で対応しているか」を確認すると、抜けを見つけやすくなります。
2019年版にあった「過剰なデータ公開（Excessive Data Exposure）」は、2023年版ではAPI3:2023 Broken Object Property Level Authorizationに統合されています。古い資料を参照する際は、項目名の違いに注意してください。
対策の優先順位・着手順（自社環境別）
対策を一覧で把握できても、すべてを同時に完璧にするのは現実的ではありません。どこから着手するかは、OWASP API Security Top 10の並び順が一つの客観的な手がかりになります。このリストは、報告頻度や影響度を踏まえて並べられており、筆頭がAPI1:2023 BOLA（オブジェクトレベルの認可不備）、続いてAPI2:2023（認証の不備）です。
そのため、まず認可・認証の設計を固めることが、APIセキュリティでは最優先となります。
その次に、全APIに共通して効く通信の暗号化（TLS）と入力検証を整え、レート制限で過剰消費を抑え、監視・ログで検知できる状態にする、という順序が自然です。APIの棚卸しは、守る対象を確定させる土台として、早い段階で一度行っておくと後続の対策の抜け漏れを防げます。
ここまでの着手順を図にまとめると、次のとおりです。
自社の状況によって重点も変わります。
- 外部に公開しているAPIがある場合：認証・認可とレート制限、監視の優先度が特に高くなります。不特定多数からアクセスされうるため、WAF/WAAPによる緩和や外部の脆弱性診断の併用も検討します。
- クラウド上でAPIを運用している場合：APIゲートウェイやクラウドの設定不備（API8のSecurity Misconfiguration）にも注意が必要です。クラウドの権限設定・公開範囲の点検を対策に含めます。
- 社内向け・システム間連携が中心の場合：外部公開APIほど露出は大きくないものの、認可の不備は内部からの不正利用につながります。APIの棚卸しでシャドーAPIをなくし、サーバー側での認可検証を徹底します。
ここからは、自前の実装だけではカバーしきれない部分を、外部のツールや診断でどう補うかを見ていきます。
一括ダウンロードする
自前で足りない部分を補う方法（WAF/WAAP・外部の脆弱性診断）
ここまでの実装対策は、APIを守るうえでの根本的な対策です。一方で、実装の抜けを自力で完全に洗い出すのは難しく、運用中の攻撃をリアルタイムに緩和する仕組みも必要になります。これらを補うのが、WAF/WAAPによる防御と、外部の脆弱性診断・APIセキュリティテストです。
WAFとWAAPの役割の違い
WAF（Web Application Firewall）は、Webアプリケーションへの攻撃を検知・遮断するソフトウェアまたはハードウェアです。ここで押さえておきたいのは、WAFが「根本対策」ではなく「影響を低減する対策」だという位置づけです。IPAのWAF読本は次のように説明しています。
WAF は、ウェブアプリケーションの脆弱性を悪用した攻撃などからウェブアプリケーションを保護するソフトウェア、またはハードウェアです。WAF は脆弱性を修正するといったウェブアプリケーションの実装面での根本的な対策ではなく、攻撃による影響を低減する対策です。
Web Application Firewall (WAF) 読本｜独立行政法人情報処理推進機構（IPA）（https://www.ipa.go.jp/archive/security/vuln/waf.html）
このように、WAFは実装対策の「代わり」ではなく、実装対策を前提とした緩和策という位置づけです。WAAP（Web Application and API Protection）は、このWAFに加えてDDoS緩和・ボット管理・API保護までをまとめたもので、調査会社Gartnerが定義するカテゴリです。API特有の攻撃まで含めて守りたい場合に選択肢となります。
いずれも、前述した認証・認可などの実装対策を置き換えるものではなく、組み合わせて使うものと理解しておくことが大切です。
導入を検討する目安としては、外部に公開していて不特定多数からアクセスされるAPIや、DDoS・ボットによる自動アクセスのリスクが高いサービスではWAF/WAAPの効果が大きくなります。一方、社内向け中心で露出が小さい場合は、まず実装対策とAPIの棚卸しを優先し、必要に応じて検討する、という順序が現実的です。
認証・認可やレート制限といった機能は、APIゲートウェイ側でも提供されることがあります。ゲートウェイで共通的に効かせられる制御はゲートウェイに寄せ、WAF/WAAPは攻撃の検知・緩和に、という形で役割を分けると重複を避けられます。
脆弱性診断・APIセキュリティテストで実装を検証する
自前の実装に抜けがないかを客観的に確かめるには、外部の脆弱性診断やAPIセキュリティテストが有効です。代表的な手法がDAST（動的アプリケーションセキュリティテスト）で、OWASPは「稼働中のアプリケーションに疑似的な攻撃リクエストを送り込み、脆弱性や弱点を検出するブラックボックス型のテスト」と説明しています。
実際に動いているAPIに対して外部から検証するため、設計書だけでは気づきにくい実装上の不備を洗い出せます。
出典・参考資料（1件）
では、こうした診断はどのくらいの頻度で行うべきでしょうか。脆弱性診断を提供するCoWorker株式会社の一ノ瀬氏は、攻撃側の変化を背景に、診断の頻度について次のように述べています。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
APIの診断には、ツール（SaaS）で自動的にスキャンする形態と、専門家が診断してレポートを納品する受託型があります。継続的に実装の抜けをチェックしたい場合はツール型、リリース前にまとめて深く検証したい場合は受託型、というように、目的に応じて使い分けます。ここでは、APIの診断に対応したサービスを紹介します。
| 比較項目 | Aikido Security | CoWorker 脆弱性診断サービス |
|---|---|---|
| 診断の形態 | ツール型（SaaS・自動スキャン） | 受託型（AI自動解析＋専門家の最終確認） |
| API診断の方式 | DAST（動的診断）・API Scanning 自動スキャンを継続的に実行 | 動的脆弱性診断（Web/API） AIが解析し専門家が最終確認 |
| 診断対象の範囲 | API・Web・ソースコード・クラウド設定・コンテナ | API・Web・ソースコード・設計書 |
| 料金目安 | 3,780ドル/年〜（Basicプラン） 無料で始められるプランあり | ソースコードAI診断は15万円〜 Web/API診断を含むプランは50万円〜 |
| 向いているケース | 開発・運用のサイクルの中で継続的に診断したい開発会社・開発部門 | リリース前にAPIをまとめて検証したい・専門家の視点を交えたい |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを1つの管理画面で検査するSaaS型の脆弱性診断ツールです。人が診断してレポートを納品する受託型ではなく、自動スキャンを継続的に回す形態のため、開発・運用のサイクルの中でセキュリティをチェックし続けたい開発会社・開発部門に向いています。
APIに関しては、稼働中のアプリに対するDAST（動的診断）とAPI Scanningに対応しています。あわせてソースコードを対象とするSAST・依存関係を調べるSCA、クラウド設定を点検するCSPMもカバーし、APIの実装からその土台となるコード・インフラまでをまとめて検査できる点が特徴です。検知したアラートは自動でトリアージ（優先度付け）され、誤検知を減らす仕組みを備えます。
Slack・Teams・Jira・AWSなどと連携でき、検知から対応までを開発の流れに組み込めます。
開発の流れにセキュリティを組み込むこうした発想が広がる背景について、Aikido Securityを日本で取り扱う株式会社AndGoの原氏は、開発現場でのセキュリティの位置づけの変化を次のように説明しています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。だから開発の初期からセキュリティを組み込むDevSecOps（開発（Dev）、セキュリティ（Sec）、運用（Ops））が現実解になってきていて、Aikido Securityはその“回し方”を作るためのツールだと考えています。
日本国内では株式会社AndGoが取り扱っています。料金は、1〜10ユーザーでSAST・SCA・CSPM・DAST・ASM（攻撃対象領域の管理）に対応するBasicプランが年額3,780ドル、Proプランが年額7,560ドル、Customは要問い合わせです（AndGo取扱ページ・MCB FinTechカタログ掲載情報、2026年11月時点）。
請求は為替を考慮した日本円での案内となり、正式な料金は問い合わせでの確認が前提です。無料で始められるプランも用意されています。
CoWorker 脆弱性診断サービス（CoWorker株式会社）
AIによる自動解析と社内のセキュリティ専門家の最終確認を組み合わせた受託型の診断を提供するのが、CoWorker株式会社の「CoWorker 脆弱性診断サービス」です。自社開発のAI「Red Agent」が一次解析を行い、専門家が確認してレポートにまとめます。診断メニューは次の3つで構成されています。
- ソースコードAI診断
- 動的脆弱性診断（Web/API診断）
- 実践攻撃シミュレーション診断（ペネトレーションテスト）
動的脆弱性診断は、稼働中のWebアプリケーションやAPIを対象に、攻撃者の視点で実際に攻撃を試みて脆弱性を洗い出します。AIによる自動解析で診断の時間を短縮しつつ、最終的に専門家が確認してレポートを作成するため、ツール単体では判断が難しい箇所も人の目で補える点が特徴です。リリース前にAPIをまとめて検証したい、専門家の視点を交えて診断したい、といった場面に向いています。
料金プランは、診断対象や再診断の有無で次のように分かれています（MCB FinTechカタログ掲載情報）。
- ソースコードAI診断：150,000円
- Lite（ソースコード＋動的診断〈Web/API〉、API 150件まで）：500,000円
- Standard（再診断1回、API 300件まで）：1,000,000円
- Professional（詳細レポート・再診断2回、API 500件まで）：1,500,000円
APIのエンドポイント数に応じてプランが分かれているため、診断対象の規模に合わせて選べます。
APIの脆弱性診断は、画面を操作して調べる従来のWebアプリケーション診断では拾いきれない認可の欠陥（他人のデータを操作できてしまうBOLAなど）まで対象にできる点が特徴です。どのサービスがどこまでAPIを診断するか、ツール型と手動の違いや費用の考え方を含めた選び方は、以下の記事で詳しく解説しています。
ここで取り上げたのはAPIの診断に対応したサービスですが、対象範囲や診断方法の異なる脆弱性診断サービスは数多くあります。種類・費用相場・選び方を比較して、自社に合う診断サービスを検討したい場合は、以下の記事で詳しく解説しています。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
まとめ
APIセキュリティの対策は、認証・認可、通信の暗号化、レート制限、入力検証、APIの棚卸し、監視・ログといった項目を漏れなく押さえることが出発点です。本記事のチェックリストを使って自社の現状を棚卸しし、OWASP API Security Top 10を基準に「どの項目にどの対策で対応しているか」を点検してみてください。
着手の順序としては、API1のBOLAをはじめとする認可・認証の設計を最優先に固め、続いて全APIに共通する暗号化・入力検証、レート制限、監視へと広げていくのが基本です。そのうえで、自前の実装だけでは確かめきれない部分は、外部の脆弱性診断やAPIセキュリティテストで検証し、WAF/WAAPで運用中の攻撃を緩和する、という組み合わせで守りを固めていきましょう。
自社に合った診断サービスを比較検討する際は、以下から各社の資料をまとめて請求できます。
一括ダウンロードする
よくある質問（FAQ）
Q. APIセキュリティとは何ですか？
A. APIセキュリティとは、API（アプリケーション同士がデータや機能をやり取りする接続口）を、不正アクセス・データ窃取・サービス妨害などの攻撃から守るための対策の総称です。Webアプリケーションが画面を通じて人が操作するのに対し、APIはプログラムが直接データをやり取りします。
画面上のチェックを経由しないため、認証・認可、通信の暗号化、レート制限、入力検証といった制御をAPI側で正しく設計しておく必要があります。
Q. OWASP API Security Top 10とは何ですか？
A. OWASP API Security Top 10とは、非営利団体OWASPが公開している、API特有の代表的なセキュリティリスクをまとめた一覧です。Webアプリケーション全般を対象とするOWASP Top 10とは別に用意されたもので、最新は2023年版です。
筆頭のAPI1:2023 BOLA（オブジェクトレベル認可の不備）をはじめ10項目が挙げられており、自社の対策が標準に当たっているか、どこに抜けがあるかを点検する基準として使えます。
Q. APIの保護はAPIキーだけで十分ですか？
A. APIキーだけでは不十分です。APIキーは呼び出し元を識別するための仕組みで、それ自体は強固な認証や通信の暗号化を提供しません。公開APIや外部連携では、OAuth 2.0に基づくアクセストークンによる認可やTLSによる暗号化と組み合わせ、APIキーは用途を限定して扱うのが基本です。
Q. APIセキュリティは認証だけ対策すれば十分ですか？
A. 認証だけでは不十分で、認可・通信の暗号化・入力検証・レート制限・監視まで含めて対策する必要があります。特に、認証で「誰か」を確かめた後に「その利用者が対象データや操作にアクセスしてよいか」をサーバー側で検証する認可（アクセス制御）は、APIで最も繰り返し問題になってきたBOLA（API1:2023）に直結します。認証と認可は別の対策として、両方を設計することが重要です。
Q. APIセキュリティにおけるWAFとWAAPの違いは何ですか？
A. WAFはWebアプリケーションへの攻撃を検知・遮断する仕組みで、WAAPはそのWAFにDDoS緩和・ボット管理・API保護までをまとめた、より広いカテゴリです。いずれもIPAが示すとおり、実装上の脆弱性を修正する根本対策ではなく、攻撃による影響を低減する緩和策です。認証・認可などの実装対策を置き換えるものではなく、組み合わせて使います。
API特有の攻撃まで含めて守りたい場合はWAAPが選択肢になります。
Q. APIの脆弱性診断にはどのような手法を使いますか（DASTとは何ですか）？
A. APIの脆弱性診断では、稼働中のアプリケーションに疑似的な攻撃リクエストを送り込んで弱点を検出するDAST（動的アプリケーションセキュリティテスト）が代表的な手法です。実際に動いているAPIを外部から検証するため、設計書だけでは気づきにくい実装上の不備を洗い出せます。
診断は、SaaSツールで自動スキャンする形態と、専門家が診断してレポートを納品する受託型に分かれ、継続的にチェックしたい場合はツール型、リリース前にまとめて深く検証したい場合は受託型、というように目的で使い分けます。
Q. REST APIのセキュリティで特に注意すべき点は何ですか？
A. REST APIでは、HTTPS（TLS）による通信の暗号化、URLに機微情報を含めないこと、入力の検証、返すデータの最小化を特に押さえます。OWASPのREST Security Cheat Sheetは、HTTPSエンドポイントのみを提供すること、パスワードやトークン・APIキーをURLに含めないこと、入力のパラメータやオブジェクトを信頼しないことを挙げています。
あわせて、公開中のエンドポイントを棚卸しして把握しておくことも、抜けをなくすうえで重要です。
Q. APIセキュリティとAPI管理（APIマネジメント）はどう違いますか？
A. APIセキュリティは脅威からAPIを守る対策、API管理（APIマネジメント）はAPIの公開・バージョン・利用状況といったライフサイクル全体を運用する仕組みです。両者は重なる部分もあり、APIゲートウェイのように認証やレート制限などのセキュリティ機能を備える管理基盤もあります。
ただし、管理基盤を導入すればセキュリティが自動的に十分になるわけではなく、本記事で挙げた各対策は別途点検する必要があります。
Q. APIセキュリティとアプリケーションセキュリティはどう違いますか？
A. APIセキュリティはAPIのエンドポイント・データのやり取り・アクセス制御に焦点を当てた対策で、アプリケーションセキュリティは画面（UI）・データベース・ビジネスロジックまで含むアプリ全体を対象とした対策です。
両者は重なりますが、APIは画面を経由せずプログラムが直接データにアクセスするぶん、BOLA（オブジェクトレベル認可の不備）のような固有のリスクがあり、OWASP API Security Top 10という専用の基準が用意されています。
Q. APIセキュリティ対策はどこから着手すればよいですか？
A. まず認可・認証の設計から着手するのが基本です。OWASP API Security Top 10は報告頻度や影響度を踏まえた並びで、筆頭がAPI1:2023 BOLA（オブジェクトレベル認可の不備）、続いてAPI2:2023（認証の不備）です。その後、全APIに共通して効く通信の暗号化と入力検証を整え、レート制限で過剰消費を抑え、監視・ログで検知できる状態にする、という順序が自然です。
守る対象を確定するAPIの棚卸しは、早い段階で一度行っておくと後続の対策の抜け漏れを防げます。
APIの脆弱性診断・セキュリティ診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、APIの脆弱性診断・セキュリティ診断サービスの最新資料を無料で一括請求できます。診断の方式や対応範囲「Web・API・ソースコード」、料金、サポート体制を比べて、自社に合うサービスを選べます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
