要約

  • 2026年8月公開の RFC 10017は IETF の Best Current Practice であり、業務、機微情報、個人データを扱うブラウザーアプリには Backend for Frontend を強く推奨する。アクセスおよびリフレッシュトークンをブラウザーコードから外せるからだ。
  • BFF は複数のトークン窃取と新規トークン取得を防ぐが、正規アプリと同じオリジンで動く悪性コードまでは隔離しない。秘密が流出しなかった事実は、意図しない操作がなかった証明ではない。

盗まれた秘密が一つもない侵害

冒頭は RFC の脅威分析から作った事例であり、公表済み事故ではない。狙いは、持ち運べる資格情報を攻撃者が得たかという問いと、現在の利用者コンテキストを使って操作できたかという問いを分離することにある。

RFC 10017では、悪性 JavaScript はアプリ内の弱い別主体として扱われない。同じ実行環境に入れば正規コードと同じ権限を持ち、画面のデータを調べ、オリジン単位の保存領域を使い、同一オリジンのコンテキストと通信し、正規オリジンからバックエンドへ要求を送れる。

文書は四つの攻撃を区別する。現在のトークンを一度盗む、更新後も継続的に盗む、新しい認可フローで独立したトークンを取得する、そしてトークンを抜き出さず利用者のブラウザーから要求を代理する、である。最後の攻撃では、正規コードと侵害コードの要求は同じ文脈から出る。外部コンポーネントがトークンを付ける設計なら、侵害コードが誘発した要求にも付け得る。

したがって「トークン流出なし」が閉じるのは、値が管理外へ出たか、別環境で再利用できたかという問題だけだ。どの要求がセッションから出たか、BFF の経路が広すぎなかったか、資源サーバーがその業務操作を許すべきだったかは残る。

BFF が変えるのは被害の形

BFF には三つの中心的役割がある。機密 OAuth クライアントとして認可サーバーと通信し、アクセスおよびリフレッシュトークンをサーバー側のセッション文脈で管理し、ブラウザーからの要求に適切なトークンを加えて資源サーバーへ転送する。ブラウザーが触るのはセッション用の入口であり、トークン本体ではない。

効果は大きい。ブラウザー内に盗むトークンがなく、一回限りと継続的な窃取が成立しない。侵害コードが認可コードを得ても、BFF のクライアント資格情報なしでは交換できない。PKCE は認可コード交換への別の攻撃も狭める。

しかし残る攻撃も仕様に明記される。悪性コードはアプリのオリジン内から BFF へ要求できる。HttpOnly は Cookie 値を読ませないが、許された要求にブラウザーが Cookie を付ける動作は止めない。BFF は秘密を一度もブラウザーへ見せず、トークンを選んで転送できる。

これはクライアントハイジャックである。攻撃者はアプリ、セッション、BFF のマッピング、資源ポリシーが認める操作に制限される。トークンを任意の機械へ持ち出す権限は得ない。その差は重要だが、実行中のコードが信頼できるという意味にはならない。

RFC が機微なアプリに BFF を強く推奨しつつ、残余攻撃を示すのは矛盾ではない。アーキテクチャは被害を比較して選ぶ。最も長く持続し、場所を越えて使える資格情報被害を除いても、活動中の利用者文脈を悪用する経路は残る。

読めない Cookie も要求には使われる

RFC 10017は BFF の Cookie に Secure と HttpOnly を要求し、SameSite=Strict、パス/、Domain 属性なし、ホスト範囲の適切な接頭辞を推奨する。これらはネットワーク露出、スクリプト読出し、広いサブドメイン共有を抑える。

それでも要求の意図は証明しない。Cookie がブラウザーと BFF の関係を認証するため、BFF は CSRF 対策を実装しなければならない。単独サイトなら SameSite=Strict は有効だが、同じ eTLD+1 を持つ兄弟サブドメインは cross-origin でも same-site である。一方の乗っ取りが、単純な same-site 前提を崩すことがある。

CORS も設定名ではなく実際の挙動で確認する。一部の safelisted request は preflight なしで送信され、ブラウザーは応答をコードへ渡さないだけである。preflight を防御に使う BFF はカスタムヘッダーを必須にし、すべての対象入口で欠落を拒否できる。証拠は「CORS 有効」ではなく、各状態変更要求が同じ条件を通った記録だ。

