Runtime-Sicherheit und externe Daten

Runtime-Sicherheit und externe Daten

0:00 Jetzt präsentiert die Typlöschung aus Modul 1 die Rechnung. Alles, was wir gestern gebaut haben — sorgfältige Zustandsmodelle, Marken, generische Schnittstellen —, ist an der Systemgrenze zunächst nur eine Behauptung. Bis jemand prüft. Und das ist keine Schwäche von TypeScript, das ist die Arbeitsteilung: Der Compiler prüft den Code, nicht die Welt.

0:20 In diesem Modul bauen wir die andere Hälfte — die Stelle, an der aus fremden Daten geprüfte Domänentypen werden. Es ist eines der praktischsten Module des Seminars, denn hier sitzen erfahrungsgemäß die teuersten Fehler.

Runtime-Sicherheit und externe Daten

0:34 Der Leitsatz lautet: Der Compiler prüft den Code, nicht die Welt. Wir gehen die vier typischen Einfallstore durch — Schnittstellen, Formulare, Konfigurationen und Dateien —, sehen uns die Wahl zwischen Handarbeit und Schema-Bibliothek an und klären die Richtungsfrage: Wer definiert die Wahrheit, der Typ oder das Schema?

0:53 Zum Schluss ein Thema, das heute jeden betrifft: strukturierte Antworten von Sprachmodellen. Vorweg die Antwort — sie bekommen keinen Sonderweg.

Warum der Compiler hier nicht hilft

1:02 Der Rückverweis auf Modul 1 lohnt sich hier ausdrücklich. Die Aussage haben Sie gehört: Ein Typ ist eine Aussage über den Code, nicht über die Daten. Die Konsequenz daraus zieht im Alltag aber kaum jemand von allein — und genau die buchstabieren wir jetzt aus. Was über das Netz, aus einer Datei, aus einem Formular oder aus einer Konfiguration hereinkommt, ist zur Laufzeit beliebig.

1:25 Und der Compiler hat diesen Moment nie gesehen — er war zu diesem Zeitpunkt längst nicht mehr im Raum. Er prüft, was im Quelltext behauptet wird, und die Behauptung überlebt das Übersetzen nicht. Der Satz, den ich Ihnen mitgeben möchte, steht am Ende: Ein Typ an dieser Stelle ist eine Annahme mit guter Formatierung. Das ist keine Polemik, sondern eine präzise Beschreibung.

1:47 Sie sieht aus wie eine Zusicherung, und sie ist eine Notiz. Vier Orte, an denen genau das täglich passiert. Der Rückgabetyp einer Funktion, die eine Antwort auspackt — jemand hat hingeschrieben, was zurückkommen soll. Das Ergebnis des JSON-Auspackens, das laut Signatur jeder Typ sein darf. Werte aus der Umgebung, die immer Zeichenketten sind, auch wenn im Typ „Zahl" steht.

2:11 Und, besonders lehrreich: eine markierte Kennung aus Modul 5, die an dieser Stelle nur behauptet ist. Die Marke sagt „geprüft" — aber geprüft hat niemand. Marken sind erst dann wertvoll, wenn sie ausschließlich hinter einer echten Prüfung vergeben werden. Der zweite Punkt ist der verbreitetste Irrtum in diesem Feld: zu glauben, strenge Prüfung oder das bloße Vorhandensein einer Schema-Bibliothek erledige das automatisch.

2:37 Beides tut es nicht — die Bibliothek prüft, wenn Sie sie aufrufen, und keine Sekunde früher. Der erste Punkt ist die Grundverwechslung, über die wir gerade gesprochen haben. Und der dritte ist ein Architekturfehler mit Spätfolgen: die Prüfung tief im Code verstecken, statt sie an die Grenze zu legen. Dann weiß bald niemand mehr, welcher Wert im System geprüft ist und welcher nicht.

unknown als Ausgangspunkt

2:59 Die Lösung ist verblüffend einfach und kostet ein Wort. Wir haben sie in Modul 2 schon vorbereitet: Was man nicht benutzen kann, muss man prüfen. Sehen wir uns an, wie man diese Regel an einer echten Grenze umsetzt. Wer eingehende Daten als unbestimmt annimmt, kann sie nicht versehentlich verwenden — der Compiler lässt es schlicht nicht zu.

