API セキュリティのベスト プラクティス: 認証、認可、レート制限

API は、現代のビジネス プラットフォームの結合組織です。 ERP は API を通じて e コマース ストアと通信します。支払いゲートウェイは API を通じてトランザクションを処理します。モバイル アプリは API を通じてデータを取得します。そして、攻撃者はこれを知っています。Gartner は、2026 年までに、API が企業 Web アプリケーションに対する最も頻繁な攻撃ベクトルとなり、従来の Web インターフェイスを超えると予測しています。

OWASP API セキュリティ トップ 10 では、最も一般的な API 脆弱性は珍しいゼロデイではなく、基本的な認証の失敗、認証の破損、過度のデータ漏洩であることが明らかになりました。これらは、高度な攻撃ではなく、不適切なセキュリティ アーキテクチャに起因する予防可能な欠陥です。

重要なポイント

• PKCE を使用した OAuth2 が API 認証の現在の標準です。 API キーだけでは実稼働システムには不十分です
• オブジェクトレベル認証の破損 (BOLA) は API の最大の脆弱性です --- すべてのエンドポイントはリソースの所有権を確認する必要があります
• レート制限は、単なるパフォーマンスの最適化ではなく、セキュリティ制御です --- 資格情報のスタッフィング、列挙、および DoS を防止します。
• API 境界での入力検証により、インジェクション、オーバーフロー、ビジネス ロジック攻撃がデータベースに到達する前に防止されます。

---

認証: 身元の証明

認証は、「誰がこのリクエストを行っているのか?」という質問に答えます。 API の場合、答えは暗号的に検証可能であり、リプレイ攻撃に耐性があり、分散システム全体に拡張可能である必要があります。

認証方式の比較

OAuth2 と OIDC のベスト プラクティス

OpenID Connect (OIDC) を使用した OAuth2 は、最新のアプリケーションにおける API 認証の標準です。主な実装方法:

シングルページ アプリケーションやモバイル アプリケーションを含むすべてのクライアント タイプに対して、PKCE で認証コード フローを使用します。暗黙的フローは、ブラウザ履歴とリファラー ヘッダーでトークンが露出されるため、非推奨になりました。

有効期限の短いアクセス トークン。 アクセス トークンは 15 ～ 60 分で期限切れになります。リフレッシュ トークン (安全に保存され、使用時にローテーションされる) を使用して、再認証せずに新しいアクセス トークンを取得します。

トークン ストレージ。 トークンを localStorage または sessionStorage に保存しないでください (XSS に対して脆弱です)。 Secure および SameSite 属性を持つ HttpOnly Cookie を使用します。トークンを直接使用する必要がある SPA の場合は、トークンをメモリ内にのみ保持し、ページ更新時のセッション損失のトレードオフを受け入れます。

トークンを徹底的に検証します。 すべての API リクエストでは、トークンの署名、有効期限、発行者、対象者、スコープを検証する必要があります。 JWT を単にデコードしてその内容を信頼しないでください。

トークン バインド。 可能であれば、DPoP (Demonstating Proof-of-Possession) ヘッダーを使用してトークンを要求したクライアントにバインドし、トークンの盗難や再生を防ぎます。

JWT のセキュリティに関する考慮事項

JWT は API の最も一般的なトークン形式ですが、特定のリスクが伴います。

• none アルゴリズムは決して使用しないでください。 alg ヘッダーを、予期されるアルゴリズムのホワイトリストに対して常に検証してください。
• 公開 API では、対称アルゴリズム (HS256) よりも非対称アルゴリズム (RS256、ES256) を優先します。非対称キーを使用すると、署名キーを共有せずにトークンを検証できます。
• 標準クレームを含める: iss (発行者)、aud (対象者)、exp (有効期限)、iat (発行日)​​、sub (件名)、jti (失効用の一意の ID)。
• ペイロードを小さくしてください。 JWT はデータベースではありません。承認の決定に必要なクレームのみを含めます。必要に応じて、ユーザー情報エンドポイントから追加データを取得します。
• トークンの取り消しを実装します。 短い有効期限とトークン ブロックリスト (Redis などの) を組み合わせて使用​​し、アカウントが侵害された場合に即座に取り消します。

