Vercel 2026年セキュリティ侵害から学ぶAPIセキュリティ7つの教訓

要約

2026年4月19日、Vercelは、攻撃者がサードパーティ製AIツールのOAuth連携を介して社内システムを侵害し、保存時に暗号化されていなかった顧客の環境変数が漏洩したことを公表しました。この侵害は、すべてのAPI開発者が適用すべき7つの重要な教訓を明らかにしています。それは、保存時のシークレット暗号化（転送時だけでなく）、AI開発ツールからのOAuth許可の監査、すべての環境変数をデフォルトで機密として扱うこと、認証情報の自動ローテーション、CI/CDパイプラインの保護、セキュリティがデフォルトで有効なAPIの構築、そしてインシデント対応プレイブックを必要になる前に準備することです。

button

はじめに

Context.aiという小さなAIツールへの単一のOAuth許可が、攻撃者にVercelの内部システムへの直接的な経路を与えました。そこから攻撃者は、保存時に暗号化されていなかった顧客の環境変数、APIキー、データベース認証情報、デプロイメントトークンにアクセスしました。

この侵害は、Vercelがファイアウォールを欠いていたからでも、HTTPSを有効にするのを忘れていたからでもありません。それは、開発者がシークレットを「機密」として手動でオプトインするだろう、サードパーティのAI統合は低リスクである、そして生産性向上ツールに付与されたOAuthスコープは定期的な監査を必要としない、というアーキテクチャ上の仮定が原因で発生しました。

APIを構築または利用する開発者にとって、このインシデントは分析に値するケーススタディです。攻撃チェーンは、ほとんどの開発チームが日常的に繰り返すパターンを悪用しました。具体的には、環境変数に認証情報を保存すること、AIツールにOAuthアクセスを許可すること、そして機密データを保護するためにプラットフォームのデフォルト設定を信頼することです。

このガイドでは、Vercelの侵害から得られた7つの教訓を分析し、今週からすぐに実践できる具体的なステップとともに、それらを自身のAPIワークフローに適用する方法を示します。

何が起こったのか：2026年4月のVercel侵害

攻撃チェーン

2026年4月17日から19日の間に、攻撃者はContext.aiのGoogle Workspace OAuthアプリケーションを侵害しました。Context.aiはAIオブザーバビリティツールであり、主要なIDプロバイダではなく、小規模なプレイヤーです。しかし、Vercel従業員のGoogle WorkspaceアカウントへのOAuthアクセス権を持っていました。

攻撃チェーンの展開は次の通りです。

1. 攻撃者がContext.aiのOAuthアプリを侵害し、そのGoogle Workspace統合を制御下に置く
2. そのOAuthアクセスを利用してVercel従業員のGoogleアカウントを乗っ取り、その従業員が持っていたあらゆる権限を継承する
3. Vercelの内部システムに侵入し、顧客向けのデータストアにアクセスする
4. 顧客が「機密」とマークしていなかった環境変数を抽出する。これらは保存時に暗号化されていなかった

Vercelは、攻撃者について「その運用速度とVercelのシステムに対する詳細な理解から、非常に高度な手口を使っていた」と説明しました。

漏洩した情報

侵害が確認されたもの：

• 「機密」とマークされていない顧客の環境変数（APIキー、データベースURL、署名キー、デプロイメントトークン）
• 580件の従業員記録（氏名、Vercelメールアドレス、アカウントステータス、アクティビティのタイムスタンプ）

侵害されなかったもの（Vercelによる）：

• 「機密」とマークされた環境変数（保存時に暗号化済み）
• コアプラットフォームインフラストラクチャ

重要な設計上の詳細：Vercelの環境変数に対する「機密」フラグはデフォルトでオフでした。シークレットは、開発者が明示的にオプトインした場合のみ保存時に暗号化されます。このオプトインモデルは、開発者コミュニティから大きな批判を浴びました。

なぜこれがAPI開発者にとって重要なのか