3:20 Der Weg zum Domänentyp führt dann zwangsläufig durch eine Prüfung. Und jetzt kommt der Teil, der über die reine Technik hinausgeht: Diese Prüfung ist im Code sichtbar, sie hat einen Namen, und sie ist im Review auffindbar. Man kann darüber sprechen. Genau das leistet der abschaltende Typ nicht: Dort gibt es keine Prüfung, über die man sprechen könnte, und niemandem fällt ihr Fehlen auf.

3:42 Achten Sie auf die kleine Warnung im Kommentar, denn sie ist der ganze Knackpunkt: Das Auspacken einer Antwort liefert von Haus aus den abschaltenden Typ, nicht den unbestimmten. Sie landen also ohne Ihr Zutun im bequemen Fall — und der ist der gefährliche. Die Annotation in der ersten Zeile ist der ganze Trick, wie die Fußzeile sagt: Sie macht aus einer stillen Bequemlichkeit eine erzwungene Entscheidung.

4:05 Danach ist nichts mehr benutzbar, ohne durch die Prüfung zu gehen. Ein Wort, eine Zeile — und die Grenze steht. Alle drei Punkte sind Wege, die gerade gebaute Grenze wieder zu untergraben. Erstens: das Auspacken ohne Annotation verwenden und still beim abschaltenden Typ landen — der Standardfall, wenn niemand hinsieht. Zweitens: den unbestimmten Wert per Behauptung in den Zieltyp zwingen, statt ihn zu prüfen; das ist die elegant aussehende Kapitulation.

4:33 Und drittens, besonders ärgerlich, weil die Arbeit schon getan war: die Prüfung schreiben und den ungeprüften Wert danach trotzdem weiterreichen. Passiert häufiger, als man denkt — meist, weil zwei Variablen im Spiel sind.

Die vier Einfallstore

4:47 Sehen wir uns an, wo fremde Daten in ein System kommen. Es sind im Wesentlichen vier Wege, sie sehen sehr verschieden aus — und sie folgen alle demselben Prinzip. Wer eine Grenze bauen kann, kann alle vier. Die rechte Spalte ist die interessante, denn sie versammelt die klassischen Überraschungen. Bei Schnittstellen: Ein Feld fehlt, es steht ein leerer Wert statt eines Werts, oder eine Zahl kommt als Text.

5:12 Bei Formularen ist die Überraschung grundsätzlicher — dort ist einfach alles Text, auch Zahlen und Datumsangaben. Bei Konfigurationen gilt eine leere Zeichenkette als gesetzt, und schon läuft die Anwendung mit einer Einstellung, die niemand gesetzt hat. Und bei Dateien sind es Kodierung, Trennzeichen und fehlende Spalten. Vier Quellen, ein gemeinsamer Nenner: Nichts davon ist so, wie der Typ es behauptet.

5:37 Fünf Schritte, und der Kern steckt in Schritt drei, wie die Fußzeile betont: prüfen und umwandeln an einem Ort, nicht an fünf. Verteilte Prüfungen sind fast so schlecht wie keine, weil niemand mehr weiß, welche gelaufen ist. Zuerst bestimmen Sie also die Stelle, an der die fremden Daten eintreffen. Dort nehmen Sie sie als unbestimmt an, nicht als Zieltyp. Sie prüfen und überführen in den Domänentyp.

6:01 Den Fehlerfall geben Sie als Wert zurück, statt ihn durchzureichen — das ist der Ergebnistyp aus Modul 3. Und dahinter arbeiten Sie ausschließlich mit geprüften Typen.

Von Hand oder mit Schema

6:11 Jetzt die Frage, an der sich Entwicklerrunden gern festbeißen: selbst schreiben oder Bibliothek? Ich nehme das Ergebnis vorweg — es ist kein Glaubenskrieg. Für drei Felder ist eine Bibliothek Aufwand ohne Gewinn, für dreißig ist Handarbeit ein Wartungsfall. Die Entscheidung hängt an Größe und Lebensdauer. Die entscheidende Zeile ist die dritte, denn sie beschreibt das strukturelle Problem der Handarbeit: Typ und Prüfung sind zwei Quellen, und zwei Quellen laufen mit der Zeit auseinander.

6:41 Nicht sofort, aber nach dem dritten Feld, das jemand nur an einer Stelle ergänzt hat. Eine Bibliothek hat eine Quelle. Die anderen Zeilen sind Abwägungen: Bei kleinen Modellen ist Handarbeit transparent und angemessen, bei großen trägt sie nicht mehr. Fehlermeldungen mit Pfadangabe bekommen Sie geschenkt, statt sie zu bauen. Und dafür handeln Sie sich eine Abhängigkeit mit eigener Fehlerkultur ein.

