Autorisierung und Datensicherheit

Autorisierung und Datensicherheit

0:00 Dieses Modul zieht die Fäden zusammen. Die Layout-Eigenschaft aus Modul zwei, die schmalen Eigenschaften aus Modul vier, der Zugriffs-Layer aus Modul neun, die Sitzung aus Modul zehn — alles läuft hier zusammen zu einer Frage: Wer darf was, und wo wird das geprüft? Ich sage Ihnen den wichtigsten Satz gleich vorweg, damit Sie ihn im Ohr haben: Die Prüfung gehört an die Daten, nicht an die Seite.

0:23 Alles Weitere in diesem Modul ist eine Ausfaltung dieses einen Satzes. Und weil hier Fehler nicht abstürzen, sondern still funktionieren, sehen wir besonders genau hin.

Prüfungen nah an die Daten

0:33 Fangen wir mit dem teuersten Denkfehler beim Umstieg an. Wer aus Single-Page- Anwendungen kommt, hat eine bestimmte Vorstellung davon, wo Berechtigungen geprüft werden — und diese Vorstellung ist hier falsch. Nicht ein bisschen ungenau, sondern grundsätzlich. Ich zeige Ihnen, warum, und was stattdessen gilt. Berechtigungen gehören so nah wie möglich an die Datenquelle — also in den Zugriffs-Layer, nicht in Seite oder Layout.

0:59 Der Grund ist ein doppelter, und Sie kennen beide Hälften schon: Eine Prüfung im Layout läuft bei Navigation innerhalb des Zweigs nicht erneut, das war Modul zwei. Und ein Layout verhindert gar nicht, dass verschachtelte Segmente gerendert werden — es zeigt sie nur nicht an. Wenn Sie also im Layout entscheiden, wer etwas sehen darf, haben Sie einen Vorhang gezogen, keine Tür verschlossen.

1:21 In einer Single-Page-Anwendung gab es einen Eintrittspunkt: den Router. Eine Weiche dort, und die Sache war erledigt. Hier gibt es viele Eintrittspunkte — die Seite, das Layout, die Aktion, der Endpunkt, und sogar das Vorabladen. Jeder davon kann Daten anfordern, und keiner weiß, was die anderen geprüft haben. Deshalb funktioniert die alte Gewohnheit nicht mehr.

1:43 Der vierte Punkt ist der, den ich für den unheimlichsten halte: Ausgeblendete Inhalte stehen trotzdem in der übertragenen Nutzlast. Der Nutzer sieht sie nicht auf der Seite. Er findet sie in den Entwicklerwerkzeugen. Diese Tabelle beantwortet die Frage in vier Zeilen, und nur die unterste bekommt ein uneingeschränktes Ja. Der Proxy ist eine Weiche, das wissen wir aus Modul acht.

2:07 Das Layout wirkt einmal je Zweig. Die Seite wirkt für die Ansicht — und nur für die. Der Zugriffs-Layer wirkt bei jeder Abfrage, egal von wo sie kommt, und deckt damit Seite, Aktion und Endpunkt gleichzeitig ab. Das ist der Grund, warum wir ihn in Modul neun gebaut haben, obwohl er dort wie eine Ordnungsfrage aussah. Er ist die einzige Stelle, die alle Wege abdeckt.

2:30 Der erste Punkt ist ein Muster, das aus der React-Welt mitwandert und hier gefährlich wird: In einem Layout nichts zurückzugeben ist keine Absicherung. Es sieht aus wie eine, es fühlt sich an wie eine, und es ist keine. Der zweite Punkt ist der, den ich in Modul sieben angekündigt habe: Eine Prüfung auf der Seite gilt nicht für die dort definierte Aktion.

2:50 Und der dritte ist der subtilste — parallele Bereiche werden vom Router gerendert, auch wenn das Layout sie nicht anzeigt. Der Inhalt entsteht, wird berechnet und übertragen.

Rollen und Ressourcenbesitz