---

認可: アクセス制御の強制

認証により、誰がリクエストを行っているかがわかります。承認は、ユーザーが何を行うことが許可されているかを示します。 OWASP API トップ 10 では、オブジェクト レベル認証の破損 (BOLA) が API の脆弱性の第 1 位としてリストされています。これは、これが最も一般的であり、最も影響力が大きいためです。

RBAC vs ABAC

ロールベースのアクセス制御 (RBAC) は権限をロールに割り当て、ユーザーはロールに割り当てられます。実装も推論も簡単です。

属性ベースのアクセス制御 (ABAC) は、ユーザー、リソース、アクション、および環境の属性に対してポリシーを評価します。より複雑なルールをサポートしますが、監査は困難です。

ERP や e コマース システムを含むほとんどのビジネス プラットフォームでは、リソース所有権チェックと組み合わせれば、RBAC で十分です。認可ルールが時間、場所、データ分類、動的な組織階層などのコンテキスト要因に依存する場合は、ABAC を検討してください。

BOL の防止

オブジェクト レベルの認証の破損は、API によってユーザーがリソース識別子を操作して他のユーザーに属するリソースにアクセスしたり、リソースを変更したりできるようになった場合に発生します。たとえば、/api/orders/12345 を /api/orders/12346 に変更しても、別のユーザーの注文が明らかになりません。

予防ルール:

1. すべてのエンドポイントはリソースの所有権を確認する必要があります。 認証のみに依存しないでください。ユーザーの身元を確認した後、要求されている特定のリソースにアクセスできることを確認します。
2. 間接参照を使用します。 連続したデータベース ID を公開する代わりに、UUID またはユーザー スコープの参照番号を使用します。
3. データ層で強制します。 コントローラー レベルだけでなく、すべてのデータベース クエリに所有権フィルター (WHERE organization_id = ? など) を追加します。これは、ECOSIRE のプラットフォーム アーキテクチャ 全体で使用されるマルチテナント パターンです。
4. 自動テスト。 CI/CD パイプラインに認証バイパス テストを含めます。各エンドポイントについて、ユーザー A がユーザー B のリソースにアクセスできないことをテストします。

---

レート制限とスロットリング

レート制限は、過負荷を防ぐパフォーマンスの最適化だけでなく、悪用を防ぐセキュリティ制御です。レート制限がなければ、攻撃者は 1 秒あたり数千回の試行で認証情報スタッフィングを実行したり、有効なアカウントを列挙したり、製品カタログ全体をスクレイピングしたり、上流プロバイダーの API クォータを使い果たすことができます。

レート制限戦略

エンドポイント タイプによるレート制限

エンドポイントが異なれば、脅威プロファイルも異なり、必要な制限も異なります。

• 認証エンドポイント (ログイン、トークン交換): IP ごとに 1 分あたり 5 ～ 10 リクエスト。制限を低く設定すると、資格情報のスタッフィングやブルート フォースが防止されます。
• パスワード リセット/アカウント回復: アカウントごとに 1 時間あたり 3 ～ 5 件のリクエスト。アカウントの列挙と悪用を防ぎます。
• データ読み取りエンドポイント: ユーザーあたり 1 分あたり 100 ～ 1000 リクエスト。通常の使用を可能にしながら、削れを防ぎます。
• データ書き込みエンドポイント: ユーザーあたり 1 分あたり 30 ～ 60 リクエスト。自動化された不正行為やスパムを防止します。
• パブリック検索エンドポイント: IP ごとに 1 分あたり 20 ～ 60 リクエスト。競合によるスクレイピングを防ぎます。
• Webhook レシーバー: レート制限ではなく署名を検証しますが、予想される量を超えるリクエストはドロップします。

レート制限の実装

クライアントが自己規制できるように、適切な HTTP ステータス コードとヘッダーを返します。

