Ein kleiner Fehler zwischen Frontend, Backend und Azure legt Produktion lahm

Der vollständige Artikel steht unten. Aktivieren Sie JavaScript für Quiz und Simulationen.

Ein kleiner Fehler zwischen Frontend, Backend und Azure legt Produktion lahm

In modernen Technologieprojekten glauben wir leicht, die größten Risiken lägen in großen Architekturentscheidungen. Das Team diskutiert Muster, Cloud, Sicherheit, Skalierung, Zuständigkeiten und Dienstverträge. Alles wichtig. Produktion scheitert jedoch häufig nicht an diesen großen Entscheidungen. Sie scheitert an kleinen Fehlern, die zunächst nebensächlich wirken.

Deshalb machen selbst erfahrene Teams und Architekten denselben Fehler: Läuft das Frontend lokal, antwortet das Backend korrekt und endet das Deployment ohne rote Fehler, gilt das System als fertig. Das ist es nicht automatisch. Zwischen „läuft“ und „läuft gut in Produktion“ liegt ein großer Unterschied.

Besonders tückisch ist der Fall, in dem Frontend, Backend und Azure-Infrastruktur unterschiedliche Versionen derselben Realität verwenden. Jede Schicht sieht den Request etwas anders und interpretiert Host, Scheme, Origin, Cookies und Verkehrsweg eigenständig. Obwohl es formal läuft, wirkt das System instabil, widersprüchlich und riskant zu warten.

Warum dieses Problem gefährlich ist

Solche Ausfälle zeigen selten eine klare Einzelmeldung. Stattdessen erscheinen verstreute Symptome:

• Anmeldung funktioniert nur manchmal,
• nach dem Aktualisieren verschwindet die Sitzung,
• das Frontend bekommt trotz Anmeldung 401,
• der Redirect nach Autorisierung führt zur falschen Adresse,
• Cookies sind sichtbar, werden aber nicht zurückgesendet,
• CORS funktioniert in einem Ablauf und scheitert im anderen,
• lokal sieht alles gut aus, unter Azure kehrt der Fehler unberechenbar zurück.

Das zerstört Vertrauen in das System. Nutzer sehen keinen falsch weitergereichten Host und keine fehlerhafte Scheme-Auswertung hinter dem Reverse Proxy. Sie sehen nur: Das System verhält sich nicht stabil.

So sieht das in einem echten Projekt aus

Nehmen wir einen typischen Aufbau:

• Angular als Frontend des Adminbereichs,
• ASP.NET Core als Backend-API,
• Azure App Service als Anwendungshosting,
• Azure Front Door oder Application Gateway als Eingangsschicht,
• eigene Domain,
• Anmeldung über Cookies, Sitzung oder Autorisierungs-Callback.

Das Diagramm wirkt durchdacht. Lokal funktioniert es, und auch Staging zeigt scheinbar keine großen Probleme. Hier beginnt die Falle: Das Team hält die Architektur für korrekt, weil einfache Tests bestanden wurden.

Produktion zeigt schnell, dass das nicht reicht.

Ein kleiner Fehler genügt:

• Das Backend liest X-Forwarded-Protofalsch,
• die Anwendung interpretiert den Request als http, obwohl der Nutzer über httpsfalsch,
• gekommen ist; öffentlicher und interner Host gelten als identisch,
• das Frontend bildet API-Adressen aus der falschen Quelle,
• die Cookie-Policy passt nicht zum tatsächlichen Ablauf,
• der Callback wird aus einer falschen Domain erzeugt.

Einzeln wirkt jede Kleinigkeit harmlos. Zusammen entsteht ein scheinbar funktionierendes, architektonisch aber bereits gebrochenes System.

Der größte Teamfehler: Symptome statt Ursachen behandeln

Oft reagiert das Team ähnlich: Das Frontend bekommt eine Interceptor-Ausnahme, das Backend ein weiteres if-a. DevOps ergänzt eine Infrastrukturregel. Jemand trägt eine URL manuell ein, jemand lockert vorübergehend die Sicherheit, um den Release freizugeben.