あなたが構築または利用するすべてのAPIは、APIキー、OAuthトークン、データベース認証情報、Webhook署名キーといったシークレットに依存しています。Vercelの侵害はAPIを直接標的としたものではありませんでした。API認証情報が存在するインフラストラクチャが標的となりました。そして、そのインフラストラクチャはあなたのものと共通しています。すなわち、環境変数、OAuth統合、CI/CDパイプライン、そしてサードパーティツールです。

教訓1：転送時だけでなく、保存時にもシークレットを暗号化する

HTTPSは転送中のAPIキーを保護します。しかし、それらのキーがデプロイメントプラットフォーム上の環境変数に置かれている場合はどうでしょうか？Vercelの場合、「機密ではない」環境変数は保存時に暗号化されずに保管されていました。攻撃者はネットワークトラフィックを傍受する必要はなく、ストレージから直接認証情報を読み取りました。

すべきこと

• 専用のシークレットマネージャーを使用する。HashiCorp Vault、AWS Secrets Manager、Azure Key Vaultはデフォルトで保存時にシークレットを暗号化します。APIキー、データベースパスワード、署名キーは、平文の環境変数ではなくここに置くべきです。
• お使いのプラットフォームで保存時の暗号化を確認する。デプロイメントプラットフォームがデフォルトで環境変数を暗号化しているか、またはオプトインが必要かを確認してください。オプトイン方式の場合、いくつか見落としている可能性があります。
• 設定とシークレットを分離する。環境変数は非機密の設定（ログレベル、機能フラグ、地域設定）には適していますが、認証情報はVaultに入れるべきです。

Apidogがこれをどのように処理するか

Apidogは、HashiCorp Vault、Azure Key Vault、およびAWS Secrets Managerとネイティブに統合されています。認証が必要なAPIをテストする際、認証情報は実行時にVaultから取得され、プロジェクトファイルや環境設定に平文で保存されることはありません。Apidogにおける認証テンプレートと実際の認証情報の分離は、シークレットを公開することなくAPIテスト設定をチームと共有できることを意味します。

教訓2：AI開発ツールからのOAuth許可を監査する

Vercelの侵害全体は、AIツールへの単一のOAuth許可から始まりました。Context.aiは疑わしいアプリケーションではありませんでした。偶然にも侵害された、正当なオブザーバビリティツールだったのです。

AIツールエコシステムは急速に成長しています。Claude Code、Cursor、GitHub Copilot、Windsurf、v0、そしてその他多くの小規模ツールが、開発環境へのOAuthまたはAPIアクセスを要求します。これらの一つ一つが、攻撃者にとって潜在的な足がかりとなる可能性があります。

すべきこと

• Google Workspace、GitHub、およびIDプロバイダにおけるすべてのOAuth許可を棚卸しする。認識できないアプリがあれば、取り消してください。
• 四半期ごとの監査スケジュールを設定する。OAuth許可は静かに蓄積されます。6ヶ月前に一日だけ試したツールが、まだアクセス権を持っているかもしれません。
• 最小権限の原則を適用する。AIツールにOAuthスコープを付与する際は、利用可能な最も狭いスコープを選択してください。可能な限り読み取り専用にし、絶対に必要な場合を除き管理者アクセスは与えないでください。
• 異常なOAuth動作を監視する。Google Workspace管理コンソールはサードパーティアプリのアクセス状況を表示します。新しいOAuth許可や異常なアクティビティパターンについてアラートを有効にしてください。

AIサプライチェーンリスク

これは2026年特有の脅威であり、ほとんどのAPIセキュリティガイドはまだ追いついていません。開発者は、セキュリティレビューの速度を上回るペースでAIコーディングアシスタント、オブザーバビリティツール、自動化エージェントをワークスペースに接続しています。接続された各ツールは、攻撃対象領域を拡大します。Vercelのインシデントは、小さくニッチなAIツールであっても、大規模な侵害の侵入点となる可能性があることを証明しています。

教訓3：すべての環境変数をデフォルトで機密として扱う