• 429 リクエストが多すぎます 制限を超えた場合
• 制限がリセットされるまでの秒数を含む Retry-After ヘッダー
• 許可されたリクエストの合計を示す X-RateLimit-Limit ヘッダー
• ウィンドウ内に残っているリクエストを示す X-RateLimit-Remaining ヘッダー
• X-RateLimit-Reset ヘッダーとウィンドウのリセット時の UTC タイムスタンプ

インスタンスごとの制限ではなく、一元化されたレート制限サービス (Redis ベース) を使用して、攻撃者が制限をバイパスするためにリクエストをインスタンス間で分散するのを防ぎます。

---

入力の検証

API 境界での入力検証は、インジェクション攻撃、バッファ オーバーフロー、ビジネス ロジックの悪用に対する防御の第一線です。 API に入力されるすべてのデータは、タイプ、形式、長さ、範囲、ビジネス ルールについて検証される必要があります。

OWASP API セキュリティ トップ 10

OWASP API セキュリティ トップ 10 (2023 年版) では、すべての API が対処する必要がある重大なリスクが特定されています。

検証のベストプラクティス

スキーマの検証。 リクエスト スキーマを定義し (JSON スキーマ、Zod、または OpenAPI 仕様を使用)、準拠しないリクエストを拒否します。これにより、不正なデータがビジネス ロジックに到達する前に捕捉されます。

パラメータ化されたクエリ。 ユーザー入力を SQL、NoSQL、または LDAP クエリに決して連結しないでください。エスケープを自動的に処理するパラメータ化されたクエリまたは ORM メソッドを使用します。これは、すべてのビジネス プラットフォームに対する 重要なセキュリティ ルール です。

コンテンツ タイプの強制。 予期される Content-Type ヘッダーのみを受け入れます。 JSON を想定する API は、パーサーベースの攻撃を防ぐために、XML、フォーム データ、およびその他のコンテンツ タイプを拒否する必要があります。

応答フィルタリング 完全なデータベース レコードをクライアントに返さないでください。 DTO (データ転送オブジェクト) を使用して、各応答にどのフィールドが含まれるかを明示的に定義します。パスワード ハッシュ、内部 ID、監査メタデータなどの内部フィールドは、API 応答に決して表示されるべきではありません。

エラー処理 一般的なエラー メッセージをクライアントに返します。スタック トレース、データベース エラー、内部システムの詳細を決して公開しないでください。デバッグのためにサーバー側で詳細なエラーをログに記録します。

---

API セキュリティ アーキテクチャ パターン

API ゲートウェイ パターン

API ゲートウェイはすべてのバックエンド サービスの前に配置され、横断的なセキュリティの問題を一元管理します。

• 認証 --- リクエストがバックエンド サービスに到達する前にトークンを検証します。
• レート制限 --- ゲートウェイ レベルで制限を適用します
• リクエスト/レスポンス変換 --- 機密ヘッダーを削除し、セキュリティ ヘッダーを追加します
• ログとモニタリング --- セキュリティ分析のためにすべての API トラフィックをキャプチャします
• WAF 統合 --- 既知の攻撃パターン (SQL インジェクション、XSS ペイロード) をブロックします。

一般的な API ゲートウェイには、Kong、AWS API Gateway、Azure API Management、Traefik などがあります。

サービス間認証

マイクロサービス間の内部 API にも認証が必要です。オプションには次のものが含まれます。

• 相互 TLS (mTLS) --- クライアントとサーバーの両方が証明書を提示します。強力ですが、操作が複雑です。
• サービス トークン --- サービスは事前共有トークンを使用して認証します。シンプルですが安全な配布が必要です。
• サービス メッシュ --- Istio または Linkerd は、Kubernetes のサービス間で mTLS を自動的に処理します。
• OAuth2 クライアント認証情報 --- サービスはクライアント ID とシークレットを使用して認証を行い、アクセス トークンを取得します。

ゼロトラスト アーキテクチャ の場合、侵害後の横方向の移動を防ぐためにサービス間認証が不可欠です。

---

監視とインシデント検出