3:01 Jetzt zu einer Unterscheidung, die in Reviews am häufigsten fehlt. Es gibt nicht eine Berechtigungsprüfung, es gibt zwei — und die zweite wird regelmäßig vergessen, weil die erste sich vollständig anfühlt. Ich zeige Ihnen den Unterschied an einem Beispiel aus unserem Portal, das jeder sofort versteht. Die erste Frage lautet: Darf diese Person überhaupt Rechnungen sehen? Das ist die Rolle. Die zweite lautet: Darf sie diese Rechnung sehen? Das ist der Besitz.

3:28 Ein Gast darf seine eigene Rechnung sehen, nicht die des Nachbarliegeplatzes. Fehlt diese zweite Prüfung, entsteht das, was in Sicherheitsberichten als unsichere direkte Objektreferenz auftaucht — ein sperriger Name für eine sehr einfache Sache: Man zählt die Nummer in der Adresszeile hoch und bekommt fremde Daten. Sehen Sie sich die Struktur an: erst Identität, dann Besitz oder Rolle, dann die Änderung.

3:53 Die Bedingung in der Mitte ist die, die am häufigsten fehlt — sie prüft, ob der Datensatz dieser Person gehört, mit einer Ausnahme für die Verwaltung. Worauf es ankommt: Diese wenigen Zeilen stehen im Zugriffs-Layer, nicht in der Seite. Damit gelten sie automatisch für jeden Aufrufer. Und beachten Sie, dass hier die Antworten aus Modul drei verwendet werden — nicht angemeldet und nicht berechtigt sind verschiedene Fälle mit verschiedenen Antworten.

4:19 Der zweite Punkt ist der, der die Sache konkret macht: Kennungen aus der URL sind erratbar oder aus Listen bekannt. In unserem Portal steht die Buchungsnummer in der Bestätigungsmail, in der Rechnung, in der Adresszeile. Sie ist kein Geheimnis. Der dritte Punkt beschreibt, warum das so lange unbemerkt bleibt: Ein Zugriff auf fremde Daten fällt niemandem auf, solange nichts abstürzt.

4:42 Es gibt keine Fehlermeldung, keinen Eintrag im Log, nichts. Und der vierte ist die schlichte Rechnung: Die Prüfung kostet eine Bedingung und verhindert einen Meldefall. Der zweite Punkt ist eine Beobachtung aus der Praxis, die ich für nützlich halte: Beim Löschen und Ändern wird der Besitz öfter vergessen als beim Lesen.

5:01 Der Grund ist psychologisch — beim Lesen denkt man an Datenschutz, beim Löschen denkt man an die Fachlogik. Dabei ist ein fremder Datensatz, den jemand löschen kann, der schlimmere Fall. Der dritte Punkt ist die Wiederholung der Kernbotschaft: Wer die Prüfung in die Komponente legt, hat sie in der Aktion nicht. Es gibt viele Eintrittspunkte, aber nur einen Zugriffs-Layer.

Übertragungsobjekte statt Datensätze

5:22 Jetzt zu der Frage, was eigentlich hinausgeht. Wir haben in Modul vier gelernt, dass durchgereichte Objekte vollständig im Browser landen. Jetzt bauen wir die Struktur, die das systematisch verhindert — nicht durch Aufmerksamkeit, sondern durch Konstruktion. Und der eigentliche Gewinn zeigt sich erst in einem halben Jahr.

5:42 Der Zugriffs-Layer gibt nicht die Datenbankzeile zurück, sondern ein Objekt mit genau den Feldern, die der jeweilige Aufrufer sehen darf. Und das kann je nach Betrachter unterschiedlich sein: Die Verwaltung sieht die Telefonnummer eines Gastes, ein anderer Gast nicht. Denken Sie an einen Auszug aus einem Register — Sie bekommen nicht die Akte, sondern eine Bescheinigung mit den Angaben, die für Ihren Zweck bestimmt sind.

6:05 Was nicht darauf steht, kann auch nicht weitergegeben werden. Die entscheidende Zeile ist die mit der Bedingung: Dasselbe Feld ist für den einen sichtbar und für den anderen nicht — entschieden an einer einzigen Stelle. Worauf es ankommt: Diese Entscheidung steht nicht in der Komponente, wo sie jemand beim Umbau übersehen könnte, sondern im Zugriff.

