Referenzarchitektur Frontend

Darstellung der Frontends in der softwaretechnischen Architektur inklusive Security zeigt die softwaretechnische Darstellung von Frontends in einer Anwendungslandschaft. Im Vergleich zur allgemeinen Darstellung der softwaretechnischen Referenzarchitektur geht die folgende Abbildung näher auf die bereits in der Einführung erwähnte Verteilung von Frontend und Backend ein.

Durch die Verwendung von SPAs befindet sich der Frontend-Teil der GA im Webbrowser des Anwenders, während der Backend-Teil weiterhin auf den Servern der Anwendungslandschaft betrieben wird. Zur strukturierten, sicheren und einheitlichen Anbindung der Frontends an die Backend-Systeme ist verpflichtend, ein zentrales API-Gateway als querschnittliche Komponente vorzuschalten. Das API-Gateway ist ein Bestandteil der Systemlandschaft und wird in der software-technischen Referenzarchitektur detailliert beschrieben.

Darstellung der Frontends in der softwaretechnischen Architektur mit der Variante BFF zeigt eine Variante für die Darstellung von SPAs in der softwaretechnischen Referenzarchitektur unter Verwendung eines Backend-for-Frontend (BFF).

Dabei wird eine zusätzliche Anwendung zwischen Backend und Frontend auf der Serverseite vorgesehen, um das Backend über eine spezifische API vom Frontend zu entkoppeln. Diese Vorgehensweise erhöht zunächst die Komplexität, ist jedoch ein bewährtes Muster, um folgende Herausforderungen zu lösen:

Die Architekturvariante Native Federation beschreibt eine modularisierte Single Page Application (SPA), bei der fachlich abgegrenzte Anwendungsdomänen (z. B. „Suche“, „Fallbearbeitung“, „Administration“) als eigenständig lieferbare Frontend-Komponenten umgesetzt und zur Laufzeit durch eine zentrale Anwendungskomponente (Shell) integriert werden.

Im Unterschied zu einer „einfachen“ SPA (ein Build-Artefakt, ein Deployment) erlaubt diese Variante getrennte Build- und Bereitstellungsprozesse je Komponente und reduziert damit Kopplungseffekte zwischen Organisationseinheiten und Liefergegenständen (Artefakten).

Die erhöhte Komplexität ist gerechtfertigt, wenn organisatorische oder technische Rahmenbedingungen eine Modularisierung erfordern; insbesondere dann, wenn mehrere Organisationseinheiten oder Auftragnehmer parallel an derselben Anwendung arbeiten und unabhängige Release-Zyklen bzw. Freigaben benötigt werden.

Native Federation ist sinnvoll, wenn mehrere der folgenden Entscheidungskriterien erfüllt sind:

Sind diese Voraussetzungen nicht gegeben (z. B. nur ein bis zwei Teams, gemeinsamer Freigabezyklus, hohe funktionale Verflechtung), ist eine einfache SPA oder ein modular strukturierter Monolith (klare Modulgrenzen innerhalb eines gemeinsamen Build-Artefakts) in der Regel wirtschaftlicher und risikoärmer.

Native Federation ist somit kein Standardvorgehen, sondern eine gezielte Architekturentscheidung zur Skalierung von Organisation, Lieferfähigkeit und Modernisierungsfähigkeit bei großen, langfristig betriebenen Anwendungen.

Frontends authentifizieren Nutzer über den zentralen IAM-Service der Systemlandschaft. Die übergreifenden Vorgaben zu OAuth 2.0, IAM-Service und Autorisierungsinformationen sind in der Referenzarchitektur Sicherheit festgelegt. Die folgenden Vorgaben schärfen diese für SPAs.

HTTP-Response-Header sind die primäre Maßnahme des Browsers zum Schutz vor Clickjacking, Cross-Site-Scripting (XSS) und verwandten Angriffen. Sie MÜSSEN serverseitig gesetzt werden – entweder durch den Webserver/Reverse Proxy, der das Frontend ausliefert, oder durch ein vorgelagertes API-Gateway.

CORS (Cross-Origin Resource Sharing) und CSRF-Schutz werden primär serverseitig (API-Gateway, Backend) durchgesetzt. Das Frontend MUSS dennoch folgende Vorgaben einhalten.

