Security by Design: Wie KI unbemerkt Sicherheitslücken in Webanwendungen erzeugt

KI kann Entwicklerinnen und Entwicklern viel Arbeit abnehmen. Ein API-Endpunkt, ein Formular, Tests oder eine Konfigurationsdatei sind oft in wenigen Minuten erstellt. Das ist praktisch, besonders dann, wenn ein Projekt unter Zeitdruck steht.

Genau darin liegt aber auch ein Risiko: Code kann funktionieren und trotzdem unsicher sein. Die Anwendung liefert die gewünschten Daten, der Login funktioniert, der Datei-Upload läuft. Aber was passiert, wenn jemand eine ID verändert, eine Eingabe manipuliert oder eine Anfrage ohne die nötige Berechtigung stellt?

Beim Programmieren mit KI geht es deshalb nicht darum, ob KI eingesetzt werden darf oder nicht. Die entscheidende Frage ist: Wie stellen Teams sicher, dass Geschwindigkeit nicht zulasten der Sicherheit geht? Genau hier setzen Security by Design und Security by Default an. Security by Design sorgt dafür, dass Sicherheitsanforderungen bereits bei der Planung, Entwicklung und Tests berücksichtigt werden, wohingegen Security by Default für sichere Standardeinstellungen für Anwendungen und Systeme steht.

Security by Design beginnt bereits beim Programmieren mit KI

Security by Design ist besonders wichtig, wenn Teams KI zum Entwickeln von Code einsetzen, denn funktionierender Code erfüllt nicht automatisch alle Sicherheitsanforderungen. Autorisierung, Eingabevalidierung oder sichere Konfigurationen müssen weiterhin bewusst geprüft werden.

KI-generierter Code wirkt oft überzeugend. Er ist sauber eingerückt, kommentiert und passt auf den ersten Blick zum verwendeten Framework. Wenn die Funktion anschließend noch den gewünschten Test besteht, ist der nächste Schritt schnell gemacht: Code übernehmen, Pull Request erstellen, weiter zum nächsten Ticket.

Gerade unter Zeitdruck passiert das schnell. Die KI liefert eine plausible Lösung, die Tests sind grün, und der Pull Request soll noch vor dem Sprint-Ende fertig werden. Die Frage, ob wirklich jede Berechtigung geprüft wurde oder ob ein sicherer Default fehlt, rutscht dann leicht nach hinten.

Das Problem: Viele Tests prüfen vor allem den normalen Ablauf. Ein:e Nutzer:in meldet sich an, ruft Daten ab oder lädt eine Datei hoch. Angreifer:innen interessieren sich jedoch selten für diesen normalen Ablauf. Sie probieren aus, was passiert, wenn Parameter verändert, Berechtigungen umgangen oder ungewöhnliche Eingaben gesendet werden.

Eine Untersuchung von Veracode zeigte, dass bei 45 Prozent der getesteten KI-generierten Codeaufgaben Sicherheitsprobleme auftraten. Besonders bei Cross-Site Scripting und Log Injection lieferten die getesteten Modelle häufig keinen ausreichenden Schutz.

Das bedeutet nicht, dass KI-Code grundsätzlich unsicher ist, es bedeutet: Er braucht dieselbe sorgfältige Prüfung wie jeder andere Code, und bei sicherheitskritischen Funktionen oft noch mehr Aufmerksamkeit. Dies ist besonders beim Vibe Coding, bei dem Entwickler:innen größere Teile der Umsetzung an KI-Assistenten delegieren, ein wichtiger Faktor, denn: Je weniger Code manuell geschrieben wird, desto wichtiger werden strukturierte Reviews, Tests und Sicherheitskontrollen.

Wenn „eingeloggt“ nicht ausreicht

Ein typischer Fehler in Webanwendungen betrifft die Autorisierung. Eine Anwendung prüft, ob ein:e Nutzer:in angemeldet ist. Das ist wichtig, reicht aber nicht aus.

Stellen Sie sich einen Kundenbereich vor. Dort kann eine Rechnung über eine URL wie diese abgerufen werden: /api/invoices/4711

Die KI erstellt einen funktionierenden Endpunkt. Die Rechnung wird aus der Datenbank geladen und an den angemeldeten Nutzer bzw. die angemeldete Nutzerin zurückgegeben. Im ersten Test sieht alles richtig aus.

Doch eine Frage bleibt offen: Gehört die Rechnung mit der ID 4711 wirklich zu dieser Person?