Vercelのアーキテクチャでは、「機密」フラグがオプトイン方式でした。デフォルトは暗号化されていないストレージです。これは、チェックボックスをオンにするのを忘れた（または知らなかった）開発者が、APIキーを露出させたままにしたことを意味します。

これはチェックボックスの問題ではなく、設計思想の問題です。

すべきこと

• デフォルトで暗号化する。お使いのプラットフォームに「機密」トグルがある場合、すべてに対して有効にしてください。実行時に環境変数を復号化するパフォーマンスコストは、侵害のコストと比較してごくわずかです。
• 変数を分類する。設定（非シークレット）と認証情報（シークレット）の2つのカテゴリに分類してください。例外なくすべての認証情報に暗号化を適用してください。
• 規律を強制するために命名規則を使用する。SECRET_やCREDENTIAL_のようなプレフィックスをシークレット変数に付けて、コードレビュー中にチームが保護されていないシークレットを識別できるようにします。

# 設定（非機密）
LOG_LEVEL=info
REGION=us-east-1
FEATURE_FLAG_NEW_UI=true

# 認証情報（常に保存時に暗号化）
SECRET_DATABASE_URL=postgresql://...
SECRET_API_KEY=sk-...
SECRET_WEBHOOK_SIGNING_KEY=whsec_...

• 分類を自動化する。KEY、SECRET、TOKEN、PASSWORD、CREDENTIALなどのパターンを含む環境変数で、「機密」とマークされていないものを検出するCIチェックを作成してください。

教訓4：認証情報のローテーションを自動化する

Vercelが侵害を公表した際、顧客への最初の推奨事項は、すべての非機密環境変数を直ちにローテーションすることでした。数十のサービスと数百のAPIキーを持つチームにとって、これは苦痛な手動プロセスです。

最も迅速に復旧したチームは、すでに自動ローテーションを導入していたチームでした。

すべきこと

• 短い有効期限を設定する。APIキーとトークンは90日以内に期限切れにするべきです。短いほど良いです。キーが漏洩した場合でも、露出期間が限定されます。
• シークレットマネージャーでローテーションを自動化する。AWS Secrets ManagerとHashiCorp Vaultはどちらも自動ローテーションスケジュールをサポートしています。これらを設定してください。
• デプロイメントパイプラインにローテーションを組み込む。新しいバージョンをデプロイする際、そのプロセスの一部として認証情報をローテーションします。これにより、ローテーションがセキュリティ上の雑務からデプロイステップへと変わります。
• 必要になる前にローテーションをテストする。四半期ごとにローテーション演習を実施してください。チームは4時間以内に本番環境のすべての認証情報をローテーションできますか？できない場合は、できるようになるまで練習してください。

API開発者のためのローテーションチェックリスト

侵害が公表された場合（自身のものであるか、依存しているプラットフォームのものであるかに関わらず）、次の順序でローテーションしてください。

1. データベース認証情報（最も広範囲に影響）
2. 外部サービス用APIキー（決済プロセッサ、メールプロバイダ、クラウドサービス）
3. OAuthクライアントシークレット（なりすましを防止）
4. Webhook署名キー（偽造Webhookペイロードを防止）
5. デプロイメントトークン（不正なデプロイを防止）
6. セッション署名キー（潜在的に侵害されたセッションを無効化）

教訓5：CI/CDパイプラインをAPI攻撃対象領域として保護する

CI/CDパイプラインはビルド時に環境変数とシークレットを読み取ります。これはあなたのコードベース、デプロイメントターゲット、そしてしばしば本番環境の認証情報へのアクセス権を持っています。Vercelの侵害では、攻撃者はデプロイメントを管理する内部システムにアクセスしました。あなたのパイプラインもこれと同じです。

すべきこと