Die übergreifenden Vorgaben zu TLS und Zertifikaten sind in der Referenzarchitektur Sicherheit normativ festgelegt. Die folgenden Vorgaben ergänzen diese für die Browser-Kommunikation.

Build-Artefakte von Frontends bestehen typischerweise aus zahlreichen Open-Source-Abhängigkeiten und sind daher besonders Supply-Chain-Risiken ausgesetzt. Die nachfolgenden Vorgaben korrespondieren mit AG-11: Verbindliche Integrationsverträge und Versionierung (Versionsbindung) und den Betriebs- und Sicherheitsanforderungen aus der Architekturvariante: Modularisierte Single Page Application mit Native Federation.

Die in HTTP-Sicherheits-Header & Cookies definierten Header (insbesondere CSP) reduzieren die Auswirkungen von XSS, ersetzen jedoch keine sichere Implementierung im Anwendungscode.

Bei Verwendung der Architekturvariante Native Federation (siehe Architekturvariante: Modularisierte Single Page Application mit Native Federation) werden zur Laufzeit Module aus separaten Bereitstellungen geladen. Daraus ergeben sich zusätzliche Sicherheitsanforderungen.

Das Frontend verarbeitet im Browser personenbezogene Daten, die den Anforderungen der DSGVO (insbesondere Art. 5 Abs. 1 lit. c – Datenminimierung) unterliegen. Da keine übergreifenden IsyFact-Vorgaben zu DSGVO existieren, sind die konkreten datenschutzrechtlichen Anforderungen im Berechtigungs- und Datenschutzkonzept der jeweiligen Systemlandschaft zu regeln. Die folgenden Vorgaben definieren den technischen Mindestrahmen.

Die Teststrategie legt fest, welche Eigenschaften eines Frontends auf welcher Teststufe abgesichert werden. Leitgedanke ist eine risikoorientierte Verteilung der Testfälle: Ein Fehler SOLL auf der niedrigsten Teststufe gefunden werden, auf der er feststellbar ist.

Die Teststufen unterscheiden sich in Realitätsnähe und Kosten: Je höher die Stufe, desto aussagekräftiger ist das Ergebnis, desto langsamer, störanfälliger und wartungsintensiver ist der Test jedoch auch. Eine Konzentration auf hohe Teststufen – insbesondere auf End-to-End-Tests – führt zu langen Rückmeldezeiten, instabilen Testläufen und hohen Wartungskosten und widerspricht dem Grundsatz Shift Left (siehe Grundsätze der Qualitätssicherung). Umgekehrt ersetzt eine hohe Abdeckung auf niedrigen Teststufen nicht den Nachweis, dass die Anwendung als Ganzes bedienbar ist.

Die Verteilung ist kein Selbstzweck, sondern folgt dem fachlichen Risiko: Fachlich kritische Geschäftsvorfälle MÜSSEN durchgängig über alle Stufen abgesichert sein, während unkritische Oberflächenbereiche auf den unteren Stufen abgedeckt werden können.

Teststufen der Frontend-Teststrategie beschreibt die Teststufen der Pyramide von der Basis bis zur Spitze.

Die statische Codeanalyse prüft den Quellcode ohne Ausführung der Anwendung gegen ein definiertes Regelwerk. Sie ist die kostengünstigste Qualitätsmaßnahme überhaupt, da sie unmittelbar an der Codestelle Rückmeldung gibt – bereits in der Entwicklungsumgebung und damit lange vor jeder Testausführung.

Ihr Zweck ist zweigeteilt: Sie sichert die Einheitlichkeit des Codes über Teams und Auftragnehmer hinweg (→ AG-3: Standardisierung vor projektspezifischen Sonderlösungen) und erkennt zugleich fehleranfällige oder sicherheitskritische Muster, die durch Tests nur schwer aufzudecken sind.

Ein Quality Gate ist ein definierter Prüfpunkt im Entwicklungs- und Auslieferungsprozess, an dem ein Artefakt festgelegte Kriterien erfüllen MUSS, um die nächste Stufe zu erreichen.