Wenn der Server diese Prüfung nicht durchführt, kann eine angemeldete Nutzerin oder angemeldeter Nutzer möglicherweise einfach eine andere Rechnungs-ID ausprobieren. Die Anwendung ist dann technisch funktionsfähig, aber fachlich und sicherheitstechnisch fehlerhaft.

Die Lösung ist nicht kompliziert, wird aber leicht vergessen: Die Autorisierung muss serverseitig erfolgen und direkt in die Datenabfrage einfließen. Eine Rechnung darf nur dann zurückgegeben werden, wenn sie sowohl zur angefragten ID als auch zum Konto der angemeldeten Person passt.

Genau solche Fehler entstehen häufig, wenn Teams nur prüfen, ob eine Funktion funktioniert, nicht, ob sie auch unter falschen oder böswilligen Bedingungen sicher bleibt.

Sechs Risiken beim Programmieren mit KI, die Security by Design adressiert

1. Eingaben wird zu schnell vertraut

Eingaben sollten grundsätzlich als nicht vertrauenswürdig behandelt werden unabhängig davon, ob sie aus einem Formular, einer API, einem Cookie oder einer internen Schnittstelle stammen.

KI kann eine Datenbankabfrage erzeugen, die im Test korrekt arbeitet, aber Eingaben direkt in eine Abfrage übernimmt. Daraus können SQL Injection, Cross-Site Scripting oder Command Injection entstehen.

Die Grundregel bleibt einfach: Validieren Sie Eingaben auf dem Server. Verwenden Sie parametrisierte Datenbankabfragen. Bereiten Sie Ausgaben so auf, dass sie im jeweiligen Kontext sicher dargestellt werden.

2. Neue Abhängigkeiten werden nicht geprüft

Ein KI-Assistent schlägt ein Paket vor, das genau zur Aufgabe zu passen scheint. Der Name klingt plausibel, die Installation funktioniert, also wird die Bibliothek übernommen.

Aber wer pflegt dieses Paket? Wann wurde es zuletzt aktualisiert? Gibt es bekannte Schwachstellen? Ist es überhaupt das Paket, das ursprünglich gemeint war?

Solche Fragen werden im Arbeitsalltag leicht übergangen. Besonders dann, wenn eine Lösung schnell gebraucht wird. Ungeprüfte Abhängigkeiten können jedoch Sicherheitsrisiken in die gesamte Anwendung bringen. Prüfen Sie neue Pakete deshalb genauso wie Code: Herkunft, Aktualität, bekannte Schwachstellen und tatsächliche Notwendigkeit.

3. Wenn ein Paketname zum Risiko wird

Ein Team benötigt kurzfristig eine Bibliothek, um Dateien in einem bestimmten Format zu verarbeiten. Die KI schlägt ein Paket mit einem plausiblen Namen vor. Niemand prüft genauer nach, weil der Name logisch klingt und die Installation problemlos durchläuft.

Später stellt sich heraus: Das empfohlene Paket ist kaum gepflegt, nicht etabliert oder hat schlicht einen anderen Namen als ursprünglich gemeint. Im ungünstigsten Fall wird ein nicht existierender Paketname später von Angreiferinnen und Angreifern registriert und mit Schadcode versehen. Dieses Risiko gehört zur Software Supply Chain.

Nicht jeder KI-Vorschlag ist falsch. Aber ein Paketname aus einer KI-Antwort ist noch keine Vertrauensentscheidung. Prüfen Sie deshalb Repository, Maintainer:innen, Aktualität, Lizenz, Downloads und bekannte Schwachstellen, bevor eine neue Abhängigkeit in ein Projekt aufgenommen wird.

4. Secrets landen dort, wo sie nicht hingehören

Ein API-Key direkt in einer Konfigurationsdatei, ein Datenbankpasswort in einem Codebeispiel oder ein Token, der versehentlich in einem Git-Repository landet. Das sind keine exotischen Ausnahmefälle, sondern typische Fehler aus dem Entwicklungsalltag.

Ein Team kopiert beispielsweise eine KI-generierte Konfiguration in ein neues Projekt. Darin steht ein API-Key als Platzhalter. Für lokale Tests funktioniert alles. Später wird aus dem Platzhalter ein echter Schlüssel, die Datei versehentlich eingecheckt und in ein Remote-Repository übertragen. Der Fehler wirkt klein, können aber große Folgen nach sich ziehen..

