Zusammenfassung

  • RFC 10017 erschien im August 2026 als Best Current Practice der IETF. Für geschäftliche und sensible Anwendungen sowie solche mit personenbezogenen Daten empfiehlt das Dokument ein Backend for Frontend besonders nachdrücklich, weil OAuth-Token nicht in Browser-Code gelangen.
  • Das BFF mindert einmaligen und fortlaufenden Token-Diebstahl sowie die Beschaffung frischer Token. Schadcode desselben Ursprungs kann jedoch weiterhin cookiegestützte Anfragen senden. Der Nachweis sicherer Verwahrung ist kein Nachweis beabsichtigter Handlungen.

Ein Vorfall ohne verschwundenes Geheimnis

Der Einstieg ist ein konstruiertes Analyseszenario und kein Bericht über einen veröffentlichten Sicherheitsvorfall. Er trennt zwei Fragen, die in einer Untersuchung leicht ineinanderfallen: Wo befanden sich die Anmeldeinformationen? Und welche Handlung konnte der authentisierte Kontext auslösen? Die erste Antwort kann vollständig beruhigend sein, während die zweite einen realen Schaden zeigt.

RFC 10017 setzt an der Privilegiengrenze des Browsers an. Bösartiges JavaScript, das innerhalb des Anwendungsursprungs ausgeführt wird, ist dort kein nachrangiger Mandant. Es kann Seitendaten beobachten, Ursprungsspeicher verwenden, mit gleichursprünglichen Kontexten interagieren und Anforderungen an Backends senden. Eine kompromittierte Abhängigkeit braucht keine geheime Zeichenfolge zu kopieren, wenn Browser und Server bereitstehen, die zugehörige Befugnis für sie auszuüben.

Das Dokument unterscheidet vier für OAuth relevante Szenarien: den einmaligen Diebstahl vorhandener Token, ihre fortlaufende Entnahme während der Rotation, die Gewinnung neuer Token durch einen weiteren Autorisierungsablauf und die Weiterleitung von Anforderungen durch den Browser des Opfers. Die vierte Möglichkeit erklärt, warum alle Token an ihrem vorgesehenen Ort liegen können und dennoch eine unerwünschte Transaktion erfolgt.

Für das BFF kann eine von Schadcode ausgelöste Anforderung genauso aussehen wie eine legitime. Beide stammen aus dem erwarteten Ursprung, beide veranlassen den Browser zum Mitsenden des Cookies und beide können das richtige Anforderungsformat besitzen. Fügt das BFF danach das Zugriffstoken hinzu, tut es dies auch für die fremdveranlasste Anfrage, sofern keine weitere Regel die Aktion unterscheidet.

„Kein Token-Diebstahl“ ist deshalb eine eng begrenzte Feststellung. Sie belegt, dass ein Bearer-Wert die Verwahrung nicht verlassen hat und nicht von einem anderen Rechner wiederholt werden kann. Offen bleiben die Absicht der Sitzung, die Reichweite des Proxy-Routenplans und die Geschäftsregel des Ressourcendienstes.

Das BFF verändert die Folgen des Angriffs

Ein Backend for Frontend tritt als vertraulicher OAuth-Client auf. Es hält Zugriffs- und Aktualisierungstoken auf dem Server, ordnet dem Browser eine cookiegestützte Sitzung zu und leitet Ressourcenanforderungen nach Auswahl des passenden Tokens weiter. Der Browser sieht die Sitzungsoberfläche, nicht das Tokenmaterial.

Das ist ein erheblicher Sicherheitsgewinn. Im Browser liegt kein Zugriffstoken zum Kopieren. Der Schadcode kann die Rotation des Aktualisierungstokens nicht verfolgen und einen neuen Autorisierungscode nicht ohne die vertraulichen Zugangsdaten des BFF einlösen. RFC 10017 bewertet damit die ersten drei Szenarien als wirksam gemindert und empfiehlt die Architektur für Anwendungen mit hohen geschäftlichen, persönlichen oder regulatorischen Auswirkungen.

Die browservermittelte Anfrage bleibt möglich. HttpOnly verhindert das Lesen des Sitzungscookies, nicht aber seine automatische Verwendung durch den Browser. Schadcode desselben Ursprungs ruft das BFF auf; der Browser fügt das Cookie an; das BFF findet die Sitzung, wählt das Token und leitet weiter. Kein Geheimnis wird dabei für den Schadcode sichtbar.