Quality Gates überführen die in den vorangegangenen Abschnitten beschriebenen Einzelmaßnahmen in eine verbindliche Reihenfolge: Sie legen fest, wann eine Prüfung stattfindet, wer oder was sie ausführt und welche Konsequenz ein Verstoß hat.

Frontends SOLLEN ihren Zustand bewusst und nachvollziehbar modellieren. Dabei SOLL zwischen lokalem UI-Zustand, fachlichem Feature-Zustand, globalem Anwendungszustand, URL-/Navigationszustand und serverseitig geladenen Daten unterschieden werden.

Lokaler UI-Zustand, zum Beispiel geöffnete Panels, aktive Tabs, Eingabefokus oder temporäre Formularwerte, SOLL möglichst nah an der jeweiligen Komponente gehalten werden. Feature-Zustand, der von mehreren Komponenten innerhalb eines fachlichen Bereichs benötigt wird, SOLL in einem fachlich abgegrenzten Service oder Store gekapselt werden. Globaler Anwendungszustand SOLL nur verwendet werden, wenn ein Zustand tatsächlich von mehreren fachlichen Bereichen benötigt wird oder querschnittliche Bedeutung hat.

Serverseitig geladene Daten SOLLEN nicht unnötig in globalen Stores dupliziert werden. Für API-Daten ist zu prüfen, ob ein einfacher, fachlich begrenzter Cache ausreichend ist. Abgeleiteter Zustand SOLL nicht dauerhaft gespeichert werden, sondern aus dem eigentlichen Quellzustand berechnet werden.

State-Modelle SOLLEN fachlich verständlich, typisiert und möglichst klein gehalten werden. Sie SOLLEN nur die Daten enthalten, die für die jeweilige Darstellung oder Interaktion notwendig sind.

Data Transfer Objects (DTOs) aus Backend-Schnittstellen SOLLEN nicht unreflektiert als internes Frontend-State-Modell verwendet werden. Bei Bedarf SOLL eine Trennung zwischen Schnittstellenmodell, fachlichem View-Modell und UI-Zustand erfolgen. Dadurch bleiben Änderungen an Backend-Schnittstellen besser beherrschbar und die Darstellungsschicht wird nicht unnötig an technische Datenstrukturen gekoppelt.

Gemeinsam genutzter Zustand SOLL nur über definierte Schnittstellen geändert werden. Komponenten SOLLEN gemeinsamen Zustand nicht direkt manipulieren, sondern dafür vorgesehene Methoden eines Services, Stores oder einer Fassade verwenden. Dadurch bleiben Zustandsänderungen nachvollziehbar und testbar.

Für Zustandsänderungen gelten folgende Vorgaben:

Zustand, der für Navigation, Wiederherstellbarkeit oder Teilbarkeit relevant ist, SOLL bevorzugt in der URL abgebildet werden, zum Beispiel Suchparameter, Filter, Sortierung oder Pagination. Dadurch bleiben Ansichten nachvollziehbar, bookmarkfähig und leichter testbar. Sensible Daten DÜRFEN dabei nicht in URL-Parametern abgelegt werden.

Clientseitiges Caching DARF nur als Performance- und Bedienbarkeitsoptimierung verstanden werden. Der Cache DARF NICHT als fachlich verbindliche Datenquelle betrachtet werden.

Caching SOLL gezielt und fachlich begründet eingesetzt werden. Für zwischengespeicherte Daten MÜSSEN Gültigkeit, Invalidierung und Aktualisierung geregelt sein. Insbesondere bei personenbezogenen oder berechtigungsabhängigen Daten ist sicherzustellen, dass keine veralteten oder unzulässigen Daten angezeigt werden.

Für clientseitiges Caching gelten folgende Vorgaben:

Offline-Fähigkeit oder persistentes Caching fachlicher Daten ist eine eigene Architekturentscheidung. Sie DARF nur umgesetzt werden, wenn Anforderungen, Sicherheitsbetrachtung, Datenschutz, Synchronisation, Konfliktbehandlung und Löschkonzept beschrieben sind.

Die Speicherung von Daten im Browser ist restriktiv zu verwenden. Grundsätzlich SOLL Zustand nur im Arbeitsspeicher gehalten werden. Persistente Speicherung im Client SOLL nur erfolgen, wenn sie fachlich oder technisch notwendig ist.