KI kann solche Muster aus Vereinfachungsgründen vorschlagen. Kritisch wird es, wenn Beispiele unverändert übernommen werden oder wenn Entwickler:innen echte Zugangsdaten in einen Prompt kopieren, um ein Problem schneller zu lösen.

Secrets gehören in einen zentral verwalteten Secret Manager oder in entsprechend geschützte Umgebungsvariablen, nicht in den Quellcode, nicht in Tickets und nicht in externe KI-Anfragen.

5. Sichere Konfigurationen fehlen

Nicht jede Sicherheitslücke ist eine Zeile fehlerhafter Anwendungscode. Häufig entsteht das Problem durch eine Einstellung, die in der lokalen Entwicklung bequem ist, in Produktion aber nichts verloren hat.

Dazu gehören beispielsweise:

• Aktivierter Debug-Modus
• Zu weit geöffnete CORS-Regeln
• Detaillierte Fehlermeldungen mit internen Informationen
• Öffentlich erreichbare Administrationsoberflächen
• Fehlende Größen- und Typbeschränkungen bei Datei-Uploads
• Container mit unnötig hohen Berechtigungen

Hier kommt Security by Default ins Spiel. Die sichere Einstellung sollte der Normalfall sein. Wer davon abweichen möchte, sollte dafür einen nachvollziehbaren Grund haben.

6. Tests vermitteln ein falsches Sicherheitsgefühl

KI kann schnell Unit Tests schreiben. Das ist hilfreich, aber kein Beweis dafür, dass ein Feature sicher ist.

Ein Test kann bestätigen, dass ein:e Nutzer:in die eigene Rechnung sieht. Er beantwortet aber nicht automatisch die wichtigere Sicherheitsfrage: Kann dieselbe Person auch eine Rechnung eines anderen Kontos abrufen?

Gute Tests prüfen deshalb nicht nur den Erfolgsfall. Sie testen auch fehlende Berechtigungen, manipulierte IDs, ungültige Eingaben, zu große Uploads oder wiederholte Anfragen. Kurz gesagt: Nicht nur „Funktioniert es?“, sondern auch „Was passiert, wenn jemand die Funktion missbrauchen will?“.

Entscheidend bleibt: Tests sollten nicht nur Happy Paths prüfen, sondern auch unberechtigte Zugriffe, Fehlerfälle und Missbrauchsszenarien abdecken.

Risiken, die man im Code nicht sofort sieht

Viele Probleme sind nicht auf den ersten Blick sichtbar. Sie entstehen durch die Art, wie Teams mit KI arbeiten.

Ein Beispiel ist die Übernahme von Code ohne ausreichendes Verständnis. Wenn niemand im Team erklären kann, warum eine Berechtigungsprüfung an einer bestimmten Stelle notwendig ist oder warum ein Token so konfiguriert wurde, ist das ein Warnsignal. Das gilt besonders für Authentifizierung, Autorisierung, Kryptografie und den Umgang mit sensiblen Daten.

Auch kleine Änderungen verdienen Aufmerksamkeit. Eine KI soll eine Funktion „aufräumen“, „vereinfachen“ oder „schneller machen“. Dabei kann eine Validierung verschwinden, ein Rate Limit wegfallen oder eine sichere Fehlerbehandlung verloren gehen. Der Code wird kürzer,  aber nicht unbedingt besser.

Hinzu kommt die Frage der Verantwortung. Eine KI kann Vorschläge machen. Sie kann aber keine Verantwortung für eine produktive Anwendung übernehmen. Diese Verantwortung bleibt bei den Entwicklerinnen und Entwicklern, den Code Ownern und letztlich beim Unternehmen.

Security by Design beginnt vor dem Prompt

Security by Design bedeutet nicht, dass jedes Team vor jedem Ticket ein umfangreiches Sicherheitskonzept schreiben muss. Es bedeutet, früh die richtigen Fragen zu stellen.

Sicherheit sollte nicht erst dann Thema werden, wenn ein Feature bereits fertig ist. Das NIST Secure Software Development Framework greift genau diesen Gedanken auf: Sicherheitsanforderungen, klare Verantwortlichkeiten und Prüfungen gehören in den gesamten Entwicklungsprozess.

Gerade bei Vibe Coding und LLM-gestützten Services kommen zusätzliche Fragen hinzu: Welche Daten gehen an das Modell? Welche Tools darf ein Agent verwenden? Welche Rechte erhält er? Wie werden Prompt Injection, Secrets, Abhängigkeiten und Ausgaben kontrolliert?

