トークン窃取を多層で止める——セッション・AI推論・課金まで含めた防御パターン

クレデンシャルは「いつか盗まれる」前提で設計する時代になった。サプライチェーン経由でnpmパッケージから認証情報が抜かれる事件は止まらない（先行記事のMicrosoftが警告したnpmサプライチェーン侵害「Miasma」が典型だ）。

そこで本記事は、視点を「窃取の検知」から「窃取された後でも被害を最小化する多層防御」に移す。鍵は2系統のトークン窃取を、Edge・Auth・App・監査財務の4層で同時に止めることだ。

30秒で理解する

トークン窃取と聞くと、多くの人はクッキーやJWTを抜かれる「セッション窃取」を思い浮かべる。それは今も主要な脅威だ。

だが2025〜2026年に表面化したのが、もう1系統の「AI推論トークン窃取」だ。公開された推論APIを濫用され、課金が爆発する。

両者は経路も実害も違うが、防御の発想は同じだ。「窃取される前提で、層を重ねて被害を止める」。

4層は次のように積む。Edge層でBotを弾き、Auth層でトークンを短命・回転・バインドし、App層でAPIの異常を検知し、監査・財務層で使用ログとコスト異常を監視する。

この4層を、Vercel・Cloudflare・AWSのどの機能で実装するか——それが本記事の地図だ。

なぜ今「トークン窃取」を広く語るのか

セッション窃取は古典的な課題だ。XSSやMitM、リポジトリへの秘密情報コミット、.env流出——どれも昔からあり、今も続いている。

新しいのは、AI推論トークン窃取という被害カテゴリだ。これは「盗む対象」が認証情報ではなく、課金される推論呼び出しそのものに広がったことを意味する。

たとえば公開のチャットAPIエンドポイントが認証バイパスやBot自動化で叩かれると、攻撃者は自分のコストゼロで大量の推論を回せる。請求書は運営者に届く。

共通構造は「窃取される前提で多層防御する」だ。1枚の壁（WAFや署名検証）に頼ると、その壁を抜けた瞬間に被害が青天井になる。

先行記事のMicrosoftが警告したnpmサプライチェーン侵害「Miasma」は、正規の署名を通しながら認証情報を抜く攻撃だった。「署名された＝安全」という1枚の壁が崩れた例として、本記事の多層防御の動機そのものだ。

2系統のトークン窃取と被害像

まず、何が盗まれて何が起きるのかを2系統に分けて整理する。経路と実害が違えば、効く防御も違うからだ。

セッション/認証トークン窃取

奪われるのは、セッションクッキー、JWT、OAuthのrefresh token、APIキー、クラウドの一時クレデンシャルなどだ。

主な経路は次の通り。

・XSSでブラウザ内のトークンを読み出す
・MitM（中間者）で通信中のトークンを傍受する
・公開リポジトリや.env、ビルドログへの秘密情報の混入
・サプライチェーン経由（依存パッケージが認証情報をスキャン）

実害は、なりすまし、データ漏洩、そして奪ったクレデンシャルを起点とした特権昇格だ。一度の漏洩が横展開していく。

AI推論トークン窃取（inference theft）

ここでの「トークン」はLLMの課金単位（入力/出力トークン）と、それを呼ぶ権利の両方を指す。

主な経路は次の通り。

・認証なしで叩ける公開推論エンドポイントの濫用
・認証バイパス（クライアント側だけの制限、検証漏れ）
・Bot自動化による大量並列リクエスト
・フロントエンドに埋め込まれたLLM APIキーの抽出

実害は課金の爆発だ。Vercelは自社のDocs AI機能が濫用され、ピーク時に毎分1,300リクエスト・1日あたり約1万ドル規模の請求が発生した事例を公表している。

加えて、レート制限が枯渇して正規ユーザーが使えなくなる、奪ったAPIアクセスが転売される、といった二次被害もある。

被害が見えにくいのも特徴だ。セッション窃取はデータ漏洩として後から発覚することが多い。一方AI推論窃取は、月末の請求書か、レート上限のアラートで初めて気づくことが少なくない。

しかも攻撃者にとって参入障壁が低い。公開エンドポイントとスクリプトさえあれば、特別な脆弱性を突かなくても「正規の使い方を大量に繰り返す」だけで成立してしまう。