API セキュリティ監視では、技術的なシグナル (認証試行の失敗、異常なリクエスト パターン) とビジネス シグナル (異常なトランザクション量、大量のデータ アクセス) の両方をキャプチャする必要があります。

API セキュリティに関する重要な信号

• 認証の失敗 --- 単一の IP または単一のアカウントをターゲットとしたログイン失敗の急増
• 認証失敗 --- ユーザーが未承認のリソースにアクセスしようとしていることを示す 403 応答
• レート制限違反 --- 同じソースからの継続的な 429 件の応答
• 異常なデータ量 --- データの漏洩を示唆する一括読み取り操作
• パラメータの改ざん --- 連続した ID の列挙、負の値、境界テスト
• 地理的異常 --- 予期しない地域または不可能な旅行パターンからの API 呼び出し

これらのシグナルをリアルタイムで明らかにするダッシュボードを構築します。他のセキュリティ イベントと相関付けるために SIEM と統合します。信頼性の高い脅威に対する自動応答を定義します。失敗した認証しきい値を超える IP をブロックし、不可能な移動を示すアカウントを一時的に無効にし、大量のデータ アクセス パターンについて警告します。

---

よくある質問

API キーと OAuth2 トークンのどちらを使用する必要がありますか?

ユーザー向けアプリケーションまたはサードパーティ統合を提供する API には OAuth2 トークンを使用します。 API キーは、両方のエンドポイントが制御下にあるサーバー間通信でのみ受け入れられますが、その場合でも、HMAC 署名付きリクエストにより強力なセキュリティが提供されます。パブリックにアクセスできるエンドポイントの唯一の認証として API キーを使用しないでください。

API のバージョン管理を安全に処理するにはどうすればよいですか?

明確さと見つけやすさのために、URL ベースのバージョン管理 (/api/v2/orders など) を使用します。バージョンを非推奨にする場合は、廃止日を設定し、消費者に通知し、使用状況を監視します。非推奨バージョンが完全に廃止されるまで、セキュリティ パッチを適用し続けます。パッチを適用していない古い API バージョンを実行したままにしないでください。これらは簡単なターゲットになります。

ビジネス API にはどのようなレート制限を設定する必要がありますか?

控えめに始めて、正当な使用状況データに基づいて増やしてください。認証エンドポイントの場合、IP ごとに 1 分あたり 5 ～ 10 リクエストが標準です。データ エンドポイントの場合、認証されたユーザーあたり 1 分あたり 100 ～ 500 リクエストで、ほとんどのビジネス ユース ケースをカバーできます。 429 の応答を監視して制限が厳しすぎる制限を特定し、乱用パターンを監視して制限が寛大すぎることを特定します。

サードパーティのサービスから Webhook を保護するにはどうすればよいですか?

HMAC-SHA256 と共有シークレットを使用して Webhook 署名を検証します。タイムスタンプを検証してリプレイ攻撃を防止します (5 分より古いイベントを拒否します)。 Webhook を非同期的に処理して、タイムアウトによるサービス拒否を防ぎます。監査目的ですべての Webhook イベントをログに記録します。処理前にペイロード スキーマを検証します。

---

次は何ですか

API セキュリティは、開発の最後に追加する機能ではありません。最初のエンドポイントから存在する必要がある設計原則です。強力な認証 (OAuth2/OIDC) から始めて、すべてのリソース アクセス ポイントで認可を強制し、すべてのエンドポイント タイプにわたってレート制限を実装し、API 境界を越えるすべての入力を検証します。

ECOSIRE は、あらゆる API 統合にセキュリティを組み込みます。当社の OpenClaw AI プラットフォーム は、HMAC 署名付きリクエスト、レート制限、SSRF 保護をデフォルトで実装していますが、Odoo ERP 統合 はロールベースのアクセス制御を備えた OAuth2/OIDC を使用します。ビジネス プラットフォーム API を保護するには、チームにお問い合わせください。

---

ECOSIRE によって発行 --- Odoo ERP、Shopify eCommerce、OpenClaw AI にわたる AI を活用したソリューションで企業のスケールアップを支援します。