セッションの寿命はリフレッシュトークンとも結び付ける。トークンが失効したのに有効そうなセッションを残せば状態が食い違う。逆にトークンだけを失効させ、関連セッションを追えなければ、どのブラウザー動作が停止したかを説明できない。

プロキシ経路は権限表である

BFF は秘密の保管庫だけではない。Cookie で裏付けた受信要求を bearer 認可付きの送信要求へ変換するアプリケーション層プロキシであり、その対応表自体が制御面になる。

RFC 10017は送信先を厳格に制限する。宛先ホストを allowlist に置き、動的パスを検査し、入口ごとに HTTP メソッドを絞る。境界がなければ、正規セッションが開放プロキシのように使われ、トークンが想定外ホストへ渡るか、フロントエンドが公開するつもりのない操作へ到達する。

たとえば/bff/orders/{id}は配管ではない。どの資源、パス、メソッドにセッションを使えるかを定義する。資源サーバー側にも audience、scope、主体、操作別ポリシーの確認が必要だ。正しい BFF 転送は、返金や移転や管理変更が現在の業務規則で許可された証明にならない。

HTTP 成功だけでも記録は終わらない。資源側が後で拒否する場合、BFF が再試行する場合、多数の利用者が一つの送信元 IP に集約されて誤ってレート制限される場合がある。セッション、要求 ID、経路判断、トークン範囲、資源判断、最終業務状態を結ぶ必要がある。

BFF にはプライバシー集中も生じる。全要求と応答を観察でき、第三者が運営すればブラウザーのトークン露出は減る一方、その第三者が見られるデータは増える。資格情報の安全とデータ最小化は別々に決める。

三方式は異なる証拠を残す

BCP は安全性と複雑性の順に三方式を並べる。完全な BFF は両トークンをサーバーに置き、資源要求をすべて代理する。token-mediating backend はクライアント資格情報とリフレッシュトークンを守るが、アクセスをブラウザーへ返す。ブラウザーのみのクライアントは OAuth とトークンを自分で扱う。

中間方式では、悪性コードがアクセスを盗み、またはアプリ内で使う可能性が残る。保護されたリフレッシュトークンやバックエンド資格情報までは通常得ない。これは単なる「安全度の途中」ではなく、保管、再利用、要求に関する異なる証拠契約である。

ブラウザーのみの方式は四つすべての攻撃にさらされる。Authorization Code と PKCE が必須で、発行するリフレッシュトークンにはローテーションまたは sender constraint と寿命制限が必要だ。これらは横取りと長期利用を抑えるが、すでに正規オリジンへ入ったコードを隔離しない。

DPoP も有用だが限定的だ。非抽出鍵は盗んだアクセスを外で使いにくくするものの、元のブラウザーを使う代理要求は止めない。侵害コードが新規フローを開始できるなら、自分の鍵に新トークンを結び付けられる場合もある。「sender constrained」にはどの実行文脈とフローかが必要だ。

共通ドメインのフロントエンドと API が互いのために OAuth を必要としない場合もある。連携認証後に自前セッションを維持できるなら、独立した資源関係のない OAuth 追加は、明確な信頼境界より先にトークンとプロキシ面を増やす。

機構より広い安全宣言をしない

RFC 10017はブラウザー隔離を約束しないから有用である。BFF はトークン露出への強い局所策であって、オリジン内の全コード、全代理要求、全業務結果への包括承認ではない。

運用記録では、コードと依存物の来歴、オリジン、セッション発行と期限、Cookie 属性、時刻、メソッド、パス、本文分類、CSRF 結果、BFF マッピング、トークン audience と scope、資源判断、応答、業務結果、復旧責任者を分ける。それぞれ時計と所有者が違う。

薄い共通仕様の役割もここにある。BCP は最低条件を共有し、アプリ境界、endpoint allowlist、異常しきい値、可逆性は現場に残す。図や製品ラベルではなく動作を証拠にし、詐欺、プライバシー、停止の損失を負う主体が許可、観察、停止、取消しの最終権限を持つ。

情報源