Folgende Einordnung ist zu verwenden:

Sensible Daten DÜRFEN grundsätzlich NICHT in localStorage, sessionStorage oder IndexedDB gespeichert werden. Dazu zählen insbesondere Zugangsdaten, Session-IDs, Tokens, personenbezogene Daten mit erhöhtem Schutzbedarf, Berechtigungsinformationen und fachlich besonders schützenswerte Daten.

Daten aus clientseitiger Speicherung MÜSSEN beim Lesen als nicht vertrauenswürdig behandelt werden. Sie können durch Benutzer, Browser-Erweiterungen oder Schadcode verändert worden sein. Deshalb MÜSSEN gespeicherte Daten validiert und bei fachlicher Relevanz serverseitig erneut geprüft werden.

Für persistierte Client-Daten SOLLEN Versionierung, Migration und Löschung berücksichtigt werden. Nicht mehr benötigte Daten MÜSSEN entfernt werden, insbesondere bei Logout, Benutzerwechsel oder Änderung des fachlichen Kontextes.

Ein zusätzliches State-Management-Framework SOLL nur eingesetzt werden, wenn der Nutzen die zusätzliche Komplexität rechtfertigt. Dies kann insbesondere der Fall sein bei komplexem fachlichem Zustand, mehreren beteiligten Features, aufwendiger asynchroner Orchestrierung, Bedarf an Debugging-Werkzeugen oder einheitlichen Patterns für große Teams.

Für einfache lokale oder feature-nahe Zustände SOLLEN leichtgewichtige Mechanismen bevorzugt werden, zum Beispiel Komponenten-State, reaktive Framework-Mechanismen wie Signals bei Angular-Anwendungen oder fachlich gekapselte Services. Dadurch bleibt die Architektur verständlich und vermeidet unnötigen Boilerplate-Code.

Logging, Monitoring und Telemetrie erfüllen unterschiedliche Aufgaben:

Die Browser-Konsole ist kein zentraler Logging-Dienst. Ausgaben über console.log, console.warn oder console.error DÜRFEN NICHT ungefiltert an ein Backend oder einen Telemetrie-Dienst weitergeleitet werden.

Debug- und Entwicklungsinformationen DÜRFEN in Produktivumgebungen nicht dauerhaft aktiviert sein.

Die folgenden Vorgaben beziehen sich primär auf Single-Page Applications (SPA). Für serverseitig gerenderte oder hybride Frontend-Architekturen gelten sie sinngemäß, soweit nicht anders angegeben.

Eine SPA SOLL nur solche technischen Fehler zentral erfassen, die für die Bewertung der Stabilität, Verfügbarkeit oder Nutzbarkeit der Anwendung relevant sind.

Hierzu zählen insbesondere:

Erwartete fachliche Fehler und reguläre Benutzereingaben SOLLEN nicht als technische Fehler gemeldet werden. Hierzu zählen beispielsweise Validierungsfehler, fachlich erwartete Ablehnungen, bewusst abgebrochene Vorgänge oder fehlende optionale Eingaben.

HTTP-Statuscodes MÜSSEN fachlich eingeordnet werden. Insbesondere DÜRFEN NICHT alle Antworten mit einem Statuscode aus dem Bereich 4xx pauschal als technische Fehler behandelt werden.

Ein erfasstes Fehlerereignis SOLL mindestens folgende strukturierte Angaben enthalten:

Vollständige URLs, Request- und Response-Inhalte, Formulardaten, Tokens, Session-Informationen und andere personenbezogene oder sicherheitsrelevante Daten DÜRFEN NICHT Bestandteil des Fehlerereignisses sein.

Stacktraces DÜRFEN nur übertragen werden, wenn sie vor der Übermittlung bereinigt und auf notwendige technische Informationen begrenzt wurden. Quellcode, Zugangsdaten, Inhalte aus Benutzereingaben oder interne Infrastrukturinformationen DÜRFEN dadurch nicht offengelegt werden.

Fehler- und Telemetriedaten MÜSSEN strukturiert über eine definierte und versionierte HTTPS-Schnittstelle übertragen werden. Die ungefilterte Übertragung von Konsolenausgaben oder beliebigen JavaScript-Objekten ist nicht zulässig.