Das ist ein gefährlicher Moment.

Es fühlt sich nach Reparatur an, tatsächlich werden nur Symptome behandelt. Die Ursache bleibt bestehen. Das System hat noch immer kein gemeinsames Verständnis der Requests. Beim nächsten Deployment, neuen Ablauf oder Domainwechsel kehrt der Fehler anders zurück.

Schnell wird die Architektur zu einem Bauwerk aus Umgehungslösungen. Es funktioniert irgendwie, aber niemand möchte es entspannt anfassen.

Echte Aufgaben zeigen, wo das System auseinanderläuft

Geschäftliche und technische Abläufe machen das Problem deutlicher als Diagramme.

1. Anmeldung im Adminbereich

Nutzer geben Zugangsdaten ein, werden autorisiert und gelangen ins Panel. Eigentlich einfach. Doch hier zeigt sich häufig, dass das System seine öffentliche Domain oder HTTPS-Situation nicht korrekt versteht.

Symptome:

• Das Cookie wird gespeichert, aber bei der nächsten Anfrage nicht mitgesendet,
• das Frontend meldet angemeldet, das Backend liefert 401,
• nach Neuladen verschwindet die Sitzung,
• der Login-Redirect führt zur falschen Adresse oder zum falschen Host.

Das ist keine kleine Unannehmlichkeit, sondern beschädigt direkt das Produktvertrauen.

2. Inhalte im Adminbereich veröffentlichen

Redaktionsbereiche nutzen oft eigene API-Pfade, zusätzliche Autorisierungspolicies und andere Requests als öffentliche Seiten. Hier treten Unterschiede bei Cookies, Hosts und CORS hervor.

Symptome:

• Entwürfe speichern lokal, aber nicht in Produktion,
• Veröffentlichungen scheitern trotz korrekter Daten,
• das Frontend sendet korrekt, das Backend erkennt aber keine Sitzung,
• manche Admin-Endpoints wirken zufällig instabil.

Das ist ein typisches Zeichen für unterschiedliche Request- und Autorisierungsinterpretation statt eines reinen Formularfehlers.

3. Callback einer externen Integration

Bei OAuth, Zahlungen oder externen Anbietern tritt das Problem noch deutlicher auf. Ein aus falscher Domain oder falschem Scheme erzeugter Callback bringt die gesamte Integration durcheinander.

Symptome:

• Die Rückkehr führt zur falschen Adresse,
• der Request landet auf HTTP statt HTTPS,
• der Anbieter lehnt den Callback ab,
• der Ablauf funktioniert nur in einer Umgebung.

Hier reicht „vielleicht klappt es“ nicht. Entweder gibt es ein gemeinsames Verkehrsmodell, oder Integrationen bleiben problematisch.

4. Deep Links und aktualisierte Ansichten

Bei SPAs zeigt sich der Fehler oft beim direkten Aufruf einer Unterseite oder nach Neuladen. Routing, Autorisierung und Backend teilen plötzlich nicht denselben Kontext. Das Frontend rekonstruiert Zustand, das Backend erkennt fehlende Sitzung oder falschen Origin, Nutzer erleben Chaos. Das ist tückisch, weil einfache Klicktests oft bestehen und erst normale Nutzung den Fehler aufdeckt.

Ein echtes Problem, das wir kürzlich gelöst haben

Ein in diesem Aufbau auftretendes Problem entsteht, wenn das Frontend API-Adressen aus dem aktuellen Origin bildetund das Backend zu spät die Behandlung von ForwardedHeadersaktiviert. Lokal kann es funktionieren; hinter einem Proxy und unter der Produktionsdomain beginnt Chaos.

Fehlerhaftes Frontend-Muster

const apiUrl = `${window.location.origin}/api`;

Lokal wirkt das bequem. Problematisch wird es, wenn:

• das Panel unter einer Domain läuft,
• die API unter einer anderen,
• Traffic durch einen Proxy läuft,
• öffentlicher und interner Host verschieden sind.