だからこそ、入口（Edge）で自動化を弾き、出口（財務）で課金に天井を作る——両端を締める設計が効く。

防御の全体像：4層モデル

2系統のどちらにも効く防御を、トラフィックが通る順に4層で積む。攻撃者から見れば、各層が独立した関門になる。

各層の役割を簡潔にまとめる。

重要なのは、上の層を抜けても下の層で止められる構造にすることだ。Edgeを抜けたBotはAuthの短命トークンで止まり、Authを抜けた盗難トークンはAppの異常検知で止まり、それも抜けたら財務層で課金を止める。

プラットフォーム別の防御パターン

同じ4層を、Vercel・Cloudflare・AWSがそれぞれどの機能で実装するかを見ていく。自分のスタックに引き当てて読んでほしい。

Vercel

フロントエンド中心のNext.jsスタックなら、Vercelの組み込み機能だけで4層の骨格が組める。

セッション系では、Vercel Authentication（プレビュー/本番へのアクセス制限）、Secure CookieやEdge Configでの設定配布、Deploy Hookのスコープ限定が効く。

AI推論系の主役はBotIDだ。不可視のチャレンジとクライアント側のMLシグナルでリクエストごとにBotらしさを判定する。CAPTCHA画像を解かせないため摩擦が小さい。

// Next.js Route Handler で BotID により推論APIを保護する例（防御設定）
import { checkBotId } from "botid/server";

export async function POST(req: Request) {
  const verdict = await checkBotId();
  if (verdict.isBot) {
    // 高リスク経路（推論・課金）のみ遮断。まずは monitor から始める
    return new Response("Forbidden", { status: 403 });
  }
  // ここで初めてLLM呼び出し。APIキーはサーバー側にのみ存在させる
  return handleInference(req);
}

課金系では、Spend Management（支出上限と通知）と、上限到達時の自動停止アクションを設定する。これが財務層の最後の壁になる。

Cloudflare

複数オリジンを束ねる構成や社内向けアプリには、Cloudflareのゼロトラスト機能群がよく合う。

セッション系では、Access（IDベースのアクセス制御）、Service Tokens（マシン間認証）、mTLS、Zero Trustポリシー、Workers Secretsを組み合わせる。

AI推論系では、Turnstile（不可視CAPTCHA代替）、Bot Management（MLスコアリング）、AI Gateway（推論プロキシ）、API Shieldが効く。とくにAI Gatewayは、推論呼び出しを一か所に集約してレート制御・キャッシュ・ログを掛けられるのが強い。

課金系では、Analytics Engineにカスタム閾値を置き、WorkersのログをLogpushで外部に流して監視する。

AWS

バックエンドやBedrockでの生成AI推論を主軸にするなら、AWSの認証・監査・財務の機能が揃っている。

セッション系の選択肢は厚い。IAM Identity Center、IAM Roles Anywhere、STSの短命クレデンシャル、IMDSv2（メタデータ盗用対策）、Cognitoのrefresh rotation、API GatewayのmTLS、KMS、SCP（組織レベルのガードレール）、そしてCloudTrailによる監査だ。

AI推論系では、WAF Bot Control、Shield Advanced、Bedrock Guardrails（入出力のポリシー強制）、API GatewayのUsage Plans＋Lambda Authorizerでスコープとレートを縛る。

課金系の主役はCost Anomaly Detection（ML based）とBudget Actionsだ。異常を検知して、特定の権限を自動で剥がせる。

// IMDSv2 を必須化（トークン無しのメタデータ取得を拒否）— 防御設定の例
// EC2 起動テンプレート / aws ec2 modify-instance-metadata-options 相当
{
  "MetadataOptions": {
    "HttpTokens": "required",      // IMDSv2 トークン必須（v1を無効化）
    "HttpPutResponseHopLimit": 1,  // コンテナからの間接取得を抑止
    "HttpEndpoint": "enabled"
  }
}

IMDSv1を残すと、SSRF経由でインスタンスの一時クレデンシャルを抜かれる定番の経路になる。HttpTokens: requiredで塞ぐのが基本線だ。

3者の機能対応表

