要約

  • 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、異常しきい値、可逆性は現場に残す。図や製品ラベルではなく動作を証拠にし、詐欺、プライバシー、停止の損失を負う主体が許可、観察、停止、取消しの最終権限を持つ。

情報源