Der Gewinn besteht darin, den Angreifer auf das zu begrenzen, was Sitzung, Routen und Ressourcenregeln zulassen. Eine Übernahme des Clients wird nicht ohne Weiteres zu einer transportablen, anderswo wiederverwendbaren Berechtigung. Sie macht jedoch nicht jedes Codefragment im Ursprung zu einem vertrauenswürdigen Akteur.

Diese Abgrenzung ermöglicht eine sachliche Architekturbewertung. Das BFF ist nicht wertlos, weil Client-Hijacking übrig bleibt. Es ist aber auch kein vollständiger Autorisierungsnachweis. Der richtige Prüfmaßstab lautet, welche konkrete Konsequenz es verhindert und welche Entscheidung weiterhin an anderer Stelle getroffen werden muss.

Ein unlesbares Cookie bleibt wirksam

Der BCP verlangt für BFF-Cookies Secure und HttpOnly. Zusätzlich empfiehlt er SameSite=Strict, den Pfad /, keinen Domain-Parameter und nach Möglichkeit ein hostgebundenes Präfix. Diese Eigenschaften begrenzen Übertragungsexposition, Skriptzugriff und zu breite Freigabe über Subdomains.

Sie belegen keine Nutzerabsicht. Cookiegestützte BFF-Interaktionen brauchen eine belastbare CSRF-Abwehr. SameSite kann helfen, doch Geschwister-Subdomains gehören trotz unterschiedlicher Ursprünge zur selben Site. Wird eine solche Subdomain übernommen, kann ein Weg entstehen, den eine oberflächliche SameSite-Prüfung für geschlossen hielt.

Auch CORS ist nur mit konkreten Tests aussagekräftig. Bestimmte safelisted Anforderungen werden ohne Preflight gesendet; der Browser kann lediglich die Antwort vor dem fremden Ursprung verbergen, während die Wirkung bereits eingetreten ist. Ein verpflichtender eigener Header kann einen Preflight erzwingen. Die Prüfung muss aber zeigen, dass ausnahmslos jeder zustandsverändernde Endpunkt Anforderungen ohne diesen Header zurückweist.

Hinzu kommen unterschiedliche Uhren. Browser-Sitzung, Aktualisierungstoken und Ressourcenberechtigung haben Ausgabe-, Ablauf- und Widerrufszeitpunkte. Eine scheinbar aktive Sitzung nach Ablauf des Aktualisierungstokens erzeugt einen irreführenden Zustand. Ein widerrufenes Token ohne Zuordnung zu den Sitzungen lässt unklar, welche Browser-Fähigkeit tatsächlich beendet wurde.

Die belastbare Spur verbindet Ausgabe, Erneuerung, Ablauf, Abmeldung und Widerruf. Solange das BFF ein geschütztes Cookie akzeptiert, ist es kein passives Geheimnis, sondern ein aktiver Träger von Sitzungsbefugnis.

Der Proxy-Routenplan ist eine Autorisierungsfläche

Das BFF ist mehr als ein Tresor. Es übersetzt eine eingehende, per Cookie authentisierte Anforderung in einen ausgehenden, per Bearer-Token autorisierten Aufruf. Zielhost, Pfad und Methode legen fest, welche Befugnis die Sitzung ausgeben kann.

RFC 10017 fordert strenge ausgehende Kontrollen. Zielhosts müssen erlaubt sein, dynamische Pfadbestandteile geprüft und Methoden je Endpunkt begrenzt werden. Ein offener oder zu dynamischer Proxy kann ein gültiges Token an den falschen Host schicken oder eine Ressourcenoperation erreichbar machen, die die Benutzeroberfläche nie anbieten sollte.

Eine Route wie /bff/zahlungen/{id} ist daher keine bloße Leitung. Sie entscheidet, ob eine Sitzung nur lesen oder auch stornieren, erstatten und ändern darf und welche Kennungen zulässig sind. Der Ressourcendienst muss weiterhin Zielgruppe, Umfang, Subjekt und handlungsspezifische Geschäftsregel prüfen. Eine korrekte Weiterleitung rechtfertigt nicht automatisch den endgültigen Effekt.

Die beobachtete Wirkung vervollständigt den Datensatz. Das BFF kann eine erfolgreiche Antwort notieren, obwohl ein nachgelagerter Prozess später ablehnt. Wiederholungen können doppelte Effekte erzeugen. Viele Benutzer teilen möglicherweise eine Ausgangsadresse, sodass rein IP-basierte Ratenbegrenzung das Verhalten falsch einordnet. Anforderungskennung, Sitzung, Routenentscheidung, Token-Zielgruppe, Ressourcenentscheidung und Endzustand brauchen eine gemeinsame Korrelation.