Eine bessere, stabilere Variante

export interface AppEnvironment {
  production: boolean;
  apiBaseUrl: string;
}

export const environment: AppEnvironment = {
  production: true,
  apiBaseUrl: 'https://api.twojadomena.pl'
};

@Injectable({ providedIn: 'root' })
export class ApiConfigService {
  readonly baseUrl = environment.apiBaseUrl.replace(/\/+$/, '');
}

Ein Interceptor, der Adressen normalisiert statt rät

import { HttpInterceptorFn } from '@angular/common/http';
import { inject } from '@angular/core';

export const apiBaseUrlInterceptor: HttpInterceptorFn = (req, next) => {
  if (/^https?:\/\//i.test(req.url)) {
    return next(req);
  }

  const config = inject(ApiConfigService);
  const normalizedUrl = `${config.baseUrl}/${req.url.replace(/^\/+/, '')}`;

  return next(
    req.clone({
      url: normalizedUrl,
      withCredentials: true
    })
  );
};

Der zweite Teil lag im Backend. Wenn die Verarbeitung von UseForwardedHeaders() zu spät erfolgt, arbeitet die weitere Pipeline bereits mit einem falschen Request-Bild.

Die richtige Richtung in ASP.NET Core

using Microsoft.AspNetCore.HttpOverrides;

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor |
        ForwardedHeaders.XForwardedProto |
        ForwardedHeaders.XForwardedHost;

    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

var app = builder.Build();

app.UseForwardedHeaders();

app.UseCors("AdminCors");
app.UseAuthentication();
app.UseAuthorization();

Ein unscheinbares Problem kann in der Praxis Folgendes beschädigen:

• Anmeldung,
• Cookies,
• Redirects,
• Callbacks,
• Linkerzeugung,
• Konsistenz zwischen Frontend und Backend.

Was wirklich stimmen muss

Die richtige Reparatur ergänzt nicht immer neue Ausnahmen. Sie schafft ein gemeinsames Verständnis für den gesamten Ablauf.

• Frontend darf den API-Ort nicht erraten, sondern braucht klare Umgebungskonfiguration.
• Backend muss Host, Scheme und seine Position hinter dem Proxy korrekt verstehen.
• Azure ist eine reale Architekturschicht, kein neutraler Transportkanal.
• Cookies müssen zum tatsächlichen Ablauf passen, nicht nur zur lokalen Vorstellung.
• CORS muss präzise auf öffentliche Domains eingestellt sein, nicht nur „irgendwie funktionieren“.
• Logs müssen zeigen, was das System wirklich sieht, nicht was das Team annimmt.

Erst dann sprechen wir von Produktionsreife.

Die wichtigste Lektion

Architektur scheitert nicht nur an großen Entscheidungen, sondern oft an kleinen missverstandenen Annahmen:

• falscher Host,
• falsches Scheme,
• falsche Middleware-Reihenfolge,
• falsche Cookie-Policy,
• der Irrglaube, Azure ändere nichts,
• zu großes Vertrauen, dass lokaler Erfolg Produktion garantiert.

Genau deshalb ist dieser Fehler gefährlich. Er wirkt zunächst wie eine kleine Anomalie. Später zeigt sich, dass er Anmeldung, Routing, Callbacks, Sicherheit und Stabilität der ganzen Plattform steuert.

Fazit

Frontend, Backend und Azure können einzeln korrekt entworfen sein und zusammen trotzdem instabil werden. Produktion verlangt neben gutem Code vor allem Konsistenz.

Ein reifes System braucht ein gemeinsames Verständnis über alle Schichten. Derselbe Host. Dasselbe Scheme. Dieselben Vertrauensregeln. Dieselbe Sicherheitssemantik. Dasselbe Request-Bild.

Manchmal entscheidet ein kleiner Fehler darüber, ob Nutzer eine professionelle Plattform erleben oder ein System, das nur bis zum ersten schwierigen Deployment gut aussieht.