4層を支える代表機能を、軸ごとに3社で並べる。空欄は「単体機能としては薄い／別機能で代替」を意味する。

表の使い方はシンプルだ。自分の主軸プラットフォームの列を縦に読み、空欄や薄い行を「他社機能や自前実装で補う場所」として洗い出す。

標準視点：認証スタックの設計原則

プラットフォームに依存しない、Auth層そのものの設計原則を押さえておく。これがあるとプロダクト選定がぶれない。

第一に、アクセストークンは短命にし、refresh tokenで回す（rotation）。盗まれても有効期限が短ければ被害窓が縮む。

第二に、トークンを送信元にバインドする。PKCE（RFC 7636）で認可コード横取りを防ぎ、DPoP（RFC 9449）やmTLS-bound token（RFC 8705）で「鍵を持つ者しか使えない」状態にする。

第三に、ブラウザ側のクッキーはHttpOnly＋Secure＋SameSiteを基本とする。JavaScriptから読めなくすれば、XSSの被害をクッキー送出面に限定できる。

// セッションクッキーの安全なデフォルト（防御設定の例）
res.cookie("session", token, {
  httpOnly: true,                 // JSから読めない（XSS対策）
  secure: true,                   // HTTPSのみ送出
  sameSite: "lax",                // 既定はlax。クロスサイトPOSTを抑制
  maxAge: 60 * 15 * 1000,         // 短命（15分）。更新はrefreshで
  path: "/",
});

第四に、ログアウトと失効を設計に入れる。OIDC Front-Channel Logoutなどで、関連セッションを連鎖的に切る。

多層防御として考える：WAFの先にあるもの

「WAFを入れたからBot対策は完了」——これが現代では最も危ない思い込みだ。

WAFは既知の攻撃パターン（SQLi、既知のシグネチャ）を止めるのは得意だ。だが正規の形をした大量アクセスや、盗んだトークンでの正常に見える呼び出しは、パターンに乗らない。

そこで必要になるのが、リクエスト単位のBot判定だ。MLスコアリング、JSによる挙動検出、SDKフィンガープリントで「人間らしさ」を都度評価する。BotIDやTurnstileがこの層を担う。

さらにApp層では、API利用パターンの異常を検知する。OWASPのAutomated Threats（OAT-001〜021）が観点の整理に役立つ。とくに次の3つは課金・データ両面で重要だ。

・OAT-008 Credential Stuffing：流出クレデンシャルの総当たりログイン
・OAT-010 Card Cracking に類する濫用：自動化された有効性チェック
・OAT-015 Denial of Service：リソース枯渇狙いの大量呼び出し

AIエージェントの普及で、この層はさらに重くなる。エージェントは正規の資格情報を持った自動化呼び出しなので、Bot判定だけでは弾けない。短命・最小スコープのクレデンシャルと、推論の集約点（AI Gateway）での観測が効いてくる。

ここで「正常に見える呼び出し」をどう見分けるかが課題になる。手がかりは振る舞いの逸脱だ。普段は1分に数回のユーザーが突然毎分数百回叩く、深夜帯に特定エンドポイントだけ急増する、1つのトークンが地理的に離れたIPから同時に使われる——こうしたパターンはパターンマッチでは拾えないが、ベースラインからの逸脱として検知できる。

実装としては、トークン単位・IP単位・エンドポイント単位でレートと成功/失敗比率を時系列で持ち、移動平均からの乖離でスコアリングする。完璧な判定を目指すより、「怪しい時だけ追加チャレンジを挟む」「高リスク経路だけ厳しくする」といった段階的な締め方が現実的だ。

そして最後に、課金面の防御線を引く。技術的にすべてを止めきれなくても、財務層で被害額に天井を作れる。

コスト異常検知の実装パターン

財務層は「検知」と「対応」を分けて考えると設計しやすい。検知だけでは請求は止まらないからだ。

代表的な組み合わせは次の通り。

設計の肝は段階性だ。第一段は「通知のみ」の緩い閾値で人間に判断させる。第二段は明確な異常時だけ発火する「自動シャットオフ」に限定する。

