Jede HTTP-Antwort trägt einen dreistelligen Statuscode. Die erste Ziffer verrät die Klasse: 2xx Erfolg, 3xx Umleitung, 4xx Fehler auf Seite des Clients (die Anfrage passt nicht), 5xx Fehler auf Seite des Servers.

Code	Bedeutung	Was dein Frontend tut
200 OK	Erfolg mit Inhalt	Daten prüfen und anzeigen
201 Created	Neu angelegt (nach POST)	Neues Objekt übernehmen
204 No Content	Erfolg ohne Body (oft nach DELETE)	Kein `json()` aufrufen
400 Bad Request	Anfrage kaputt, etwa ungültiges JSON	Eigenen Code prüfen
401 Unauthorized	Nicht angemeldet	Zur Anmeldung leiten
403 Forbidden	Angemeldet, aber keine Berechtigung	Hinweis „keine Berechtigung“
404 Not Found	Gibt es nicht	„Nicht gefunden“ zeigen
422 Unprocessable Content	Verstanden, aber Daten ungültig	Meldung am Formularfeld
429 Too Many Requests	Zu viele Anfragen	Header `Retry-After` abwarten
500 Internal Server Error	Fehler im Server	Allgemeine Meldung zeigen
503 Service Unavailable	Dienst kurz nicht verfügbar	Später mit Pause erneut versuchen

Die wichtigste Regel der Woche: fetch lehnt bei 404 oder 500 nicht ab. Auch eine Fehlerantwort ist eine Antwort. Prüfe deshalb immer antwort.ok oder antwort.status, bevor du die Daten verwendest.

Anmeldung und Cookies: Nach einem erfolgreichen Login setzt der Server meist ein Session-Cookie, zum Beispiel Set-Cookie: sid=…; HttpOnly; Secure; SameSite=Lax; Path=/. HttpOnly: JavaScript kann das Cookie nicht lesen, der Browser schickt es trotzdem bei Anfragen an dieselbe Origin mit (Standard von fetch: credentials: "same-origin"). Secure: nur über HTTPS. SameSite=Lax: bremst Anfragen, die von fremden Seiten ausgelöst werden. Für eine API auf einer anderen Origin brauchst du credentials: "include", und der Server muss das per CORS ausdrücklich erlauben.

Sicherheit: keine sensiblen Daten in Local Storage.

Ursache: localStorage ist bequem, aber jedes Skript derselben Origin kann ihn lesen, auch eingeschleuster Code (XSS) oder ein kompromittiertes Fremdskript.
Erkennung: In den Developer Tools unter „Anwendung“ bzw. „Speicher“ nachsehen; im Code nach localStorage.setItem mit Token, Passwort oder Personendaten suchen.
Test im Lab: Auf der eigenen Übungsseite localStorage in der Konsole auslesen. Was du dort siehst, sieht auch jedes fremde Skript auf der Seite.
Fix: Die Sitzung lebt in einem HttpOnly-Cookie vom Server. In den Local Storage kommen höchstens harmlose Einstellungen wie Sortierung oder Farbschema.
Verifikation: Nach dem Login steht kein Token im Speicher, und document.cookie zeigt das Session-Cookie nicht an.
Betrieb: Review-Regel und Suchmuster in der CI, Sitzungen kurzlebig halten und beim Logout serverseitig beenden.

TypeScript/JavaScript Lernpfad von den Grundlagen zur sicheren Full-Stack-Entwicklung.

Anmelden