• シークレットのスコープを特定のパイプラインに限定する。すべてのCIジョブから本番データベースのURLを利用可能にしないでください。シークレットは、それを必要とするパイプラインにのみ制限してください。
• CIでは短期間有効な認証情報を使用する。長期間有効なAPIキーの代わりに、OIDCトークンまたはビルド完了後に期限切れとなる一時的な認証情報を使用してください。GitHub ActionsはAWS、Azure、GCP向けにOIDCをネイティブでサポートしています。
• パイプラインのアクセスログを監査する。ビルド中に誰が（そして何が）シークレットにアクセスしたかを確認してください。通常必要としないシークレットにビルドジョブがアクセスするなどの異常なアクセスパターンは、アラートをトリガーすべきです。
• CIの依存関係をピン留めする。サプライチェーン攻撃はCIランナーも標的とします。アクションのバージョンを可変タグではなく、特定のコミットSHAにピン留めしてください。

# 悪い例：可変タグ
- uses: actions/checkout@v4

# 良い例：特定のコミットにピン留め
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

• ビルド環境を隔離する。各ビルド後に破棄される一時的なビルドランナーを使用してください。永続的なランナーは状態を蓄積し、認証情報の漏洩リスクがあります。

ApidogがCI/CDセキュリティにどのように貢献するか

ApidogのCLIツールを使用すると、パイプライン設定に認証情報を埋め込むことなく、CI/CDパイプラインでAPIテストを実行できます。実行時にVaultから認証情報を取得し、テストシナリオを実行し、ビルド完了時に認証情報を破棄できます。これにより、デプロイプロセスを遅らせることなくAPIテストのセキュリティを維持できます。

教訓6：セキュリティがデフォルトで有効なAPIを構築する

Vercelのインシデントは、より広範な原則を浮き彫りにしています。それは、セキュリティ制御はデフォルトで有効になっており、開発者は特定の理由がある場合にのみオプトアウトすべきだということです。Vercelでは、開発者がチェックボックスをオンにする必要があることを知らなかった（または忘れていた）ため、オプトインモデルは機能しませんでした。

この原則を、あなたが構築するAPIに適用してください。

すべきこと

• デフォルトですべてのエンドポイントに認証を要求する。認証なしのアクセスは例外とし、ルールではありません。エンドポイントが公開されている場合は、その理由を文書化してください。
• デフォルトでレート制限を有効にする。控えめな制限（APIキーあたり毎分100リクエストなど）から始め、顧客が必要性を示した場合に引き上げてください。
• 最小限のエラー情報を返す。APIはエラー応答で内部の詳細を漏洩すべきではありません。スタックトレース、データベース名、内部IPはログに残し、500応答には含めないでください。
• すべての入力を積極的に検証する。クライアントから提供されたデータを信用しないでください。すべてのエンドポイントでタイプ、長さ、範囲、フォーマットを検証してください。
• すべての認証イベントをログに記録する。成功したログイン、失敗した試行、トークンのリフレッシュ、権限変更はすべて監査ログエントリを生成すべきです。

Apidogにおけるセキュリティスキームの設計

Apidogは、OAuth 2.0、JWT、mTLS、APIキー、Hawk認証を含む13の認証方法をネイティブにサポートしています。ApidogでAPIを設計する際、セキュリティスキームをプロジェクトレベルで定義し、すべてのエンドポイントに継承させることができます。これは、作成するすべてのエンドポイントで認証がデフォルトで有効になることを意味します。エンドポイントを公開したい場合は、セキュリティスキームを明示的に削除します。これは意識的なオプトアウトであり、忘れられたオプトインではありません。

Apidogのインターフェースで、カスタムクライアント証明書とCA証明書を使用した相互TLSを含む各認証方法を直接テストできます。これにより、デプロイ前にセキュリティ設定が正しく機能することを確認し、認証設定ミスを早期に発見できます。

教訓7：必要になる前にインシデント対応プレイブックを構築する

現在の検索結果上位のAPIセキュリティガイドには、API認証情報が侵害された後に何をすべきかについて触れているものはありません。Vercelの侵害は、多くのチームがプレイブックを持たないまま対応に追われる事態を招きました。彼らは、どのキーを最初にローテーションすべきか、不正なAPI呼び出しをどのように確認するか、そして影響を受けたユーザーとどのように連絡を取るかを必死に模索しました。