6:25 Die Komponente bekommt schlicht nichts, wenn sie nichts bekommen darf. Der Satz unter dem Code ist die Zusammenfassung: Was hier nicht steht, kann später nicht versehentlich sichtbar werden. Es ist nicht verborgen, es ist nicht vorhanden. Der zweite Punkt ist mein stärkstes Argument für den Aufwand. Wenn Sie ganze Objekte durchreichen und irgendwann ein neues Feld in die Datenbank aufnehmen, landet es automatisch im Browser.

6:49 Niemand hat eine Entscheidung getroffen, niemand hat etwas übersehen — es ist einfach passiert. Bei uns wäre das etwa ein interner Vermerk zum Gast, den jemand aus der Verwaltung ergänzt. Mit Übertragungsobjekten passiert das nicht: Das neue Feld ist nicht in der Liste, also geht es nicht hinaus. Sie müssen es aktiv aufnehmen, um es zu veröffentlichen.

Sicherheit von Server Actions

7:10 Jetzt sehen wir uns an, was Next.js selbst für Sie tut — und wo diese Hilfe aufhört. Das ist wichtig, weil die eingebauten Mechanismen gut sind und deshalb zu der Annahme verleiten, es sei alles erledigt. Das ist es nicht, und die Grenze verläuft an einer klaren Stelle. Wir haben in Modul sieben festgestellt: Eine exportierte Aktion ist über einen direkten Aufruf erreichbar, auch wenn sie nirgends verlinkt ist.

7:35 Next.js tut dagegen einiges — verschlüsselte Kennungen, die sich zwischen Builds ändern, das Entfernen ungenutzter Aktionen aus dem Bundle, eine Prüfung der Herkunft und die Beschränkung auf eine einzige HTTP-Methode. Das ist durchdacht und senkt das Risiko erheblich. Es beantwortet aber nicht die Frage, ob der Aufrufer das eigentlich darf.

7:55 Der Satz unter der Tabelle ist die Botschaft: Die linke Spalte senkt das Risiko, die rechte beseitigt es. Das ist keine Wortklauberei. Die eingebauten Mechanismen machen es schwerer, eine Aktion zu finden und aufzurufen. Sie machen es nicht unmöglich. Wenn also die Prüfung fehlt, ist Ihre Anwendung angreifbar — nur mit etwas mehr Aufwand.

8:16 Meine Einschätzung: Das ist gut gemachte Verteidigung in der Tiefe, und genau so sollten Sie es lesen. Als zusätzliche Schicht, nicht als Ersatz für die erste. Der zweite und dritte Punkt betreffen etwas, das man kennen sollte: Variablen aus dem Umfeld einer Aktion werden verschlüsselt zum Client und wieder zurück geschickt.

8:35 Das ist eine elegante Lösung für ein echtes Problem, und die Dokumentation sagt trotzdem ausdrücklich, man solle sich auf diese Verschlüsselung nicht allein verlassen. Ich finde diese Offenheit angenehm. Der vierte Punkt ist ein Betriebsdetail für später: Hinter einem vorgeschalteten Server braucht die Herkunftsprüfung eine Liste erlaubter Ursprünge, sonst schlägt sie fehl.

Geheimnisse und Umgebungsvariablen

8:56 Ein kurzes Kapitel über etwas, das jeder zu kennen glaubt und das trotzdem regelmäßig schiefgeht. Es geht um Umgebungsvariablen, um ein Präfix mit weitreichender Wirkung — und um einen Schlüssel, den Sie erst brauchen, wenn Sie auf mehr als einer Instanz betreiben. Der letzte Punkt ist der, der in keinem Tutorial steht. Umgebungsvariablen sind serverseitig, bis ein bestimmtes Präfix sie in den Browser schiebt. Und dann sind sie öffentlich — in jedem ausgelieferten Bundle, für jeden lesbar.

9:25 Das Präfix ist keine Einstellung, es ist eine Veröffentlichung. Deshalb gehört der Zugriff auf die Umgebung ausschließlich in den Zugriffs-Layer, wie wir es in Modul neun festgelegt haben. Wenn nur eine Stelle Geheimnisse liest, gibt es auch nur eine Stelle, an der etwas schiefgehen kann. Hier kommt der Fall, der in keinem Tutorial steht und den man im Betrieb schmerzhaft lernt.

