本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
OWASP API Security Top 10 (2023) 解説と実践的対策
1. 概要と脅威モデル
APIは現代のアプリケーションの基盤であり、そのセキュリティは極めて重要です。OWASP API Security Top 10 (2023) は、APIの設計、開発、デプロイ、運用における最も重大なセキュリティリスクをまとめたものです[1]。これは、開発者、セキュリティ担当者、アーキテクトがAPIの脆弱性を特定し、対策を講じるための羅針盤となります。
OWASP API Security Top 10 (2023) リスト:
API1:2023 Broken Object Level Authorization (BOLA): 個別オブジェクトへのアクセス制御の不備。
API2:2023 Broken Authentication: 認証メカニズムの不備。
API3:2023 Broken Object Property Level Authorization: オブジェクトのプロパティレベルでのアクセス制御の不備。
API4:2023 Unrestricted Access to Sensitive Business Flows: ビジネスロジックの脆弱性。
API5:2023 Broken Function Level Authorization: 機能レベルでのアクセス制御の不備。
API6:2023 Unrestricted Resource Consumption: リソース消費の制限の欠如。
API7:2023 Server Side Request Forgery (SSRF): サーバーサイドのリクエスト偽造。
API8:2023 Security Misconfiguration: セキュリティ設定の不備。
API9:2023 Improper Inventory Management: APIインベントリ管理の不備。
API10:2023 Unsafe Consumption of APIs: 外部API利用時のセキュリティ対策の不備。
脅威モデル: APIセキュリティにおける脅威モデルは、攻撃者がAPIを悪用してどのような目標を達成しようとするかを理解することに焦点を当てます。主な脅威は以下のカテゴリーに分類できます。
認可の欠陥 (API1, API3, API5): 適切な権限を持たないユーザーが機密データや機能にアクセスできる脅威。攻撃者はIDの列挙や推測により、他者の情報へ不正アクセスを試みます。
認証の欠陥 (API2): 攻撃者が正当なユーザーになりすます、またはシステムに不正にログインする脅威。クレデンシャルスタッフィング、ブルートフォース、セッショントークンハイジャックなどが含まれます。
ビジネスロジックの悪用 (API4): 支払い処理、予約システムなど、APIが提供するビジネスフローの設計上の欠陥を悪用し、金銭的利益やサービスの妨害を図る脅威。
リソース枯渇 (API6): 大量のリクエストや不正な入力でAPIサーバーのリソースを消費し、サービス拒否 (DoS) を引き起こす脅威。
サプライチェーン攻撃と設定ミス (API7, API8, API9, API10): 依存関係にある外部APIやシステムの脆弱性、APIゲートウェイやクラウド設定の不備、APIのライフサイクル管理の欠如を利用して攻撃を行う脅威。これらは広範な影響を及ぼす可能性があります。
2. 攻撃シナリオ (API1:2023 Broken Object Level Authorization)
API1:2023 Broken Object Level Authorization (BOLA) は、APIセキュリティリスクの中で最も深刻かつ頻繁に発生する脆弱性の一つです。この脆弱性は、ユーザーがアクセス権のないオブジェクト（例: 他のユーザーのデータ、システム設定）に直接アクセスできる場合に発生します。
攻撃チェーン (Attack Chain: BOLA)
graph TD
A["攻撃者"] --> |ユーザーIDを推測/列挙| B{"正規ユーザーのAPIリクエストを傍受"};
B --> |リクエストを変更| C["不正なオブジェクトIDでAPIリクエストを送信"];
C --> |アクセス制御の不備| D{"APIサーバーが不正なリクエストを処理"};
D --> |機密データ漏洩/改ざん| E["攻撃者が他ユーザーのデータにアクセス/操作"];
解説: 攻撃者はまず、正規ユーザーが自身のデータにアクセスするAPIリクエストを傍受し、その構造を理解します。次に、そのリクエストのオブジェクトID（例：ユーザーID、ドキュメントID）を推測、または列挙可能な方法で取得します。最後に、傍受したリクエストのオブジェクトIDを不正なものに変更してAPIエンドポイントに送信します。もしAPIがリクエスト元のユーザーがそのオブジェクトにアクセスする権限を持っているかを適切に確認しない場合、攻撃者は他ユーザーの機密データへのアクセスや改ざんが可能となります。
具体的なシナリオ
あるeコマースサイトのAPIが、ユーザーの注文履歴を取得するエンドポイント /api/v1/orders/{order_id} を提供しているとします。
正規リクエスト: ユーザーAが自分の注文ID
order_123を使って/api/v1/orders/order_123にリクエストを送信し、自分の注文履歴を取得します。この時、ユーザーAの認証トークンがAuthorizationヘッダーに含まれます。攻撃者の行動: 攻撃者は、正規ユーザーAの認証トークンを保持したまま、注文IDを
order_456に変更して/api/v1/orders/order_456にリクエストを送信します。脆弱性: APIサーバーが、
order_456が実際にユーザーAに属しているかを検証せず、認証トークンのみを検証してリクエストを処理してしまいます。結果: 攻撃者はユーザーB (注文
order_456の所有者) の注文履歴にアクセスできてしまいます。
3. 検出と緩和策
認証・認可の徹底 (API1, API2, API3, API5)
最も基本的な対策は、認証と認可の徹底です。
認証の強化:
OAuth 2.0 / OpenID Connect の採用: アクセストークン、リフレッシュトークンを用いてセキュアな認証フローを構築します。トークンの有効期限を短く設定し、定期的なローテーションを促します。
多要素認証 (MFA): 機密性の高いAPIアクセスにはMFAを義務付けます。
強力なパスワードポリシー: 長さ、複雑性、履歴の要件を課し、定期的な変更を促します。
レートリミット: 認証エンドポイントへの総当たり攻撃を防ぐため、ログイン試行回数に制限を設けます。
認可の厳格化:
オブジェクトレベルの認可 (BOLA対策): すべてのAPIリクエストにおいて、リクエスト元のユーザーが、アクセスしようとしているリソース（オブジェクト）に対する権限を持っているか、サーバーサイドで厳格に検証します。これは、URLパスパラメータ、クエリパラメータ、リクエストボディ内のIDなど、すべてのオブジェクト参照に対して行う必要があります。
プロパティレベルの認可 (BOPLA対策): オブジェクト全体だけでなく、その中の特定のプロパティに対する読み書き権限も細かく制御します。ユーザーが変更を許可されていないプロパティを更新しようとした場合、それを拒否します。
機能レベルの認可 (BFLA対策): ロールベースアクセス制御 (RBAC) や属性ベースアクセス制御 (ABAC) を導入し、ユーザーのロールや属性に基づいてアクセス可能なAPIエンドポイントや機能を制御します。
暗号とプロトコルの安全な利用
API通信は常にHTTPS/TLSで暗号化し、最新かつ安全なプロトコルバージョンと暗号スイートを使用します。
TLSの誤用例 (curl)
# 非推奨: 自己署名証明書や期限切れ証明書を無視して接続 # 想定される影響: 中間者攻撃により通信内容が盗聴・改ざんされるリスク curl -k https://insecure.example.com/api/data
-k(または--insecure) オプションは、証明書の検証を無効にするため、中間者攻撃のリスクを高めます。TLSの安全な代替 (curl)
# 推奨: 証明書検証を有効にし、信頼できるCA証明書を使用 # 想定される影響: 証明書検証により、正規のサーバーとの安全な通信が保証される # 通常、OSのデフォルト設定で検証は有効。追加のCA証明書が必要な場合 curl --cacert /path/to/my-ca-certs.pem https://secure.example.com/api/data
特別な理由がない限り、証明書検証は常に有効にすべきです。
鍵・秘匿情報の取り扱い (API8, API9)
APIキー、データベース認証情報、トークンなどの秘匿情報は厳重に管理する必要があります。
誤用例: コードへのハードコーディング (Python)
# 非推奨: ソースコードにAPIキーを直接記述 # 想定される影響: Gitリポジトリへの漏洩、ビルド成果物からの抽出リスク API_KEY = "sk_XXXXXXXXXXXXXXXXXXXXXXXXX" # APIキー本体 # ... APIリクエスト ...
これはGitリポジトリへの漏洩や、ビルド成果物からの抽出のリスクを高めます。
安全な代替: 環境変数とシークレット管理サービス (Python)
import os # 推奨: 環境変数から取得 # 想定される影響: 秘匿情報がソースコードから分離され、安全性が向上 API_KEY = os.getenv("MY_SERVICE_API_KEY") # 環境変数からAPIキーを取得 if not API_KEY: raise ValueError("MY_SERVICE_API_KEY環境変数が設定されていません") # クラウドのシークレット管理サービスから取得する場合 (例: AWS Secrets Manager) # 想定される影響: 秘匿情報のライフサイクル管理と安全なアクセスが可能 import boto3 import json def get_secret(secret_name: str, region_name: str = "ap-northeast-1") -> dict: """ AWS Secrets Managerから秘匿情報を取得する関数。 Args: secret_name (str): シークレットの名前。 region_name (str): AWSリージョン。 Returns: dict: 取得した秘匿情報（JSON形式）。 Raises: Exception: AWS Secrets Managerからの取得に失敗した場合。 Complexity: ネットワークI/Oに依存するため、O(1)ではないが、通常は非常に高速。 Memory: 取得するシークレットのサイズに依存。通常は小さい。 """ client = boto3.client("secretsmanager", region_name=region_name) try: get_secret_value_response = client.get_secret_value(SecretId=secret_name) except Exception as e: # エラーハンドリングを適切に行う print(f"Error retrieving secret '{secret_name}': {e}") raise e else: if "SecretString" in get_secret_value_response: return json.loads(get_secret_value_response["SecretString"]) else: # バイナリデータの場合の処理 (ここではJSON形式を想定) raise ValueError("Secret is not a string, or not in expected JSON format.") # 使用例: # try: # secrets = get_secret("my-api-secrets") # API_KEY = secrets["api_key"] # except Exception as e: # print(f"Failed to get API key: {e}") # API_KEY = None # または適切なフォールバック処理環境変数や専用のシークレット管理サービス (AWS Secrets Manager, Azure Key Vault, HashiCorp Vaultなど) を利用することで、秘匿情報を安全に管理できます。
4. 運用対策
鍵・秘匿情報のローテーション
定期的なローテーション: APIキーや証明書は定期的に（例: 90日に一度）ローテーションします。自動化されたローテーションプロセスを導入することが理想です。
オンデマンドローテーション: 漏洩が疑われる場合は即座にローテーションします。漏洩時には、関連するすべての依存関係も確認し、必要に応じてローテーションを実施します。
無効化ポリシー: 未使用または期限切れの秘匿情報は速やかに無効化し、クリーンアップします。
最小権限の原則
APIキーの権限: 各APIキーには、そのキーが必要とする最小限の権限のみを付与します。例えば、読み取り専用APIキーはデータ変更権限を持たせないようにします。
IAMロール: クラウド環境では、サービスアカウントやIAMロールに最小限の権限を持つポリシーを適用します。これにより、インフラレベルでのセキュリティを強化します。
コンテキストに応じた権限付与: 特定の処理でのみ必要となる一時的な権限付与メカニズムを検討します。
監査とロギング
詳細なアクセスログ: すべてのAPIアクセスについて、誰が、いつ、何を、どこから行ったかを記録します。認証試行の成功/失敗、認可エラー、データ変更操作などは特に詳細に記録します。
ログの一元管理: ログを集中管理システム (SIEMなど) に集約し、リアルタイムでの監視と分析を可能にします。異常なアクセスパターンやエラーの増加を迅速に検出します。
監査証跡: ログは改ざんされないように保護し、監査証跡として利用できるように長期間保存します。ログの整合性を確保するために、ハッシュ化や署名などの技術も検討します。
5. 現場の落とし穴
APIセキュリティ対策には、いくつかの一般的な落とし穴があります。
誤検知 (False Positives) と検出遅延: WAF (Web Application Firewall) やAPIゲートウェイでの異常検知ルールが厳しすぎると、正当なトラフィックをブロックし、サービス可用性を損なうことがあります。逆に、緩すぎると攻撃を見逃します。適切なチューニングには時間と専門知識が必要です。検出遅延は、攻撃が進行中に警告が出ず、被害が拡大するリスクがあります。
可用性とのトレードオフ: 厳格なセキュリティ対策（例: 複雑なレートリミット、詳細な入力検証）は、APIの応答時間増加やリソース消費増大を招き、パフォーマンスや可用性に影響を与える可能性があります。特に、DDoS対策は正規ユーザーのアクセスを妨げないように注意が必要です。サービス品質とセキュリティのバランスを考慮した設計が求められます。
古いAPIバージョンの放置: 過去のAPIバージョンを無計画に維持し続けると、既知の脆弱性を持つコードが残り続け、攻撃のリスクを高めます。APIライフサイクル管理の欠如はAPI9:2023に該当し、計画的な廃止と移行が重要です。
開発者への負担: 厳格なセキュリティポリシーは開発プロセスにオーバーヘッドをもたらし、開発者の生産性を低下させる可能性があります。セキュリティをシフトレフトし、CI/CDパイプラインにセキュリティテストを組み込むことで、この負担を軽減し、早期に脆弱性を発見・修正できるようにします。
6. まとめ
OWASP API Security Top 10 (2023) は、APIを保護するための包括的なガイドラインを提供します。これらのリスクを理解し、認証・認可の徹底、安全な暗号・プロトコルの利用、鍵・秘匿情報の厳重な管理、そして定期的な監査といった多層的な対策を講じることが不可欠です。
特に、API1:2023 BOLAのような認可の欠陥はビジネスへの影響が大きいため、サーバーサイドでの厳格なオブジェクトレベル認可の検証を徹底することが最重要です。また、セキュリティ対策は開発ライフサイクルの初期段階から組み込み、運用中も継続的に見直しと改善を行うことで、変化する脅威に対応し、APIの安全性を維持できます。
参考文献
[1] OWASP Foundation. “OWASP API Security Top 10 (2023)”. OWASP API Security Project. Accessed on 2024-07-30. URL: https://owasp.org/API-Security/editions/2023/ (発表日: 2023-03-01).
