Worum es geht: Sicherheit lässt sich nicht nachträglich anbauen. Die meisten Lücken entstehen nicht durch raffinierte Angriffe, sondern durch sechs immer gleiche Versäumnisse – und alle sechs kosten beim Bauen wenige Minuten.
1. Sechs Versäumnisse
Die häufigste schwere Lücke: Eine Schnittstelle prüft, ob jemand angemeldet ist, aber nicht, ob er genau diesen Datensatz sehen darf. Wer die Kennung in der Adresse hochzählt, sieht fremde Daten. Abhilfe: zentrale Prüfung bei jedem Zugriff, plus ein Test mit zwei Konten.
2. Die zwei Grundregeln
Niemandem trauen, der von außen kommt. Jede Eingabe wird geprüft, bevor sie verwendet wird – Formulardaten, Adressparameter, Dateien, Antworten fremder Dienste und auch Ausgaben von Sprachmodellen. Der Unterschied zwischen Prüfen und Vertrauen ist der Unterschied zwischen einer Anwendung und einer Lücke.
So wenig Rechte wie möglich. Das Datenbankkonto der Anwendung braucht keine Rechte, Tabellen zu löschen. Der Server braucht keinen Zugriff auf andere Systeme. Ein KI-Agent braucht keinen Schreibzugriff auf das gesamte Dateisystem. Jedes Recht, das nicht vergeben ist, kann nicht missbraucht werden.
3. Was der Browser mitbringt
| Maßnahme | Wogegen |
|---|---|
| HTTPS überall, mit HSTS | Mitlesen und Verändern unterwegs |
| Content-Security-Policy | Eingeschleustes fremdes JavaScript |
| Cookies mit HttpOnly, Secure und SameSite | Diebstahl der Sitzung und Anfragen von fremden Seiten |
| X-Content-Type-Options: nosniff | Dateien, die als etwas anderes ausgeführt werden |
Diese vier Kopfzeilen sind in einer halben Stunde eingerichtet und decken eine ganze Klasse von Angriffen ab. Viele Rahmenwerke setzen sie mit einer einzigen Einstellung.
4. Der besondere Fall: KI-Systeme
Bei Anwendungen mit Sprachmodellen kommt eine Angriffsart hinzu, die es vorher nicht gab. Wenn ein Modell Text aus einer fremden Quelle liest – eine Webseite, eine E-Mail, ein hochgeladenes Dokument – und dieser Text Anweisungen enthält, kann er das Verhalten des Systems verändern. Das ist keine theoretische Gefahr, sondern die zentrale Sicherheitsfrage bei Agenten.
Die Abwehr besteht aus drei Teilen. Erstens: Fremder Text ist Material, nie Anweisung – das gehört ausdrücklich in die Systemanweisung. Zweitens: Der Agent bekommt nur die Werkzeuge und Rechte, die er für seine Aufgabe braucht. Drittens: Alles mit Außenwirkung – E-Mails, Zahlungen, Löschungen – geht über eine menschliche Freigabe. Ausführlich behandelt das der Beitrag zu Human in the Loop.
5. Vor dem Livegang
Eine kurze Prüfliste, die jemand abhakt: HTTPS erzwungen, Schlüssel nicht im Code und nicht in Git, Rechteprüfung mit zwei Testkonten geprüft, Abhängigkeiten auf bekannte Lücken geprüft, Fehlermeldungen verraten keine Interna, Sicherung eingerichtet und einmal zurückgespielt, Datenschutzerklärung und Verzeichnis der Verarbeitungstätigkeiten aktuell.
Sieben Punkte, eine Stunde Arbeit. Das ist die günstigste Versicherung, die ein Projekt kaufen kann.
6. Häufige Fragen
Brauchen wir einen Penetrationstest? Bei Anwendungen mit sensiblen Daten oder Zahlungsverkehr ja. Für eine Unternehmenswebsite genügt die Prüfliste plus automatische Abhängigkeitsprüfung.
Was tun bei einem Vorfall? Zugänge sperren, Schlüssel austauschen, Protokolle sichern, Umfang feststellen. Bei personenbezogenen Daten gilt die Meldefrist von 72 Stunden – das sollte vorher jemand wissen, nicht erst am Tag danach.
Wie oft aktualisieren? Sicherheitsaktualisierungen zeitnah, alles andere in einem festen monatlichen Termin. Wer nur bei Problemen aktualisiert, steht irgendwann vor einem Sprung über mehrere Hauptversionen.
Stand: September 2026. Die Übungen laufen vollständig in Ihrem Browser – es wird nichts gespeichert oder übertragen.