9:47 Next.js verschlüsselt die Umfeldvariablen einer Aktion mit einem Schlüssel, der bei jedem Build neu erzeugt wird. Läuft Ihre Anwendung auf drei Instanzen, haben Sie drei verschiedene Schlüssel. Eine Aktion, die Instanz A verschlüsselt hat, kann Instanz B nicht entschlüsseln. Das Ergebnis sind Fehlermeldungen über nicht gefundene Aktionen — sporadisch, scheinbar zufällig, nicht reproduzierbar. Genau die Sorte Fehler, an der Teams Tage verlieren.

10:15 Zwei Zeilen, und sie lösen genau das eben beschriebene Problem: ein Schlüssel, den Sie erzeugen und beim Bauen mitgeben, statt ihn erzeugen zu lassen. Worauf es ankommt, steht in der Fußnote: Das brauchen Sie nur, wenn mehr als eine Instanz läuft. Bei einer einzelnen Instanz ändert dieser Aufwand nichts. Merken Sie sich den Zusammenhang trotzdem — er gehört zu der Liste von fünf Dingen, die wir in Modul dreizehn beim Selbsthosten durchgehen.

10:40 Dort taucht er wieder auf, dann im Betriebszusammenhang. Der erste Punkt ist der, der eine Schlüsselrotation erzwingt: Eine veröffentlichte Variable bleibt in bereits ausgelieferten Bundles bestehen. Umbenennen hilft nicht — wer das alte Bundle hat, hat den Wert. Sie müssen das Geheimnis selbst wechseln. Der zweite Punkt ist Handwerk, das trotzdem schiefgeht: Umgebungsdateien gehören in die Ignorierliste.

11:04 Und der dritte ist der stille Fehler aus Modul vier: Ein Wert ohne Präfix wird im Client durch eine leere Zeichenkette ersetzt — es gibt keinen Fehler, nur seltsames Verhalten.

Typische Risiken und ihre Gegenmittel

11:15 Jetzt wird es praktisch. Die Next.js-Dokumentation gibt für ein Audit eine erfreulich kurze Liste vor — fünf Fragen, die man tatsächlich anwenden kann. Wir gehen sie am Hafenmeister-Portal durch und ergänzen zwei Themen, die dort nicht stehen und in die Praxis gehören. Was diese Liste auszeichnet, ist ihre Kürze. Sicherheitschecklisten haben oft hundert Punkte und werden deshalb nie abgearbeitet.

11:39 Fünf Fragen kann man tatsächlich stellen — vor jedem Release, in jedem Review. Wir ergänzen zwei Punkte, die in der Praxis dazugehören: eine Ratenbegrenzung für teure Vorgänge und eine Richtlinie, die festlegt, welche Inhalte der Browser überhaupt laden darf. Beides sind Themen, die man leicht aufschiebt und die im Ernstfall den Unterschied machen.

12:00 Der rote Faden dieser fünf Fragen ist eine Bewegung von innen nach außen. Frage eins prüft den Kern: Gibt es einen isolierten Zugriffs-Layer, und greift jemand daran vorbei? Das lässt sich in einer Minute beantworten — suchen Sie nach Datenbankimporten außerhalb dieses Ordners. Findet sich etwas, haben Sie einen zweiten Weg an den Daten, und der ist ungeprüft. Die Fragen zwei bis vier gehen die Eintrittspunkte durch.

12:25 Und Frage fünf ist die ehrlichste: Wer hat die mächtigsten Dateien zuletzt tatsächlich gelesen? React bietet Werkzeuge, mit denen sich Werte markieren lassen, sodass ihr Durchreichen an den Client zum Fehler wird. Das ist nützlich — und die Dokumentation nennt es ausdrücklich eine zusätzliche Schicht, nicht die Lösung. Der Grund steht im zweiten Punkt: Es hilft gegen Versehen, nicht gegen eine falsch entworfene Schnittstelle.

12:50 Wenn Ihre Funktion ein ganzes Gastobjekt zurückgibt und die Komponente es entgegennimmt, dann ist das kein Versehen, sondern der Entwurf. Sauber zugeschnittene Übertragungsobjekte bleiben die eigentliche Antwort — die Markierung ist das Sicherheitsnetz darunter. Der erste Punkt ist eine Erfahrung, die viele teilen: Eine Inhaltsrichtlinie ohne Test bricht die Anwendung an einer Stelle, an die niemand gedacht hat — meistens ein eingebettetes Skript oder eine Schriftquelle.