Die Schnittstelle MUSS insbesondere folgende Maßnahmen unterstützen:

Telemetrie-Endpunkte DÜRFEN NICHT als allgemeine Proxy-Schnittstelle zu externen Monitoring-Diensten verwendet werden.

Übertragungsfehler DÜRFEN die eigentliche Nutzung der Anwendung nicht blockieren. Wiederholungsversuche MÜSSEN zeitlich und mengenmäßig begrenzt werden.

Eine dauerhafte Speicherung von Telemetriedaten im Browser SOLL vermieden werden. Insbesondere fehlgeschlagene Übertragungen DÜRFEN NICHT zu einer unkontrollierten persistenten Sammlung von Fehlerdaten führen.

Frontends SOLLEN technische Metriken erfassen, wenn diese zur Bewertung von Stabilität, Verfügbarkeit und wahrgenommener Performance benötigt werden.

Geeignete Metriken sind insbesondere:

Metriken SOLLEN aggregiert ausgewertet werden. Einzelne Messwerte DÜRFEN NICHT ohne fachliche und datenschutzrechtliche Begründung einem konkreten Benutzer zugeordnet werden.

Metriken MÜSSEN mindestens nach Anwendung, Version und Umgebung unterscheidbar sein. Weitere Dimensionen, beispielsweise Browserfamilie oder Gerätetyp, DÜRFEN nur in der für die technische Analyse erforderlichen Genauigkeit übertragen werden.

Für relevante Metriken SOLLEN Zielwerte, Warnschwellen und Alarmierungsregeln definiert werden. Alarmierungen SOLLEN auf aggregierten und wiederholt auftretenden Problemen basieren und nicht unkontrolliert für jedes einzelne Client-Ereignis ausgelöst werden.

Neben der realen Nutzung SOLLEN für geschäftskritische Frontends synthetische Prüfungen berücksichtigt werden. Diese können beispielsweise die Erreichbarkeit, den erfolgreichen Anwendungsstart und zentrale technische Abläufe überprüfen.

Fehler und Messwerte SOLLEN einer technischen Benutzeraktion oder Backend-Anfrage zugeordnet werden können, ohne personenbezogene Daten zu verwenden.

Für HTTP-Anfragen ist die in der Referenzarchitektur REST definierte Korrelations-ID im Header X-Correlation-Id zu berücksichtigen. Vorhandene Korrelationsinformationen SOLLEN bei der Kommunikation zwischen Frontend, Backend-for-Frontend und Backend weitergegeben werden, soweit dies technisch und sicherheitlich vorgesehen ist.

Vom Browser übermittelte Korrelations-IDs MÜSSEN als nicht vertrauenswürdig behandelt werden. Sie DÜRFEN NICHT als Grundlage für Autorisierung, Zugriffskontrolle oder andere sicherheitsrelevante Entscheidungen verwendet werden.

Ein Backend-for-Frontend SOLL eingehende IDs validieren oder eigene vertrauenswürdige Korrelationsinformationen erzeugen. Die Zuordnung zwischen einem clientseitigen Ereignis und den zugehörigen serverseitigen Logs SOLL anschließend in der zentralen Observability-Infrastruktur möglich sein.

Bei Verwendung eines Backend-for-Frontend SOLL dieses als zentrale Annahmestelle für Frontend-Fehler und Telemetriedaten vorgesehen werden.

Das Backend-for-Frontend SOLL insbesondere:

Benutzer- oder Sitzungsinformationen, die serverseitig bereits vorliegen, SOLLEN nicht zusätzlich durch das Frontend übertragen werden. Das Backend-for-Frontend DARF diese Informationen nur ergänzen, wenn dies für den festgelegten technischen Zweck erforderlich und datenschutzrechtlich zulässig ist.

Ohne Backend-for-Frontend MUSS eine vergleichbare abgesicherte Telemetrie-Schnittstelle über das API-Gateway oder eine dafür vorgesehene Backend-Komponente bereitgestellt werden. Eine direkte Kopplung der SPA an interne Logging-Systeme ist nicht zulässig.