Auch die Datenschutzgrenze verschiebt sich. Das BFF sieht alle weitergeleiteten Anforderungen und Antworten. Ein externer Betreiber reduziert zwar die Token-Exposition im Browser, erhält aber breite Einsicht in Aktivität und Inhalte. Schutz der Zugangsdaten und Datenminimierung sind zwei getrennte Entscheidungen.

Drei Architekturen bewahren unterschiedliche Spuren

Der BCP vergleicht ein vollständiges BFF, ein tokenvermittelndes Backend und einen reinen Browser-Client. Beim BFF verbleiben beide Tokenarten auf dem Server, der alle Ressourcenaufrufe weiterleitet. Der Vermittler bewahrt vertrauliche Client-Daten und Aktualisierungstoken, gibt Zugriffstoken aber an den Browser zurück. Beim Browser-Client finden OAuth-Ablauf und Tokenhaltung vollständig im Laufzeitkontext statt.

Der Vermittler hat ein anderes Risikoprofil. Er schützt Erneuerungsfähigkeit und Codeaustausch, doch das Zugriffstoken ist für die kompromittierte Browser-Umgebung wieder erreichbar. Dessen Diebstahl und die unmittelbare Nutzung bleiben möglich. Die Architektur sollte anhand des tatsächlichen Datenflusses bewertet werden, nicht anhand der Nähe ihres Namens zum Backend.

Der reine Browser-Client ist allen vier Szenarien ausgesetzt. Authorization Code mit PKCE ist vorgeschrieben. Aktualisierungstoken müssen rotieren oder sendergebunden sein und eine maximale oder inaktivitätsbezogene Lebensdauer haben. Das begrenzt Abfangen und Fortdauer, isoliert aber keinen Schadcode, der bereits im legitimen Ursprung läuft.

DPoP liefert eine weitere begrenzte Sicherung. Ein an einen nicht exportierbaren Schlüssel gebundenes Token lässt sich außerhalb des Geräts schwerer verwenden. Browservermittelte Anforderungen verhindert das nicht. Kann der Schadcode einen neuen Ablauf beginnen, kann er versuchen, die neuen Token an einen eigenen Schlüssel zu binden. „Sendergebunden“ ist daher nur aussagekräftig, wenn Senderkontext, Schlüssel und Entstehungsablauf feststehen.

Nicht jede Anwendung unter einer gemeinsamen Domain benötigt OAuth zwischen Frontend und API. Wenn beide zu einer einzigen Anwendung gehören und kein unabhängiger Ressourcenakteur existiert, kann eine föderierte Anmeldung mit anschließender eigener Sitzung die Beziehung klarer abbilden. OAuth ohne echte Vertrauensgrenze kann Token- und Proxyflächen hinzufügen, ohne Zuständigkeiten zu trennen.

Die Aussage darf nicht breiter sein als der Mechanismus

RFC 10017 ist gerade deshalb wertvoll, weil es kein Browser-Enklave verspricht. Das Dokument ordnet Angriffe und weist Kontrollen bestimmten Folgen zu. Ein BFF ist eine starke lokale Antwort auf Token-Exposition. Es erklärt weder sämtlichen Ursprungscode für vertrauenswürdig noch jede Anforderung zum Ausdruck des Nutzerwillens.

Eine belastbare Betriebsakte hält Code- und Abhängigkeitsherkunft, Ursprung, Sitzungsausgabe und -ablauf, Cookie-Eigenschaften, Zeit, Methode, Pfad und Body-Klasse, CSRF- und CORS-Ergebnis, BFF-Zuordnung, Token-Zielgruppe und -Umfang, Ressourcenentscheidung, Antwort, Geschäftswirkung und Rückabwicklungsverantwortlichen fest. Diese Fakten besitzen unterschiedliche Uhren und Eigentümer.

So bleibt die gemeinsame Koordination schmal. Die BCP setzt einen Mindeststandard und beschreibt Optionen; lokale Betreiber entscheiden über Abhängigkeiten, Routen, Schwellenwerte, Beobachtung und Umkehrbarkeit. Laufender Code und tatsächlich beobachtete Anforderungen wiegen schwerer als ein Architekturdiagramm mit der Bezeichnung BFF.

Die Organisation, die Betrug, Datenschutzverlust und Ausfall trägt, muss die letzte Entscheidung darüber behalten, welche Aktion angenommen, überwacht, gestoppt und rückgängig gemacht wird. Token auf dem Server zu halten, ist ein wichtiger Teil. Die Befugnis der Sitzung eng zu halten, ist der andere.

Quellen