13:17 Führen Sie sie zuerst im Berichtsmodus ein, dann sehen Sie, was sie blockieren würde, ohne dass etwas kaputtgeht. Der dritte Punkt ist die Rückkehr zu Modul acht: Fehlermeldungen mit technischen Details helfen dem Angreifer mehr als dem Nutzer. Loggen ja, zurückgeben nein.

Versionspflege als Sicherheitsaufgabe

13:32 Zum Abschluss ein Thema, das selten unter Sicherheit einsortiert wird und dort hingehört. Eine Anwendung kann perfekt geschrieben sein und trotzdem angreifbar, wenn ihr Unterbau zwei Jahre alt ist. Das ist keine Entwicklungsfrage, sondern eine Betriebsaufgabe — und sie braucht einen Ablauf, nicht guten Willen. Next.js veröffentlicht regelmäßig Sicherheitsreleases.

13:54 Wer auf einer alten Nebenversion stehen bleibt, ist unabhängig von der Qualität des eigenen Codes angreifbar — die Lücke steckt dann im Framework, nicht in Ihrer Anwendung. Damit wird Aktualisieren zu einer Betriebsaufgabe wie das Einspielen von Betriebssystem-Updates. Das ist unspektakulär, es steht in keinem Sprint-Ziel, und es ist trotzdem eine der wirksamsten Sicherheitsmaßnahmen, die Sie haben.

14:18 Der rote Faden ist der dritte Schritt: kleine Sprünge regelmäßig statt seltener großer. Wer einmal im Jahr aktualisiert, springt über mehrere Hauptversionen und bekommt gebündelte Bruchänderungen — daraus wird ein Projekt mit eigenem Budget. Wer monatlich einen kleinen Schritt macht, hat jedes Mal eine überschaubare Änderung.

14:36 Schritt vier ist die Voraussetzung dafür und die Überleitung zum nächsten Modul: Ohne grünen Testlauf ist jedes Update ein Blindflug. Und Schritt fünf ist neu seit 16.3 — die im Projekt liegende Dokumentation wandert beim Update mit. Der zweite Punkt ist die direkte Überleitung: Ohne Tests ist ein Update ein Blindflug, und deshalb kommt Modul zwölf unmittelbar danach.

14:58 Der dritte Punkt ist einer, der in diesem Seminar mehrfach angeklungen ist und den ich für praktisch wichtig halte: Die gebündelte Dokumentation wandert beim Update mit, alte Anleitungen im Netz nicht. Das gilt für Sie beim Nachschlagen und, wie wir in Modul vierzehn sehen werden, ganz besonders für KI-Assistenten, die mit einem Wissensstand von vorgestern arbeiten.

15:18 Diese Aufgabe ist die Probe aufs Exempel für alles, was wir heute besprochen haben. Der Erfolg ist bewusst über drei Wege formuliert: Ein Gast erreicht fremde Buchungen weder über die Seite noch über die Aktion noch über den Endpunkt. Wenn Ihre Prüfung im Zugriffs-Layer sitzt, sind alle drei automatisch abgedeckt. Wenn nicht, merken Sie es genau hier.

15:38 Der Hinweis für die Schnelleren ist der interessanteste Teil: Rufen Sie die Aktion mit einer fremden Kennung direkt auf. Das ist der Test, den ein Angreifer als Erstes machen würde.

Modul 11 zusammengefasst

15:49 Vier Sätze zum Mitnehmen. Die Prüfung gehört an die Daten, nicht an die Seite. Rolle und Besitz sind zwei Prüfungen, nicht eine. Was Next.js eingebaut schützt, senkt das Risiko — beseitigt es aber nicht. Und Versionspflege ist Teil der Sicherheit, nicht Kür. Im nächsten Modul beantworten wir die Frage, die sich daraus ergibt: Wie stellen Sie sicher, dass das alles auch morgen noch stimmt?

16:13 Sie werden sehen, dass der Zugriffs-Layer dabei ein zweites Mal seinen Wert zeigt — diesmal als Teststrategie.