// 二段構えの考え方（擬似ポリシー）— 防御設計の例
{
  "stage1_notify": {
    "trigger": "日次コスト > 直近14日平均 × 1.8",
    "action": "Slack / メール通知（人間が判断）"
  },
  "stage2_autostop": {
    "trigger": "1時間コスト > 月予算 × 0.25 かつ 異常レート",
    "action": "対象APIキー無効化 / 課金系IAMアクションをDeny"
  }
}

自動停止には過剰停止のリスクがある。正規のキャンペーンやバッチのスパイクを巻き込むと、サービス全体を落としかねない。

だから自動停止の対象は、本番の課金系APIキーや特定のIAMアクションに絞り、全停止は避ける。「何を、どこまで止めるか」を事前に決めておくことがバランスの取り方だ。

実装の優先順位（規模別）

全部を一度に建てる必要はない。スタックの主軸に応じて、効果の大きい順に入れる。

小規模Vercelアプリ（まず30分のQuick wins）

BotIDで推論・課金APIを保護し、Vercel Authenticationでプレビューを閉じ、Spend Managementで支出上限を引く。これだけで「課金爆発」の最悪ケースに天井ができる。

Cloudflare中心スタック

Accessで境界を閉じ、Turnstileで人間判定を入れ、AI Gatewayで推論を集約し、Analytics Engineで閾値監視する。複数オリジンを束ねるほど効く。

AWS中心スタック

IAM Identity Centerで人の認証を集約し、WAF Bot ControlでEdgeを固め、Bedrock Guardrailsで推論の入出力を縛り、Cost Anomaly Detection＋Budget Actionsで財務層を自動化する。

よくある落とし穴

実装で繰り返し見かける穴を挙げる。どれも「1枚の壁を過信した」結果だ。

・refresh tokenをlocalStorageに保存（XSS一発で全部抜ける）
・公開リポジトリへのEnvVar混入、Vercel Preview URLの認証バイパス
・session cookieのSameSite=Noneを必要もなく設定（CSRF面が開く）
・Cloudflare Accessのポリシーに想定外の通し穴
・「WAFを入れたからBot対策は完了」という思い込み
・Cost Anomalyで検知はするが、自動停止が未設定（請求は止まらない）
・LLM APIキーをフロントエンドから直接呼ぶ（キー抽出 → 推論窃取）
・BotID/Turnstileのbypass用クッキー/トークンの流出

移行と運用：既存スタックへの足し方

ここまでの4層を、稼働中のサービスへどう足していくかを補足する。一度に全部入れ替える必要はない。

最初にやるべきは「現状の棚卸し」だ。どのトークンが何分有効で、どこに保存され、誰が発行できるのかを書き出す。長命なAPIキーや、フロントに露出した推論キーが見つかれば、そこが最優先の塞ぎどころになる。

次に、観測を先に入れる。ブロックより前に「誰が・どのエンドポイントを・どのレートで叩いているか」を可視化する。Edge層のBot判定もmonitorモードで始め、財務層のコスト異常検知も通知だけで回す。

数値が溜まったら、はじめて強制（ブロック・自動停止）に進む。閾値は実トラフィックのベースラインから決める。机上の数字で強制を入れると、正規ユーザーや正規バッチを巻き込む。

最後に、変更を可逆にしておく。新しいトークン方式や強制ルールは、フラグで即座に戻せる形で投入する。インシデント時に「切り戻せない防御」は、それ自体が可用性リスクになる。

なお、本記事のよくある質問（使い分け・Auth.jsの十分性・JWTの限界・localStorage・誤検知率・閾値設計・エージェント時代の追加観点）は、ページ末尾の「よくある質問」にまとめている。設計判断の早見表として参照してほしい。

参照ソース

・Vercel: Protecting against token theft / BotID / Spend Management
・Cloudflare: Bot Management / Turnstile / AI Gateway / Access / Service Tokens
・AWS: IAM Identity Center / IMDSv2 / Bedrock Guardrails / WAF Bot Control / Cost Anomaly Detection / Well-Architected Security Pillar
・IETF: RFC 7636 (PKCE) / RFC 8705 (mTLS) / RFC 9449 (DPoP)
・OWASP: ASVS / Automated Threats (OAT)
・先行記事：Microsoftが警告したnpmサプライチェーン侵害「Miasma」