7:04 Oben die Handarbeit, und ich möchte, dass Sie auf einen Punkt achten: Diese Funktion prüft genau ein Feld. Sie braucht dafür schon vier Bedingungen — Objekt, nicht leer, Feld vorhanden, Feld vom richtigen Typ. Unten dasselbe mit einem Schema, in einer Zeile. Die Fußzeile zieht die Konsequenz: Bei zwölf Feldern mit Verschachtelung sieht die Handfassung sehr anders aus, und zwar deutlich unangenehmer.

7:27 Rechnen Sie diese Zeile im Kopf einmal hoch, dann haben Sie Ihr Entscheidungskriterium. Die Schreibweise unten ist übrigens beispielhaft — die Bibliotheken unterscheiden sich hier. Und jetzt der Grund, warum diese Debatte heute weniger wiegt als noch vor zwei Jahren. Es gibt inzwischen eine gemeinsame Schnittstelle, die mehrere Bibliotheken umsetzen — sie sprechen also eine gemeinsame Sprache.

7:50 Diese Schnittstelle wird als reines Typpaket ausgeliefert, ohne Laufzeitabhängigkeit. Werkzeuge brauchen dadurch keinen eigenen Adapter je Bibliothek mehr. Und daraus folgt der praktische Punkt: Ein Wechsel kostet weniger, als die Diskussion darüber dauert. Entscheiden Sie also, fangen Sie an, und behalten Sie im Hinterkopf, dass die Entscheidung revidierbar ist.

Schema-first oder type-first

8:12 Eine Richtungsfrage, die deutlich mehr Gewicht hat als die vorige: Wer definiert die Wahrheit — der Typ oder das Schema? Das klingt philosophisch, hat aber eine sehr handfeste Folge dafür, was in einem halben Jahr noch zusammenpasst. Zwei Reihenfolgen. Type-first: Der Typ steht zuerst, die Prüfung wird daneben geschrieben. Schema-first: Das Schema steht zuerst, der Typ wird daraus abgeleitet.

8:36 Und der zweite Weg hat einen strukturellen Vorteil, der im Alltag schwerer wiegt als jede Geschmacksfrage — Prüfung und Typ können gar nicht auseinanderlaufen, weil es nur eine Quelle gibt. Das ist dasselbe Prinzip, das uns in Modul 2 bei den Literallisten und in Modul 5 bei den Schlüsseloperatoren begegnet ist: Was einmal dasteht, kann nicht widersprüchlich werden.

8:58 Oben die erste Richtung: ein Typ, und irgendwo daneben — meist in einer anderen Datei — die passende Prüfung. Unten die zweite: ein Schema, aus dem der Typ abgeleitet wird. Die Fußzeile bringt den Unterschied auf den Punkt, und er ist kein technischer, sondern ein menschlicher: Bei der ersten Variante muss jemand daran denken, beide Seiten zu ändern.

9:19 Bei der zweiten gibt es nur eine Seite. Und Verlass auf „jemand denkt daran" ist im Softwarealltag die schwächste Absicherung, die es gibt — sie hält genau bis zum nächsten Zeitdruck. Der dritte Punkt ist der architektonisch wichtigste und wird oft übersehen: Domänentypen aus Transportschemata ableiten. Das ist bequem — Sie haben das Schema ja schon — und es koppelt Ihr Domänenmodell an das Format der Gegenseite. Ändert die ihr Feld, ändert sich Ihr Kern.

9:46 Trennen Sie das: Transportmodell an der Grenze, Domänenmodell dahinter, und die Umwandlung genau an der Grenze. Die anderen beiden Punkte sind bekannt: Typ und Schema parallel pflegen, oder ein Schema so schreiben, dass der abgeleitete Typ unlesbar wird.

OpenAPI, JSON Schema, generierte Typen

10:01 Oft ist die Schnittstelle bereits formal beschrieben — in einer Schnittstellenspezifikation oder einem Schema. Dann liegt es nahe, den Typ daraus zu generieren, statt ihn danebenzuschreiben. Ein guter Reflex, mit einer wichtigen Einschränkung, die wir uns gleich ansehen. Ist eine Schnittstelle bereits formal beschrieben, gehört der Typ daraus abgeleitet und nicht daneben geschrieben — dasselbe Prinzip wie eben, nur eine Ebene höher.