API認証情報インシデント対応プレイブック

フェーズ1：封じ込め（最初の30分）

• 潜在的に漏洩した認証情報を特定する
• 最もリスクの高い認証情報（データベース、決済プロセッサ）を直ちにローテーションする
• すべてのAPIエンドポイントで強化されたロギングを有効にする
• 特定された既知の攻撃者IP/トークンをブロックする

フェーズ2：評価（最初の4時間）

• 漏洩期間のAPIアクセスログを確認する
• 侵害された認証情報で行われた不正なAPI呼び出しを特定する
• データ流出パターン（異常なクエリ量、大量の応答、機密エンドポイントへのアクセスなど）を確認する
• アクセスされたものとアクセスされなかったものを文書化する

フェーズ3：修復（最初の24時間）

• 残りのすべての認証情報をローテーションする（教訓4のローテーションチェックリストを参照）
• すべてのアクティブなセッションを失効させ、再認証を強制する
• サードパーティアプリケーションへのOAuth許可を確認し、失効させる
• ファイアウォールルールとIP許可リストを更新する
• 侵害を許した脆弱性をパッチで修正する

フェーズ4：連絡（48時間以内）

• 影響を受けた顧客に具体的な詳細を通知する：何が漏洩したか、何が漏洩しなかったか、彼らが何をすべきか
• API利用者に明確なローテーション手順を提供する
• タイムラインと修復手順を含む事後分析レポートを公開する
• 得られた教訓に基づいてセキュリティドキュメントを更新する

Apidogでプレイブックをテストする

Apidogのテストシナリオを使用して、認証情報侵害のシナリオをシミュレートできます。次のようなテストケースを作成してください。

• 期限切れのトークンがキャッシュされたデータではなく401を返すことを確認する
• ローテーションされたAPIキーが古いキーを直ちに無効にすることを確認する
• ブルートフォース攻撃中にレート制限が機能することをテストする
• エラー応答が内部情報を漏洩しないことを検証する

これらのテストを、認証情報がローテーションされるたびにCI/CDパイプラインで実行し、セキュリティ制御が期待どおりに機能することを確認してください。

実際の使用例

フィンテックAPIプラットフォーム

ある決済処理スタートアップは、Vercelの開示から3時間以内に340個のAPIキーをローテーションしました。彼らはAWS Secrets Managerに連携した事前に構築されたローテーションスクリプトを持っていました。ApidogでのAPIテストにより、本番トラフィックを切り替える前に、各ローテーションキーが正しく機能することを確認しました。ダウンタイムはゼロでした。

SaaSコラボレーションツール

プロジェクト管理APIを構築するチームは、侵害開示後にVercel上に17個の暗号化されていない環境変数があることを発見しました。彼らはすべての認証情報をHashiCorp Vaultに移行し、ローテーション後の各認証方法を検証するためにApidogテストシナリオを設定し、暗号化されていないシークレットを含むデプロイをブロックするCIチェックを追加しました。

EコマースAPIゲートウェイ

あるEコマースプラットフォームはOAuth許可を監査し、GitHub組織にアクセスできるAIツールが12個あることを発見しました。そのうち8個のツールは6ヶ月以上使用されていませんでした。彼らは未使用の許可をすべて失効させ、四半期ごとの監査サイクルを導入しました。

結論

Vercelの侵害は、特異なものではありませんでした。それは、ほとんどのAPI開発ワークフローに見られるパターン、すなわち平文のシークレット、累積されたOAuth許可、オプトインのセキュリティデフォルトを悪用したものです。ここに示す7つの教訓は理論的なものではありません。これらは、攻撃チェーンがどのように機能したかに対する直接的な対応策です。

主要なポイント：