Das muss nicht kompliziert sein. Am Beispiel eines neuen API-Endpunkts, der von einem Coding Assistant vorgeschlagen wird, zeigt sich das gut: Es kann bereits reichen, berechtigte Rollen festzulegen, erwartete Eingaben zu dokumentieren und einen negativen Testfall einzuplanen.

Security-by-Design-Checkliste für sichere Softwareentwicklung vor dem Merge

Bevor KI-generierter oder KI-überarbeiteter Code in den produktiven Branch gelangt, sollten die folgenden Prüfpunkte beantwortet werden können, die sich unter anderem an etablierten Verfahren der sicheren Softwareentwicklung orientieren und typische Anforderungen des Application Security Verification Standard (ASVS) von OWASP aufgreifen. Werden alle Eingaben serverseitig geprüft?

• Nutzen Datenbankzugriffe parametrisierte Abfragen oder sichere ORM-Mechanismen?
• Wird für jede geschützte Ressource geprüft, ob die angemeldete Person darauf zugreifen darf?
• Enthält der Code keine API-Keys, Tokens oder Zugangsdaten?
• Sind neue Abhängigkeiten geprüft und dokumentiert?
• Ist der Debug-Modus in Produktion deaktiviert?
• Decken die Tests auch unberechtigte Zugriffe und manipulierte Eingaben
• Hat mindestens eine zweite qualifizierte Person den Code geprüft?

Fazit

KI spart etwa durch Methoden wie Vibe Coding Zeit. Das steht außer Frage. Sie kann aber auch dazu führen, dass Teams Code übernehmen, den sie nur oberflächlich geprüft haben. Die gefährlichsten Sicherheitslücken entstehen oft nicht durch spektakuläre Fehler, sondern durch kleine Annahmen: „Die Person ist ja eingeloggt“, „Das Paket wird schon passen“ oder „Die Tests sind grün“.

Security by Design sorgt dafür, dass Sicherheit bereits bei Anforderungen, Architektur und Umsetzung berücksichtigt wird. Security by Default ergänzt diesen Ansatz, indem sichere Einstellungen nicht erst nachträglich aktiviert werden müssen.

KI kann Entwicklungsteams stärker machen. Voraussetzung ist, dass sie als Unterstützung genutzt wird – nicht als Ersatz für sichere Softwareentwicklung.

Wissen in die Praxis bringen

Für IT-, Plattform-, Cloud-, Security- und Delivery-Teams, die LLM-gestützte Services produktionsnah aufbauen oder Coding Assistants kontrolliert einsetzen möchten, bietet VibeCoding für IT: LLM-Services sicher betreiben einen praxisnahen Rahmen. Das Training behandelt Architektur, Datenzugriff, Qualitäts- und Security-Gates, Observability sowie Betrieb und Rollout.ibm

Für eine vertiefte Architekturperspektive bietet sich zudem der iSAQB CPSA Advanced Level WEBSEC an. Dort steht die Sicherheit von Webanwendungen als Bestandteil professioneller Softwarearchitektur im Mittelpunkt.

Security by Design erfolgreich verankern

Ob sichere Softwareentwicklung, Security by Design oder der kontrollierte Einsatz von Coding Assistants: Entscheidend sind die richtigen Kompetenzen und Prozesse. Wir unterstützen Sie dabei, passende Qualifizierungs- und Entwicklungswege für Ihre Teams zu gestalten.

Beratung anfragen

FAQ: Häufig gestellte Fragen zu Security by Design, KI-Code und sicherer Softwareentwicklung

War dieser Artikel hilfreich für Sie?

Geschrieben von

Sadek Murad

Sadek Murad entwickelt als Produktmanager für die Themenbereiche Cloud, Cybersecurity und SAP zukunftsorientierte und praxisnahe Lernformate für Unternehmen. Seine Kernkompetenz liegt dabei vor allem im Bereich der Cloud Architekturen und der Automatisierung. Durch seine Erfahrung im IT-Consulting und Weiterbildungen in AWS, Azure, Docker sowie Kubernetes kennt er die aktuellen Herausforderungen der IT-Landschaft. Sein Anspruch: Organisationen technologisch zukunftssicher aufstellen und nachhaltige Kompetenzen mit echtem Mehrwert vermitteln.