10:27 Zwei Einschränkungen sind mir wichtig. Erstens: Generierte Typen sind nur so verlässlich wie die Beschreibung, aus der sie stammen. Und Beschreibungen sind erfahrungsgemäß optimistisch. Zweitens, und das wird regelmäßig vergessen: Sie ersetzen die Laufzeitprüfung nicht. Auch generierte Typen verschwinden beim Übersetzen. Die Typlöschung kennt keine Ausnahme für gut gemeinte Typen.

10:50 Die zweite Zeile ist die entscheidende und lautet erfrischend klar: Nein, der generierte Typ passt nicht zu den echten Daten. Er passt zur Beschreibung. Eine Beschreibung ist aber kein Vertrag, sondern eine Absichtserklärung — was tatsächlich über die Leitung kommt, entscheidet die Gegenseite im Betrieb. Die dritte Zeile sagt entsprechend: Die Prüfung entfällt nicht.

11:12 Und die vierte hat eine nützliche Pointe: Änderungen fallen im Änderungssatz auf — aber nur, wenn tatsächlich neu generiert wird. Eine Generierung, die niemand mehr ausführt, ist eine besonders überzeugende Form von Altstand. Der erste Punkt ist ein Klassiker mit Ansage: generierte Typen von Hand nachbessern. Beim nächsten Lauf ist die Verbesserung weg — und wenn niemand neu generiert, um das zu vermeiden, ist man beim zweiten Punkt.

11:38 Der dritte ist aktuell und praktisch sehr relevant: Generatoren, die über die Compiler-Schnittstelle arbeiten, laufen mit Version 7.0 noch nicht, weil diese Schnittstelle erst mit 7.1 kommt. Prüfen Sie das, bevor Sie einen Migrationstermin zusagen — es ist genau die Werkzeugkettenfrage aus Modul 1.

Fehlerbehandlung an der Grenze

11:56 Jetzt die Frage, was eigentlich passieren soll, wenn die Prüfung fehlschlägt. Und die Antwort entscheidet über die Betriebsfähigkeit Ihres Systems: Ein Programmierfehler soll laut scheitern. Eine kaputte Fremdantwort soll behandelt werden. Das sind zwei völlig verschiedene Dinge. Eine fehlgeschlagene Validierung ist kein Programmierfehler, sondern ein erwartbarer Betriebszustand: Die Gegenseite hat etwas anderes geliefert als vereinbart.

12:22 Das passiert — bei Umstellungen, bei Störungen, bei Fehlern anderswo. Sie braucht deshalb zweierlei: eine Antwort, die dem Aufrufer weiterhilft, ohne interne Struktur preiszugeben, und einen Logeintrag, der die Analyse ermöglicht. Diese Zweiteilung ist wichtig — die eine Information geht nach außen, die andere nach innen, und sie sind nicht dieselbe.

12:44 Hier sehen Sie die Zweiteilung in Code. Der Pfad zur Fehlerstelle — also die Angabe, welches Feld nicht passte — wandert ins Log. Nach außen geht eine schlichte fachliche Aussage: Die Quelle ist gestört. Die Fußzeile erklärt, warum: Der Pfad verrät das Innere Ihres Modells, und das gehört nicht in eine Antwort an Fremde.

13:03 Beachten Sie außerdem, dass hier der Ergebnistyp aus Modul 3 arbeitet — der Erfolgsfall in der letzten Zeile ist überhaupt nur erreichbar, weil der Fehlerfall vorher behandelt wurde. Die Bausteine greifen ineinander. Vier Merkmale, und das letzte ist die schärfste Probe. Der Fehlerfall hat einen Namen, nicht nur eine Ausnahme.

13:23 Der Aufrufer kann reagieren, ohne die Fremdantwort zu kennen — er muss nichts über das fremde Format wissen. Das Log enthält genug für die Analyse und nichts Personenbezogenes; das ist auch eine Datenschutzfrage. Und dann der vierte: Hinter der Grenze taucht kein unbestimmter Wert und kein optionales Feld mehr auf. Wenn dahinter noch optionale Felder stehen, hat die Grenze ihre Arbeit nicht zu Ende gebracht.

KI-generierte strukturierte Daten

13:48 Und jetzt zu einem Fall, der in den letzten Jahren neu dazugekommen ist: strukturierte Antworten von Sprachmodellen. Ich mache es kurz und die Antwort steht in der Überschrift — dieselbe Grenze, ohne Sonderweg. Eine strukturierte Antwort eines Sprachmodells ist eine externe Antwort, auch wenn sie im eigenen Prozess entsteht.