• 転送時だけでなく、保存時のすべてのシークレットを暗号化する
• すべてのOAuth許可、特にAI開発ツールのものを監査する
• すべての認証情報をデフォルトで「機密」として扱う
• 必要になる前にローテーションを自動化する
• CI/CDパイプラインを攻撃対象領域として扱う
• 認証がデフォルトで有効なAPIを構築する
• 今週中にインシデント対応プレイブックを作成し、侵害発生時に慌てないようにする

あなたのAPI認証情報のセキュリティは、ツールチェーンの最も弱いリンクと同程度です。Vercelのインシデントは、そのリンクが半年前につながれて忘れ去られた小さなAIツールである可能性があることを証明しています。

今すぐAPIワークフローのセキュリティを強化しましょう。Apidogをダウンロードして、認証方法のテスト、シークレットマネージャーとの連携、セキュリティ重視のテストシナリオの実行をすべて1つのワークスペースで行いましょう。クレジットカードは不要です。

button

よくある質問

2026年4月のVercelセキュリティインシデントとは何でしたか？

攻撃者がContext.aiというサードパーティ製AIツールのOAuthアプリケーションを侵害し、それを利用してVercel従業員のGoogle Workspaceアカウントを乗っ取り、保存時に暗号化されていなかった顧客の環境変数にアクセスしました。この侵害は2026年4月19日に公表されました。

Vercelの顧客APIキーは漏洩しましたか？

「機密」としてマークされていない顧客の環境変数が漏洩しました。これには、保存時に暗号化されていなかったAPIキー、データベース認証情報、デプロイメントトークンが含まれます。「機密」と明示的にマークされた変数（保存時に暗号化済み）は侵害されませんでした。

Vercelの環境変数が暗号化されているかを確認するにはどうすればよいですか？

Vercelダッシュボードで、プロジェクト設定 > 環境変数に移動してください。「機密」とマークされた変数は保存時に暗号化されています。このフラグのない変数は暗号化されずに保存されており、影響を受けた場合は直ちにローテーションする必要があります。

APIキーを安全に保存する最良の方法は何ですか？

HashiCorp Vault、AWS Secrets Manager、Azure Key Vaultのような専用のシークレットマネージャーを使用してください。これらはデフォルトで保存時にシークレットを暗号化し、自動ローテーションをサポートし、監査ログを提供します。APIキーを平文の環境変数、Gitリポジトリ、または設定ファイルに保存しないでください。

APIキーはどのくらいの頻度でローテーションすべきですか？

APIキーは最低でも90日ごとにローテーションしてください。リスクの高い認証情報（データベースパスワード、決済プロセッサキーなど）については、30日ごとにローテーションしてください。インフラストラクチャまたは依存するプラットフォームに影響を与えるセキュリティインシデントが発生した後は、すべての認証情報を直ちにローテーションしてください。

OAuthサプライチェーン攻撃とは何ですか？

OAuthサプライチェーン攻撃とは、あなたのシステムへのOAuthアクセスを持つサードパーティアプリケーションを標的とするものです。攻撃者は直接あなたを攻撃するのではなく、サードパーティアプリを侵害し、その既存のOAuth許可を利用してあなたのデータにアクセスします。Vercelの侵害は、この攻撃ベクトルの典型的な例です。

ApidogはAPIセキュリティテストにどのように役立ちますか？

Apidogは13種類の認証方法をサポートし、主要なシークレットマネージャー（HashiCorp Vault、Azure Key Vault、AWS Secrets Manager）と統合されており、セキュリティ重視のテストシナリオを実行できます。トークンの有効期限、認証情報のローテーション、レート制限、エラー応答処理などを、CI/CDパイプラインで実行される自動テストスイートでテストできます。

API認証情報侵害後に最初に行うべきことは何ですか？

最もリスクの高い認証情報、すなわちデータベースパスワード、決済プロセッサAPIキー、OAuthクライアントシークレットを直ちにローテーションしてください。次に、すべてのAPIエンドポイントで強化されたロギングを有効にし、漏洩期間のアクセスログを確認し、インシデント対応プレイブックに沿って体系的に作業を進めてください。