Zusammenfassung

  • Der BFF in RFC 10017 ist der vertrauliche OAuth-Client. Er verwaltet Access- und Refresh-Token hinter einer Cookie-Sitzung und ergänzt ausgehende Ressourcenaufrufe. Im Browser liegt deshalb kein vorhandenes Token zum Extrahieren; ein neuer Authorization Code lässt sich ohne Client-Credentials nicht eigenständig tauschen.
  • Bösartiger Code in der legitimen Origin kann weiterhin einen Endpoint aufrufen, den auch das Frontend aufruft. Der Browser sendet die Sitzung, der BFF übersetzt sie in einen tokenbewehrten Aufruf. Das verbleibende Client-Hijacking ist schwächer als direkter Tokendiebstahl, aber so breit wie die tatsächlich erreichbaren Aktionen.
  • Der belastbare Beleg verbindet Origin und Build, Sitzung und Cookie-Policy, CSRF-Ergebnis, Endpoint, erlaubten Host/Pfad/Methode, Audience und Scopes, Autorisierung des Ressourcenservers, Antwortbehandlung, Anomalieentscheidung und Abhilfe.

Der Bericht klingt zunächst beruhigend: kein Token im Web Storage, kein Refresh Token im Heap, HttpOnly gesetzt. Dann folgt die eigentliche Feststellung: Der eingeschleuste Code konnte trotzdem eine geschützte Operation ausführen.

Er brauchte kein Credential zu kopieren. Er lief in derselben Origin wie das Frontend, stellte einen zulässigen Request zusammen und überließ dem Browser und dem BFF die Autorisierungskette. Der Browser fügte das Cookie hinzu, der BFF wählte das Access Token, der Ressourcenserver verarbeitete die Aktion.

RFC 10017 trennt diesen Ablauf bewusst vom Tokendiebstahl. OAuth 2.0 for Browser-Based Applications erschien im August 2026 als IETF Best Current Practice von Aaron Parecki, Philippe De Ryck und David Waite. Das am 31. August 2026 gespeicherte IETF-Profil nennt Parecki als Co-Chair der SCIM-Arbeitsgruppe und führt zwei RFCs einschließlich RFC 10017. Seine eigene Website beschreibt seine Identitätsstandard-Rolle, die Pflege von oauth.net und die Beteiligung an der OAuth-Arbeitsgruppe.

Das ist eine begrenzte, überprüfbare Zuschreibung. Es ist kein Anspruch auf Alleinerfindung und keine Aussage über einen konkreten BFF. Dessen Grenze entsteht erst durch laufenden Code und lokale Policies.

Das Bedrohungsmodell beginnt nach der Codeausführung

Die Speicherfrage allein setzt voraus, dass der ausgeführte Code vertrauenswürdig ist. RFC 10017 untersucht den Zustand danach: XSS, eine kompromittierte Remote-Ressource oder ein anderer Fehler erlaubt JavaScript oder WebAssembly im Ausführungskontext der Anwendung.

Dieser Code besitzt dieselben Browserprivilegien wie die legitime Anwendung. Er liest zugänglichen Storage, ruft Funktionen auf, verändert den Kontrollfluss, interagiert mit Same-Origin-Kontexten und kontaktiert Backends. Kontextbezogenes Encoding, Kontrolle von Drittressourcen, Subresource Integrity, CSP und Origin-Isolation bleiben deshalb die primäre Verteidigung. Nur das Verhindern der Ausführung verhindert Client-Hijacking selbst.

Die RFC zerlegt den OAuth-Schaden in einmaligen und persistenten Tokendiebstahl, Erwerb eines neuen Tokensets und Proxying durch den Browser. Beim letzten Szenario wird nichts exportiert. Browser oder Hilfskomponente ergänzen das Credential automatisch. Nicht exportierbar bedeutet daher nicht: nicht aufrufbar.

Der BFF entfernt tragbare Autorität

