要約

  • RFC 10017のBackend for Frontendは機密OAuthクライアントとして動き、アクセス／更新トークンをCookieセッションの背後で管理する。ブラウザ側には盗める既存トークンがなく、攻撃コードだけで新しい認可コードを交換することもできない。
  • それでも同一オリジンで実行される悪意あるコードは、正規frontendと同じBFF endpointを呼べる。ブラウザがCookieを付け、BFFがトークンを選んでresource serverへ転送するため、残る結果はclient hijackingである。
  • 実装のreceiptは、originとbuild、sessionとCookie方針、CSRF判定、endpoint、許可host/path/method、token audience/scope、resource authorization、response処理、anomaly判定、修復責任を一続きにする必要がある。

インシデント対応で「漏えいしたトークンを探せ」と指示しても、見つからないことがある。トークンが安全だったからである。

それでも、利用者のセッションから本来望まれていない操作が完了している。注入されたコードはcredentialを読まず、正規frontendが使うAPIを呼んだ。ブラウザはHttpOnly Cookieを自動送信し、BFFはsessionをaccess tokenに結び直し、resource serverは要求を処理した。

これは防御の失敗を言い換えただけではない。トークンが盗まれなかったという成果と、クライアントが乗っ取られたという残余リスクは同時に成立する。

2026年8月にIETFのBest Current Practiceとして公開されたRFC 10017 OAuth 2.0 for Browser-Based Applicationsは、Aaron Parecki、Philippe De Ryck、David Waiteの共同著作である。2026年8月31日に保存したIETF Datatrackerでは、PareckiはSCIMワーキンググループの共同議長であり、RFC 10017を含む2件のRFCが記録される。本人サイトは、アイデンティティ標準の職務、oauth.netの管理、IETF OAuthへの参加を記している。

この履歴は貢献を示すが、規格の単独所有や各社BFFへの支配を示さない。実際の権限境界は、それぞれの運用コードと設定が作る。

攻撃者はすでに正規オリジンにいる

保存場所の比較だけでは脅威を捉え損なう。RFC 10017が置く前提は、XSS、外部スクリプトの侵害などにより、攻撃者がアプリケーションの実行環境でJavaScriptやWebAssemblyを動かせる状態である。

そのコードは外部の未知クライアントではない。正規コードと同じ権限で、利用可能なstorageを読み、functionを呼び、control flowを変え、同一オリジンcontextを操作し、backendへ要求を送る。文脈別encoding、依存関係の削減、Subresource Integrity、厳格なContent Security Policy、origin分離が重要なのは、この実行自体を止めることだけがclient hijackingの根本防止になるからである。

実行された後のOAuth固有リスクは四つに分かれる。現在のtokenを一度盗む。更新されるたび継続的に盗む。別のauthorization flowを起こして新しいtokenを得る。または、何も盗まず利用者のbrowserからrequestを送る。

最後の経路では、browserや補助componentがcredentialを自動付与する。non-exportableな保管は「持ち出せるか」を制限するが、「正規sessionの中で使えるか」を制限しない。

BFFが消すのは独立して持ち運べる権限

RFC 10017の三つの主要patternのうち、BFFは最も強いsecurity guaranteeを持つ。business、sensitive、personal dataを扱うapplicationには強く推奨される。BFF自身がconfidential clientとなり、Authorization CodeとPKCEを実行し、tokenを保持し、resource serverへのすべての通信をproxyする。

authorization serverとBFFの関係、browserとBFFのsession関係は別である。browserがprotected resourceを求めると、Cookie付きrequestをBFFへ送る。BFFはsessionからtokenを取り出し、Cookieを外向きrequestから除き、正しいaccess tokenを付けてresource serverへ送る。

これにより既存tokenの単発・継続窃取は成立しない。悪意あるcodeが新しいauthorization codeを得ても、confidential client credentialがないため交換できず、PKCEもcode transactionを守る。HttpOnlyはsession stateの直接読み出しを防ぎ、client hijackingがそのままportableなsession hijackingになるのを防ぐ。

一方、利用中のbrowserはsessionを送信できる。悪意あるcodeは正規frontendと区別できない形でendpointを呼び出す。BFFは「悪意」を判定する装置ではなく、browserに独立使用可能なtokenを渡さず、呼び出せる面をserver側で狭める装置である。

Proxyの出口は列挙されなければならない

BFFは、session付きの内向きrequestをtoken付きの外向きrequestへ翻訳する。この翻訳先が入力によって自由に変わるなら、attacker-controlled hostへtokenを送るopen proxyになる。

RFC 10017はdestination hostの検証、approved resource serverの明示allowlist、dynamic routeの厳格なhost/path検証をMUSTとしている。endpoint単位のHTTP method制限もattack surfaceを減らす。閲覧routeが、受け取ったmethodをそのまま転送して削除routeになってはならない。