14:07 Das ist der Punkt, an dem die Intuition täuscht: Es fühlt sich nach „unserem Code" an, weil kein Netzwerkaufruf sichtbar ist oder weil wir das Schema ja mitgegeben haben. Trotzdem kann die Antwort Felder auslassen, erfinden oder im falschen Format liefern. Sie gehört deshalb durch dieselbe Validierung wie eine fremde Schnittstelle — ohne Ausnahme.

14:27 Und dass eine Ausgabe schemakonform angefordert wurde, senkt die Trefferquote der Prüfung, nicht ihren Bedarf. Vier verbreitete Annahmen, und keine hält. Schema angefordert, also eingehalten? Nicht garantiert. Die Antwort ist im eigenen Prozess entstanden? Irrelevant — die Typlöschung gilt genauso. Ein Typ am Aufrufpunkt genügt? Nein, er verschwindet beim Übersetzen wie jeder andere.

14:52 Und die letzte Annahme ist die gefährlichste: Kaputte Antworten fallen schon auf. Die groben ja. Die stille Abweichung — ein Feld mit plausiblem, aber falschem Inhalt — fällt eben nicht auf, und die ist teurer. Sie wandert unbemerkt in Ihre Daten. Der zweite Punkt betrifft die Sicherheit und verdient Aufmerksamkeit: Freitextfelder ungeprüft weiterreichen, wo sie in eine Ausgabe wandern.

15:17 Was ein Modell erzeugt, kann Steuerzeichen, Auszeichnung oder eingebettete Anweisungen enthalten — behandeln Sie es wie jede andere Fremdeingabe, mit derselben Sorgfalt. Der erste Punkt ist die bekannte Abkürzung: die Modellantwort direkt in den Domänentyp behaupten. Und der dritte schlägt den Bogen zum letzten Kapitel: den Fehlerfall als Programmierfehler behandeln statt als Betriebszustand.

15:40 Modelle liefern gelegentlich unpassende Antworten — das ist normal, kein Ausnahmefall.

Übung — die Grenze zum Teilekatalog

15:46 Jetzt bauen Sie eine solche Grenze selbst. Das Ziel steht in der Überschrift und ist auch der Prüfstein: Hinter der Grenze nur noch geprüfte Typen. Und unter den Testdaten wartet ein Fall, der genau die Unterscheidung dieses Seminars verlangt. Das Lernziel: eine Systemgrenze so bauen, dass ungültige Fremddaten abgewiesen werden und dahinter nur geprüfte Domänentypen vorkommen.

16:09 Erfolgreich sind Sie, wenn alle vorgelegten fehlerhaften Antworten abgewiesen werden, keine per Behauptung durchgelassen wurde, und der Fehlerfall als Wert modelliert ist. Und achten Sie auf eine der Testantworten: Sie ist formal völlig gültig und fachlich unmöglich — ein negativer Preis. Genau daran zeigt sich der Unterschied zwischen Typ und Validierung aus Modul 4. Wer früh fertig ist, vergibt der geprüften Kennung eine Marke aus Modul 5.

16:35 Fünf Schritte, und der letzte ist eine Selbstprüfung mit Aussagekraft. Zuerst sehen Sie sich die gültige Antwort an und legen das Domänenmodell fest — in dieser Reihenfolge, damit das Modell nicht einfach das Transportformat abbildet. Dann bauen Sie die Grenze, lassen die fehlerhaften Antworten durchlaufen und notieren die Befunde. Der Fehlerfall wird als Wert modelliert, Log und Antwort werden getrennt.

16:59 Und dann fragen Sie sich: Ist hinter der Grenze noch ein optionales Feld nötig? Wenn ja, ist das Domänenmodell dem Transportformat gefolgt statt der Fachlichkeit. Vier Sätze zum Mitnehmen. Der Compiler prüft den Code, nicht die eintreffenden Daten — das ist der Kernsatz des Moduls. Der unbestimmte Typ an der Grenze macht die Prüfung erzwingbar und, fast ebenso wichtig, sichtbar.

17:22 Schema-first hält Typ und Prüfung dauerhaft zusammen, weil es nur eine Quelle gibt. Und Modellantworten sind Fremddaten — dieselbe Grenze, kein Sonderweg. Im nächsten Modul wechseln wir das Thema und schauen auf die Umgebung, in der all das läuft: Module, Auflösung und moderne Werkzeugketten.