ひとことで言うと
Bearerトークンとは、HTTPリクエストの「Authorization: Bearer <token>」ヘッダーで送信されるアクセストークンです。RFC 6750で定義された仕様で、このトークンを持っている（Bearer＝持参人）だけでリソースへのアクセス権が得られます。ユーザー名・パスワードなしでAPIを認証できるため、サービス間連携で広く使われています。
「持っているだけでアクセスできる」という特性上、Bearerトークンが盗まれると攻撃者がそのトークンを使って正規ユーザーと同じ操作を実行できます。有効期限（通常1時間〜24時間）が設定されているケースが多いですが、期限が長いほどリスクも高まります。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
HTML共有で関係する場面
AIがフロントエンドHTMLにAPI呼び出しのサンプルコードを生成した際、JavaScriptのfetch()にBearerトークンをハードコードするコードが出力されることがあります。このHTMLをそのまま共有すると、ブラウザのDevToolsでソースを見た人が即座にトークンを取得できる状態になります。
ギガサイト便のようなHTMLプレビューサービスでは、閲覧者が認証されているかどうかの確認にBearerトークンが使われます。このトークンはHTTPのCookieまたはLocalStorageに保存され、サービスのAPIリクエストに自動付与されます。通常、エンドユーザーが直接触れることはなく、ブラウザが自動管理します。
よくある誤解
「Bearerトークン＝APIキー」という混同が多いです。APIキーはサービスへの認証に使う固定の秘密文字列ですが、Bearerトークンは多くの場合OAuthの認証フローで一時的に発行されるアクセストークンです。有効期限が短く、リフレッシュトークンで更新する設計が一般的です。
「BearerトークンはHTTPSなら安全に送れる」は半分正解です。HTTPSで通信内容は暗号化されますが、トークンがHTMLや`localStorage`に平文で保管されていれば、XSS攻撃でブラウザからトークンを盗まれるリスクがあります。Bearerトークンの保管場所と送信経路の両方を安全に保つ必要があります。
安全に使うための注意点
AIが生成したJavaScriptコードにAuthorizationヘッダーとBearerトークンが含まれている場合、そのトークン文字列がプレースホルダーか実際の値かを必ず確認してください。「Bearer YOUR_TOKEN_HERE」はサンプルですが、「Bearer eyJhbGci...」のように実際のJWT形式のトークンが入っている場合は即時削除が必要です。
フロントエンドHTMLでBearerトークンを使ったAPI呼び出しを実装する場合は、トークンをlocalStorageではなくHttpOnly Cookieまたはメモリにのみ保持する設計を採用してください。HttpOnly属性が付いたCookieはJavaScriptからアクセスできないため、XSS経由でのトークン窃取リスクを大幅に下げられます。
よくある質問
AI生成コードのBearerトークンが本物かどうか、どうやって見分けますか？
プレースホルダーは通常「YOUR_TOKEN」「ACCESS_TOKEN」「<token>」のような形式です。「eyJ」で始まる文字列はBase64エンコードされたJWTで本物の可能性が高く、即時無効化が必要です。jwt.ioでデコードして発行元と有効期限を確認してください。
Bearerトークンが漏えいした場合、どうすれば被害を最小化できますか？
トークンを発行したサービスの管理画面でそのトークンを即時無効化（revoke）してください。OAuthのリフレッシュトークンも同時に無効化する必要があります。その後、アクセスログを確認して不正利用の形跡を調査し、新しいトークンを発行してください。
フロントエンドHTMLでBearerトークンを安全に使う方法はありますか？
バックエンド（Cloudflare Workers・Next.js API Routes等）をプロキシとして挟み、Bearerトークンはサーバー側だけが保持する構成が最も安全です。フロントエンドはCookieセッションでバックエンドに認証し、バックエンドが外部APIへBearerトークンを付けてリクエストします。