Unter den drei Hauptarchitekturen bietet der BFF die stärksten Garantien und wird für geschäftliche, sensible sowie personenbezogene Anwendungen deutlich empfohlen. Der Server wird Confidential Client, führt Authorization Code mit PKCE aus, hält die Token und vermittelt sämtliche Ressourcenaufrufe.

Authorization Server und BFF bilden eine Tokenbeziehung. Browser und BFF bilden eine separate Sessionbeziehung. Beim Ressourcenaufruf sendet das Frontend das Cookie an den BFF; dieser löst Session State auf, entfernt das Cookie vom ausgehenden Request, hängt das passende Access Token an und ruft den Resource Server auf.

Damit verschwinden drei mächtige Angriffswege. JavaScript kann bestehende Token weder einmalig noch fortlaufend kopieren. Selbst ein neu abgefangener Code genügt ohne Confidential-Client-Credentials nicht für den Tausch; PKCE schützt die Code-Transaktion zusätzlich. HttpOnly verhindert direkten Zugriff auf Session State und damit die automatische Eskalation zu einer mitnehmbaren Sitzung.

Erhalten bleibt die Fähigkeit, erlaubte Endpoints im aktiven Browser zu nutzen. Der BFF entscheidet nicht, welcher von zwei gleich privilegierten Scripts guten Willen hat. Er entzieht dem Browser unabhängige Bearer-Autorität und bietet eine Stelle, an der der aufrufbare Rest begrenzt werden kann.

Der Autoritätsübersetzer braucht eine Ausgangsliste

Der BFF übersetzt einen eingehenden Request mit Session in einen ausgehenden Request mit Token. Ein frei wählbares Ziel macht ihn zum Token-Leak-Proxy.

RFC 10017 verlangt die Validierung von Destination Hosts, eine explizite Allowlist zugelassener Ressourcenserver und strenge Prüfung dynamischer Hosts und Pfade. Methodenbeschränkung pro Endpoint verkleinert die Oberfläche. Eine Leseroute darf nicht deshalb löschen, weil der Proxy jede eingehende HTTP-Methode übernimmt.

Ein Hostname ist zu grob. Nutzer- und Admin-API können dieselbe Domain teilen. Eine URL kann im Body stehen; ein Redirect kann die erste Prüfung umgehen. Die reproduzierbare Policy umfasst Scheme, Host, Pfadtemplate, Methode, Request-Schema, Redirect-Regel, Token-Audience, Scopes und Response-Klasse.

Der Resource Server bleibt eigener Entscheidungsträger. Er prüft Issuer, Audience, Ablauf und Berechtigungen und autorisiert Objekt und Operation. Ein breites Token plus allgemeine Proxyroute macht Hijacking weitreichend. Enge Routes plus objektbezogene Autorisierung erhalten die Trennung zwischen angemeldeter Session und universellem Mandat.

Minimum Initial Specification bedeutet hier: Die RFC liefert Confidential Client, geschütztes Cookie, CSRF-Abwehr und begrenzten Proxy. Den lokalen Endpoint- und Rechteplan muss der Betreiber ergänzen. „BFF-konform“ ist ohne diesen Plan keine Beschreibung der erreichbaren Macht.

Cookie-Härtung beweist keine Absicht

Secure und HttpOnly sind Pflicht. SameSite=Strict, Pfad /, kein Domain-Attribut und ein Präfix wie __Host-Http- werden empfohlen. Enthält eine clientseitige Sitzung Tokenmaterial, sollte sie verschlüsselt sein, damit dieses nicht im Klartext auf Disk liegt.

Diese Einstellungen beantworten konkrete Fragen: Lesbarkeit durch Script, unsicherer Transport, Subdomain-Zugriff und Dateizugriff. Keine beantwortet, ob die Person den einzelnen Request beabsichtigte.

Cookie-Authentifizierung erfordert CSRF-Abwehr. SameSite=Strict genügt nicht immer, weil verschiedene Subdomains same-site und zugleich cross-origin sind. Eine übernommene Schwester-Origin kann einen Forgery-Pfad eröffnen.