hostだけでは十分でない。同じdomainに利用者APIと管理APIが置かれることがある。body内URLやredirectが最初のhostチェック後に境界を越えることもある。再現可能な許可tupleはscheme、host、path template、method、request schema、redirect規則、token audience、scope、response classまで持つ。

resource serverも独立したprincipalである。issuer、audience、expiry、permissionを検証し、具体的なobjectとoperationを認可する。広いtokenと広いproxy routeは乗っ取りの範囲を拡大する。狭いrouteとobject-level authorizationは、同一オリジンのcodeが行える操作を実務上の必要範囲へ戻す。

共通規格がすべての企業のendpoint mapを決める必要はない。Minimum Initial Specificationは、confidential client、保護Cookie、CSRF防御、bounded proxyという共通層を与える。local operatorは自分のhost/path/method/scopeを明示しなければならない。

Cookieはsessionを守るが意図を証明しない

RFCはCookieのSecureとHttpOnlyを必須とし、SameSite=Strict、path /、Domainを設定しないこと、可能なら__Host-Http-のようなprefixを推奨する。client-side sessionにtokenが含まれる場合は、disk上に平文を残さないため暗号化すべきである。

これらはscript読取、非TLS送信、subdomain共有、local fileからのtoken露出といった具体的故障を防ぐ。しかしrequestが人の現在の意図かどうかは証明しない。

Cookie authenticationにはCSRF対策が必要である。SameSite=Strictでも、同一のregistrable domainにある二つのsubdomainはsame-siteかつcross-originになり得る。兄弟subdomainのtakeoverは別のBFFにforgeryを送る経路を作る。

CORSを使うならpreflightを強制する必要がある。safelisted requestはresponseの読取が拒否されてもrequest自体は送られる。RFCはcustom headerを推奨し、その方式を採用した場合は全incoming requestでheaderを検証するよう求める。frameworkのanti-forgery／double-submitも別の選択肢になる。

CSRFは外部originと正規originを分ける。すでに正規origin内で動くmalicious codeは、その境界の内側にいる。CSRF成功をuser intentと記録してはならない。

残る権限は実行テストで測れる

client hijackingはdirect token theftより弱い。attackerはbrowser、active session、BFF route、client policy、resource policyに拘束される。別originへのCORS、露出していないroute、object-level denyが実際に被害を小さくする。

ただしarchitecture diagramはその拘束を証明しない。各endpointから到達するhost、path、method、選択token、audience、scope、object rule、returned dataをversion付きでinventory化し、controlledなsame-origin hostile codeから許可外の組合せを試す必要がある。

BFFは全proxy trafficを観測できるため、rate limitingとanomaly detectionにも適している。人の操作速度を超えるburst、通常と異なるendpoint順序、広いobject集合、無効refresh token後も続くsessionは調査対象になる。

同時にprivacy集中点でもある。第三者運用のBFFはfrontendとresource server間のrequest/responseを見られる。data minimization、retention、tenant isolation、operator accessはtoken保護と同じ設計面に置くべきである。

session lifetimeはrefresh tokenの最大寿命に合わせ、active sessionのrefresh tokenが無効ならsessionも無効にするのがRFCの指針である。server-side sessionは直接revocationしやすいがstate replicationが必要で、client-side sessionはscaleしやすいがtoken expiry/revocationへの依存が強い。

Requestから決定までのreceiptを残す

raw token、client secret、完全なCookieをlogしてはならない。auditのために新しいcredential漏えいを作る必要はない。

sensitive actionごとに、再利用不能なsession correlation ID、作成とexpiry、Cookie policy、authentication event、code transaction、BFF client identity、frontend buildを残す。incoming endpoint、normalized method/path template、CSRF/origin/CORS判定、schema validationを結ぶ。

外向きにはresource server、path、method、allowlist version、non-secret token fingerprint、issuer、audience、scope、expiryを記録し、関係するrefresh/rotation/revocation eventも保持する。最後にresource authorization、status、response変換、rate-limit/anomaly判定、change owner、remediationを結ぶ。

このreceiptがあれば、token exfiltration、opaque session theft、CSRF、same-origin abuse、proxy escape、downstream over-authorizationを区別できる。ownerとrepairが異なる故障を一つの「不正アクセス」に潰さずに済む。

Running-Code Primacyの試験は明快である。管理されたhostile scriptをorigin内で動かし、token/sessionを読めず、新しいflowを完成できず、approved host/path/methodを越えず、object authorizationを破れず、許可されているが異常な行動には理解可能なalertとreceiptが残ることを確認する。

BFFの成功は、tokenが外へ出ないことと、残るrequest authorityが狭く、観測でき、取り消せることの両方で決まる。

参照資料