Security NEWS TOPに戻る
バックナンバー TOPに戻る
デジタル化が進む現代において、Webサービスやスマートフォンアプリ、IoT機器まで、あらゆるシステムがAPIを通じて連携しています。しかし、その利便性の反面、APIを標的としたサイバー攻撃も急増しています。こうした背景の中、APIに特化したセキュリティリスクをまとめたのが「OWASP API Security Top 10」です。
「OWASP Top 10」を中心に、基本的なセキュリティ知識を深め、企業での対策に活かすことを目的としたシリーズ第2回の今回は、API開発や管理に関わる企業の情報システム部門・開発担当者に向けて、OWASP API Security Top 10の概要と代表的なリスク、具体的な対策についてわかりやすく解説します。
OWASP API Security Top 10とは
OWASP API Security Top 10は、OWASP（Open Web Application Security Project）がAPIセキュリティに関する10大リスクを選定・解説したもので、Webアプリケーション版『OWASP Top 10』同様、攻撃シナリオや防御方法がTop10形式で詳しく記載されており、API固有の脆弱性やセキュリティリスクの把握と対策をするための判断材料のひとつとして捉え、活用することができます。
「API」について、SQAT.jpでは以下の記事でも解説しています。
あわせてぜひご覧ください。
「APIのセキュリティ脅威とは」
「APIとは何か（2）～APIの脅威とリスク～」
APIセキュリティ
APIは異なるソフトウェア間の通信を可能にしますが、同時に攻撃者にとっての格好の標的にもなり得ます。そのため、APIを利用する企業やアプリケーション開発者にとってAPIのセキュリティ対策は重要な課題です。セキュリティリスクは他のプログラムやサービスと機能などデータを共有しているAPI特有の仕組みから生じます。APIが不適切に設計・管理されていると、未認証のアクセス、データ漏洩、機密情報の不正取得といったリスクが高まります。以下は、APIセキュリティに関する主なリスクの例です。
- データ漏洩：APIを通じて個人情報や機密情報が漏洩するリスク
- 不十分な認証：認証要素が不十分なことによる不正アクセスのリスク
- サイバー攻撃リスク：標的型攻撃、インジェクション攻撃やサービス運用妨害（DoS）攻撃などのサイバー攻撃を受けてしまうリスク
- APIキーの窃取：APIキーが盗まれることによる不正利用のリスク
OWASP API Security Top 10:2023概要
以下は、2023年に発表された最新版のOWASP API Security Top 10のリストです。
| 項目番号 | リスク名 | 概要 |
| API1:2023 | Broken Object Level Authorization （オブジェクトレベルでの認可の不備） | オブジェクトレベルの認可が不適切で、他ユーザのIDを参照できてしまう問題。IDを任意に変更して不正取得される |
| API2:2023 | Broken Authentication （認証の不備） | 認証トークンやセッション管理の不備により、なりすましや不正アクセスが可能となる状態 |
| API3:2023 | Broken Object Property Level Authorization （オブジェクトプロパティレベルの認可の不備） | オブジェクト内の個別プロパティに対して、参照・更新権限チェックがない問題。内部値が漏洩・改ざんされる恐れがある |
| API4:2023 | Unrestricted Resource Consumption （無制限のリソース消費） | CPU、ネットワーク、メール送信等リソース制御がなく、DoS攻撃対策やコスト対策が不十分な状態 |
| API5:2023 | Broken Function Level Authorization （機能レベルの認可の不備） | 本来の権限を超えて管理機能が呼び出され、削除・変更など不正操作が可能になる |
| API6:2023 | Unrestricted Access to Sensitive Business Flows （機密性の高いビジネスフローへの無制限のアクセス） | 購入や予約など、業務フローが制限なく自動化され悪用され得る状態。API側の防御が不十分な状態 |
| API7:2023 | Server Side Request Forgery （サーバサイドリクエストフォージェリ） | 外部から渡されたURLを検証せず内部リソースをリクエストし、不正アクセス・ポートスキャンを誘発する |
| API8:2023 | Security Misconfiguration （不適切なセキュリティ設定） | セキュリティ設定ミスにより、デバッグモードや不要エンドポイントが公開されたままになっている状態 |
| API9:2023 | Improper Inventory Management（不適切なインベントリ管理） | バージョン管理や資産管理不備により、古いAPIやテスト系エンドポイントが放置された状態 |
| API10:2023 | Unsafe Consumption of APIs (APIの安全でない使用) | APIクライアント側の不適切な利用により、API仕様外の動作等を招くケース |
OWASP API Security Top 10:2023の代表的なリスクとその影響
OWASP API Security Top 10では、APIに特化した攻撃手法や設計ミスを10項目に分類しています。ここでは特に影響の大きい代表的な5項目を取り上げ、それぞれの特徴と企業に与える影響を見ていきましょう。
API1: Broken Object Level Authorization
- 概要：他人のデータにアクセスできてしまう認可チェックの不備
- 例：/users/12345を/users/12346に変更して別ユーザの情報を取得
- 影響：個人情報漏洩、プライバシー侵害、法令違反リスク
- 実例：T-Mobile（2020年）でAPI経由により契約者情報が漏洩*1
API2: Broken Authentication
- 概要：認証トークンやセッション管理の不備により、なりすましが可能になる
- 例：署名検証のないJSON Webトークン、長期間有効なアクセストークン
- 影響：アカウント乗っ取り、セキュリティ境界の突破
- 実例：Facebook関連APIで、電話番号を使った認証回避により数億件の情報が漏洩（報道多数*2）
API3: Broken Object Property Level Authorization
- 概要：APIで受け取ったデータ内の個別プロパティに認可制御がされていない
- 例：JSONに”isAdmin”: trueを含めて送信し、権限昇格を実行
- 影響： 特権機能の乗っ取り、システム管理権限の不正取得
- 実例：Ruby on Railsなどで一括代入の脆弱性が過去に多発（Mass Assignment脆弱性*3）
API4: Unrestricted Resource Consumption
- 概要：API利用時のリソース消費に対する制限がなく、過剰利用を許してしまう
- 例：無制限にファイルをアップロード、高頻度でログイン試行
- 影響：DoS攻撃によるサービスの停止、インフラコストの急増
- 実例：なし
API6: Unrestricted Access to Sensitive Business Flows
- 概要：業務フロー（購入・予約など）へのアクセスが制限されておらず、不正自動化が可能
- 例：ボットによるチケット・人気商品の買い占め
- 影響：売上損失、不正転売、ユーザの機会喪失
- 実例：大手チケット販売サイトでの自動購入による買い占め被害（継続的に発生*4）
これらのリスクは、API開発における「利便性と安全性のバランス」が崩れたときに生じやすいものです。次章では、こうしたリスクに対して開発・運用チームがどのように備えるべきか、具体的な対策を解説します。
開発・運用チームがすべき対策
OWASP API Security Top 10:2023に示されたリスクは、設計・開発・運用のあらゆる段階での対策が必要です。APIは公開範囲が広く、攻撃対象になりやすいため、企業の情報システム部門や開発チームは「守るべきポイント」を明確にし、セキュリティレベルを高めていく必要があります。以下に代表的な対策を整理します。
認証・認可の適切な管理
- アクセストークン（OAuthトークンなど）の署名検証や有効期限管理を適切に行う
- 多要素認証（MFA）やOAuth 2.0／OpenID Connectなどの業界標準プロトコルを採用
- ユーザIDやオブジェクトIDに基づいたアクセス制御（認可）の一貫性を保つ
目的：適切なユーザにのみ権限を付与し、不正アクセスのリスクを軽減する
入力データのバリデーションと制御
- ユーザから受け取るリクエストパラメータ、JSON、ヘッダー情報などに対してサーバーサイドで厳格な検証を実施
- 過剰なフィールドの受け入れを避け、明示的に許可されたパラメータだけを処理
- 入力サイズ、データ型、構造の制限と、想定外の入力に対する例外処理を徹底
目的：不正な値による処理改ざん（Mass Assignment、インジェクション）やサービス停止リスクを軽減
脆弱性診断・ログ監視等の定期的な実施
- APIエンドポイントに対するセキュリティ診断（ペネトレーションテスト、動的解析）を定期的に実施
- SwaggerやOpenAPI仕様書をもとに、未公開API・テスト用APIが本番に露出していないか確認するため、棚卸しを実施
- APIゲートウェイやWAF（Web Application Firewall）と連携したログの収集・監視も強化
目的：潜在的な脆弱性や構成ミスを早期に発見し、攻撃の起点となる入口を閉じる
レート制限と自動化対策
- IPアドレスやユーザごとのレートリミットを設ける（例：1分間に○回まで）
- CAPTCHAやボット対策（Device Fingerprint等）を導入して業務APIの濫用を防止
- クラウド利用時はコスト制御のためのクォータ設定や自動アラートも重要
目的：DoS攻撃や不正自動化による買い占め行為の防止
セキュアなAPI設計の徹底
- 最小権限の原則に基づいたロール設計、バージョン管理の明確化
- 非公開APIは認証必須かつアクセス制限を設け、エラーメッセージは曖昧化
- API仕様書の公開範囲と利用契約（利用規約・SLAs）にもセキュリティ要件を記載
目的：開発段階からセキュリティを組み込む“Security by Design（セキュリティ・バイ・デザイン）”の実現
企業におけるAPI活用が進む今、セキュリティ対策もまたアプリケーションとは別軸で強化が求められます。OWASP API Security Top 10はその出発点であり、ここで挙げた対策はすべての開発・運用現場で必須です。継続的な見直しと体制整備によって、APIの安全な運用を実現しましょう。
第3回では、クラウドや自動化が進む今、ますます注目されている「Non-Human Identities（NHI）」に焦点を当てます。人ではないアカウントが引き起こす新たな課題とは何か、そして企業はどう備えるべきかを解説します。
―第3回「Non-Human Identities Top 10とは？自動化時代に求められる新しいセキュリティ視点」へ続く―
【連載一覧】
―第1回「OWASP Top 10とは？アプリケーションセキュリティの基本を押さえよう」―
―第3回「Non-Human Identities Top 10とは？自動化時代に求められる新しいセキュリティ視点」―
Security NEWS TOPに戻る
バックナンバー TOPに戻る