CORS hilft, wenn ein Preflight erzwungen wird. Safelisted Requests können gesendet werden, auch wenn die Response später nicht lesbar ist. Die RFC empfiehlt deshalb einen Custom Header und verlangt bei dieser Methode dessen Prüfung in jedem Request. Framework-Anti-Forgery ist eine Alternative.

CSRF trennt fremde und legitime Origin. Schädlicher Code, der bereits in der legitimen Origin läuft, befindet sich auf der akzeptierten Seite. Ein bestandener CSRF-Check ist kein Beleg menschlicher Absicht.

Die verbleibende Aktionsfläche lässt sich testen

Client-Hijacking ist weniger mächtig als Tokenbesitz. Der Angreifer hängt an Browser und Session und bleibt durch BFF-Routes, CORS und Ressourcenautorisierung eingeschränkt. Ein nicht exponierter Endpoint oder Object-Level-Deny kann die Aktion stoppen. Die RFC wahrt diese Differenz.

Sie muss praktisch nachgewiesen werden. Ein versioniertes Inventar ordnet jedem Endpoint Host, Pfad, Methode, Token, Audience, Scopes, Objektregel und Response-Daten zu. Danach versucht kontrollierter Same-Origin-Schadcode jede nicht zugelassene Kombination. Ein erfolgreicher Login ist kein Grenztest.

Der BFF sieht den gesamten vermittelten Verkehr. Rate Limits und Anomalieerkennung können unnatürliche Bursts, seltene Endpoint-Sequenzen, ungewöhnliche Objektmengen oder eine Sitzung nach ungültigem Refresh Token erkennen. Die Sichtbarkeit bringt zugleich Privatsphärepflichten, besonders bei Drittbetrieb: Minimierung, Retention, Tenant-Isolation und Operatorzugriff gehören in die Policy.

Die Sitzungsdauer soll der darunterliegenden Autorität folgen. Die RFC empfiehlt, sie an die maximale Refresh-Token-Laufzeit zu koppeln und bei dessen Ungültigkeit zu beenden. Server-Sessions erleichtern direkte Revocation, kosten aber State-Replikation; Client-Sessions skalieren leichter und hängen stärker an Tokenablauf und -widerruf.

Einen Beleg ohne neue Geheimnisse bauen

Raw Token, Client Secret und vollständiges Cookie gehören nicht ins Log. Stattdessen: nicht wiederverwendbare Session-Korrelation, Erstellung und Ablauf, Cookie-Policy, Authentisierung, Code-Transaktion, BFF-Clientidentität und Frontend-Build.

Dazu kommen eingehender Endpoint, normalisierte Methode und Pfadtemplate, CSRF/Origin/CORS-Ergebnis und Schema-Prüfung. Für die Übersetzung: Resource Server, ausgehender Pfad und Methode, Allowlist-Version, nicht geheime Token-ID oder Fingerprint, Issuer, Audience, Scopes, Ablauf und relevante Refresh-/Rotation-/Revocation-Ereignisse.

Den Abschluss bilden Ressourcenentscheidung, Status, Antworttransformation, Rate-Limit-/Anomalieentscheidung, Change Owner und Remediation. Damit bleiben Tokenexfiltration, Sessiondiebstahl, CSRF, Same-Origin-Missbrauch, Proxy Escape und zu breite Downstream-Rechte getrennte Fehler mit getrennten Eigentümern.

Running-Code Primacy liefert den Test: kontrollierten schädlichen Code in der Origin ausführen und beweisen, dass er Token/Session nicht lesen, keinen unabhängigen Flow abschließen, den Host/Pfad/Methoden-Raum nicht verlassen und Objektregeln nicht durchbrechen kann; ungewöhnliche erlaubte Aktionen müssen einen verständlichen Alert hinterlassen.

Der BFF besteht, wenn das Token nicht hinausgelangt und die verbleibende Request-Autorität eng, sichtbar und widerrufbar ist.

Quellen