Cover image for Building Secure APIs in 2026: Threats Developers Can't Ignore

Eva Clari

今や、どのプロダクトチームもUIをリリースする前にAPIをリリースしています。モバイルアプリ、パートナー連携、内部マイクロサービス、そしてシステムに接続するAIエージェントはすべて、同じエンドポイント群を通じて通信しています。このトラフィックの集中により、APIレイヤーはスタックの中で最も魅力的な標的となっており、攻撃者もそれを知っています。Verizonの2025年データ侵害調査レポートでは、WebアプリケーションおよびAPI攻撃が確認された侵害の主な要因の上位に挙げられており、トラフィックはブラウザセッションから、マシン間呼び出しへと移行していますが、多くのセキュリティチームは依然としてユーザーログインほど厳密に監視していません。

破損したオブジェクトレベル認可が依然としてほとんどのAPIを破壊する

OWASPは、破損したオブジェクトレベル認可をAPI Security Top 10のAPI1にランク付けしており、実世界のインシデントの原因として依然として他のAPI脆弱性よりも多く発生しています。パターンはシンプルで、チームはそれをリリースし続けています。たとえば/api/orders/12345のようなエンドポイントでは、呼び出し元を正しく認証しますが、その呼び出し元が実際にorder 12345を所有しているかどうかを確認しません。IDを入れ替えるだけで、他人のデータを読み取ったり変更したりできます。

これを修正するには、エンドポイントレベルではなくオブジェクトレベルで行います。IDでリソースにアクセスするすべてのハンドラは、データが返される前に明示的な所有権または権限チェックを行う必要があります。単にドアで有効なセッショントークンを確認するだけでは不十分です。このチェックを共有の認可ライブラリやポリシーエンジンに集中させ、個々の開発者が締め切りのプレッシャーの中で忘れることがないようにします。機能テストと同じように、APIテストスイートに対して自動化された認可ファジングを実行します。PostmanのState of the API Reportでは、認可テストがAPI開発ワークフローで最もスキップされやすいステップの1つとして数年連続で指摘されており、BOLAがバグバウンティレポートに頻出するのは、チームが依然として認証と認可を同じ問題として扱っているためです。

LLM対応APIがもたらす新たな脅威クラス

言語モデルをラップまたはフロントエンドとするAPIは、標準的なREST APIにはないリスクを伴います。OWASP LLM Applications Top 10では、プロンプトインジェクション、過剰なエージェンシー、不適切な出力処理が主要なリスクとして挙げられており、これら3つはいずれもチャットウィジェットだけでなく、APIレイヤーを通じて直接表面化します。

ユーザーまたは上流システムが影響を与えられるすべてのフィールドを、モデルに対する信頼できない入力として扱い、すべてのモデル出力を下流システムに対する信頼できない入力として扱います。モデル応答が、検証を挟まずにデータベース書き込み、ファイル操作、または別の内部API呼び出しをトリガーしないようにします。APIを通じてファンクションコールやツール利用を公開する場合は、各ツールのスコープを狭くし、モデルに内部エンドポイントへの広範なアクセスを許可するのではなく、明示的な許可リストを要求します。リクエスト数だけでなく、トークンコストや呼び出しがトリガーし得る下流アクションのコストに基づいてレート制限を行いましょう。1つのプロンプトが数十の内部呼び出しに波及する可能性があるためです。AIエージェントがAPIを自律的に呼び出す場合は、共有サービスアカウントではなく、各エージェントに独自の短命で狭いスコープの認証情報を発行します。共有認証情報は、1つのエージェントが侵害された場合に、それを利用するすべてのエージェントに完全なアクセスを提供することになります。

ゲートウェイでのZero Trust適用

境界ベースのセキュリティは、信頼された内部ネットワークを前提としていますが、サービスが複数のクラウド、サードパーティ連携、完全に制御できないスケジュールで呼び出しを行うAIエージェントにまたがるようになった今、その前提は崩れています。Zero Trustは、すべてのリクエストを証明が得られるまで信頼せず、APIゲートウェイで一貫してポリシーを適用します。各サービスに個別に正しく実装させるのではなく。

サービス間に相互TLSを導入し、呼び出し元がサーバーを認証するだけでなく、双方が接続を認証するようにします。長期間有効なAPIキーで広範なアクセスを数ヶ月間許可するのではなく、狭いスコープを持つ短命のOAuth 2.0トークンを発行します。スコープを具体的なアクション（orders:read、orders:write）に定義し、リソースレベルの広範なアクセスではなく、侵害されたトークンの影響範囲を限定します。IPアドレスではなくクライアントIDごとにゲートウェイでレート制限とクォータポリシーを適用します。IPベースの制限は分散トラフィックやインフラを共有する正当なマルチテナントクライアントに対しては機能しないためです。Gartnerは、APIトラフィックがほとんどの企業環境で従来のWebトラフィックを上回るようになったことを組織が認識するにつれ、APIセキュリティツールおよびAPIゲートウェイへの支出が継続的に増加すると予測しており、ゲートウェイレベルのポリシー適用は、すべてのサービスを書き換えることなくZero Trustを適用する実践的な方法です。

シークレット管理と認証情報の衛生管理

ソースリポジトリにハードコードされたAPIキーやデータベース認証情報は、API侵害の最も一般的かつ最も防ぎやすい原因の1つです。GitHubのシークレットスキャンプログラムは、パブリックリポジトリ全体で数百万件の露出した認証情報を検出しており、そのうちの相当数が、プッシュする前に削除するつもりだった開発者によってコミットされた本番用APIキーに該当します。

シークレットは専用のVault（HashiCorp Vault、AWS Secrets Manager、またはクラウドプロバイダーの同等サービス）に保存し、バージョン管理にチェックインされた設定ファイルや環境変数にハードコードするのではなく、実行時にアプリケーションに取り込みます。APIキーや署名用シークレットは固定スケジュールでローテーションし、アクセス権を持つチームメンバーが退職した場合や、露出の可能性を示唆するインシデントが発生した場合は直ちにローテーションします。アーキテクチャ上可能な限り、長期間有効な静的キーではなく、短命の署名付きトークンを優先します。数分で期限切れになる漏洩したトークンは、無期限に有効なキーよりもはるかに被害が少ないためです。CIパイプラインに自動シークレットスキャンを追加し、コミットされた認証情報が本番で誰かが気づくのを待つのではなく、マージをブロックするようにします。

エンジニアリングチームが直面する状況

これらの脅威は概念として新しいものではありません。変わったのはサーフェスエリアです。内部マイクロサービス、パートナー連携、製品が依存するAIエージェントのいずれも、攻撃者が探査できるエンドポイントのセットを追加します。また、破損した認可や漏洩した認証情報を見つけるために攻撃者が使用するツールは、ほとんどのチームのパッチサイクルよりも速くなっています。APIセキュリティを、最初のエンドポイントを書く時点からの設計制約として扱い、リリース前に実行するチェックリストとして扱わず、機能テストと同じように認可テストとシークレット衛生の習慣を築きましょう。

個々の開発者が場当たり的に身につけるのではなく、組織全体でこれらの習慣を構築するための構造化された方法を求めるチームは、専用のITセキュリティトレーニングを検討すべきです。