Backend for Frontend: Die 4 größten Missverständnisse bei der Umsetzung

Das Backend-for-Frontend (BFF)-Muster wird oft falsch verstanden – besonders in puncto Sicherheit. Viele Entwickler setzen es ein, um Authentifizierung zu vereinfachen, doch dabei entstehen häufig gravierende Lücken. Statt Sicherheit zu erhöhen, wird sie in manchen Fällen sogar geschwächt. Welche Mythen sich hartnäckig halten und wie Sie das BFF-Pattern korrekt implementieren, lesen Sie hier.

PKCE schützt nicht vor XSS – warum BFF unverzichtbar ist

Nach der Empfehlung der OAuth Working Group und OAuth 2.1 soll PKCE (Proof Key for Code Exchange) die veraltete Implicit-Grant-Funktion ersetzen. Das ist richtig – doch viele Entwickler ziehen daraus den falschen Schluss, dass PKCE allein ausreicht, um Tokens sicher zu verwalten.

PKCE sichert ausschließlich den Autorisierungscode während der Übertragung. Es verhindert, dass Angreifer den Code abfangen und gegen Tokens eintauschen können. Doch sobald die Tokens im Browser landen, ist PKCE wirkungslos. In localStorage, sessionStorage oder sogar im JavaScript-Speicher sind Tokens für schädlichen Code zugänglich – etwa durch XSS-Angriffe (Cross-Site Scripting).

Hier setzt das BFF-Muster an: Es hält Tokens komplett aus dem Browser heraus. Der BFF-Server tauscht den Autorisierungscode gegen Tokens aus und speichert sie serverseitig. Der Browser erhält stattdessen ein `HttpOnly`-Session-Cookie, das von JavaScript nicht ausgelesen werden kann. Selbst bei einem XSS-Angriff bleibt der Angreifer ohne Zugriff auf die Tokens.

Fazit: PKCE und BFF ergänzen sich – sie sind keine Alternativen. Wenn Ihr Threat Model (Bedrohungsanalyse) XSS berücksichtigt – und das sollte es –, ist PKCE allein nicht ausreichend.

BFF ist mehr als nur ein Proxy – warum falsche Implementierungen riskant sind

In der Praxis stoße ich immer wieder auf Architekturen, die fälschlich als „BFF“ bezeichnet werden, in Wahrheit aber nur Reverse Proxys sind. Diese leiten Anfragen (und Tokens) einfach an einen Backend-Server weiter – ohne die eigentlichen Sicherheitsvorteile des BFF-Musters zu nutzen.

Der entscheidende Unterschied: Ein echter BFF ist ein vertraulicher OAuth-Client. Er besitzt ein Client Secret, führt den vollständigen OAuth-Flow aus und stellt sicher, dass Tokens niemals den Server verlassen. Tokens werden stattdessen serverseitig gespeichert und über sichere Cookies an den Browser übergeben.

Ein Reverse Proxy, der ein Bearer Token im Authorization-Header an den Browser weiterleitet, ist kein BFF. Der Browser bleibt in diesem Fall weiterhin exponiert – Sie haben lediglich einen zusätzlichen Netzwerk-Hop eingeführt, ohne die Sicherheit zu erhöhen.

Die IETF-Empfehlung (Internet Engineering Task Force) unterscheidet klar zwischen:

• Token-vermittelndem Backend (Tokens werden vom Backend abgerufen und an den Frontend weitergegeben)
• echtem BFF (Tokens bleiben komplett serverseitig)

Beide Ansätze haben unterschiedliche Sicherheitsimplikationen. Wenn Ihr System Tokens an den Browser übergibt, haben Sie kein BFF implementiert – sondern nur eine Token-Mediation, die zwar besser ist als nichts, aber nicht die gleichen Schutzmechanismen bietet.

Warum HttpOnly-Cookies sicherer sind als Tokens im Browser

Der Glaube, dass Cookies unsicherer seien als Tokens, stammt aus veralteten Sicherheitsbedenken. Historisch waren Cookies anfällig für CSRF-Angriffe (Cross-Site Request Forgery), bevor SameSite-Attribute zum Standard wurden. Zudem galt im REST-API-Design die Zustandslosigkeit als Dogma – ein Ansatz, der heute kritisch hinterfragt wird.

Doch die moderne Realität sieht anders aus:

• `HttpOnly`-Cookies können nicht von JavaScript ausgelesen werden. Selbst bei einem XSS-Angriff bleibt das Cookie geschützt.
• Tokens in `localStorage` sind für jeden Skript auf der Seite zugänglich. Ein erfolgreicher XSS-Angriff ermöglicht dem Angreifer den vollen API-Zugriff in Namen des Nutzers – ohne weitere Interaktion erforderlich.

Auch bei CSRF ist das Risiko bei HttpOnly-Cookies deutlich geringer:

• Mit SameSite=Strict oder SameSite=Lax sind CSRF-Angriffe in den meisten Szenarien bereits praktisch ausgeschlossen.
• Durch zusätzliche CSRF-Tokens wird das Risiko weiter minimiert.

Zusammenfassung: Die Angriffsfläche von HttpOnly-Cookies ist kleiner als die von Tokens in localStorage. Sie tauschen zwar ein potenzielles Risiko (CSRF) gegen ein anderes (XSS-basierte Token-Diebstähle) – doch die meisten Anwendungen profitieren von diesem Trade-off.

BFF löst nicht alle Authentifizierungsprobleme – diese Punkte müssen Sie selbst sichern

Das BFF-Muster verschiebt die Sicherheitsgrenzen, beseitigt sie aber nicht. Statt Tokens aus dem Browser zu stehlen, müssen Sie nun die Server-seitige Session-Verwaltung absichern. Das bringt neue Verantwortlichkeiten mit sich – die nicht automatisch vom BFF übernommen werden.

Diese Sicherheitsaspekte müssen Sie zusätzlich konfigurieren:

• CSRF-Schutz: Auch wenn SameSite-Cookies helfen, benötigen Sie explizite CSRF-Tokens für zustandsverändernde Anfragen (z. B. POST, PUT, DELETE).
• Session-Invalierung: Ein Nutzer-Logout muss serverseitig erfolgen – das bloße Löschen eines Cookies reicht nicht aus. Andernfalls bleiben gestohlene Session-Cookies bis zum Ablauf gültig.
• Sichere Cookie-Einstellungen:
• Secure (nur über HTTPS)
• HttpOnly (nicht per JavaScript auslesbar)
• SameSite (empfohlen: Strict oder Lax)

Ein fehlerhaft konfigurierter BFF kann zu neuen Schwachstellen führen. Beispiel: Fehlt das HttpOnly-Flag, ist das Session-Cookie trotz BFF angreifbar. Oder wird die Session nicht korrekt invalidiert, kann ein Angreifer mit einem gestohlenen Cookie weiterhin auf das System zugreifen.

Abschließender Hinweis: Das BFF-Muster ist ein mächtiges Werkzeug – aber nur, wenn es richtig eingesetzt wird. Bevor Sie es in Ihrer Anwendung einführen, prüfen Sie Ihr Threat Model und stellen Sie sicher, dass alle Sicherheitsmechanismen korrekt implementiert sind. Die Technologie allein schützt nicht vor Fehlkonfigurationen – sie schafft nur die Grundlage für eine robuste Authentifizierung.