KI-Tools machen es heute jedem möglich, in wenigen Stunden eine Website oder App zu bauen. Das ist großartig. Bis du merkst, dass das Modell dabei reihenweise rechtliche und technische Fallen eingebaut hat, die es selbst gar nicht als Problem erkennt.

Ich sehe das immer wieder. Schöne Seiten, sauberer Look, aber unter der Haube tickt eine Zeitbombe. Hier sind acht typische Fallstricke, die mir bei KI-generierten Websites regelmäßig begegnen.

1. Veralteter Paragraph im Impressum: § 5 TMG statt § 5 DDG

Viele KI-Modelle verweisen im Impressum noch brav auf „§ 5 TMG“ oder das „Telemediengesetz“. Problem: Das TMG ist am 14. Mai 2024 vom Digitale-Dienste-Gesetz (DDG) abgelöst worden. Die Pflichtangaben sind inhaltlich nahezu identisch, aber die Rechtsgrundlage heißt jetzt § 5 DDG. Auch das TTDSG wurde zum TDDDG umbenannt.

Ein Verweis auf eine nicht mehr existierende Norm kann als irreführend gelten und damit abmahnfähig. Also: Impressum prüfen, „TMG“ durch „DDG“ und „TTDSG“ durch „TDDDG“ ersetzen.

2. Google Fonts werden live von Google geladen

Klassiker. Die KI baut dir <link href="https://fonts.googleapis.com/..."> in den Head, und schon überträgt jeder Seitenaufruf die IP-Adresse deiner Besucher an Google-Server in den USA. Das LG München I (Az. 3 O 17493/20) hat das 2022 als DSGVO-Verstoß eingestuft, 100 € Schadensersatz pro Vorfall.

Lösung: Fonts herunterladen, lokal hosten, per @font-face einbinden. Spart nebenbei einen externen HTTP-Request und macht die Seite schneller. Übrigens dieselbe Logik bei Font Awesome, Adobe Fonts oder eingebetteten YouTube- und Vimeo-Videos.

3. Ungeschützte .env-Datei auf dem Server

Wenn deine KI dir eine Node-, PHP- oder Python-App baut, landen API-Keys, DB-Passwörter und Tokens meist in einer .env-Datei. Bequem, aber Webserver liefern diese Datei standardmäßig oft aus, wenn jemand deinedomain.de/.env aufruft. Bots scannen genau danach im Sekundentakt.

Checkliste:

• .env gehört in .gitignore (sonst landet sie im Git-Repo)
• Webserver-Regel: Dateien, die mit . beginnen, blockieren (.htaccess bei Apache, location ~ /\. bei Nginx)
• Secrets idealerweise gar nicht auf der Web-Wurzel ablegen, sondern eine Ebene höher

4. API-Keys hardgecodet im Frontend

Verwandte Falle: Die KI schreibt „schnell mal“ einen Stripe-, OpenAI- oder Supabase-Key direkt ins JavaScript. Im Browser sichtbar heißt öffentlich. Eine Studie von Invicti zeigt, dass über die Hälfte vibe-codeter Apps exponierte Credentials enthält. Faustregel: Wenn ein Key „secret“ im Namen hat, gehört er hinter ein Backend, nie ins Frontend.

5. Datenschutzerklärung erwähnt Dienste nicht, die tatsächlich laufen

Die KI generiert gerne eine Standard-Datenschutzerklärung mit den drei Klassikern (Google Analytics, Server-Logs, Kontaktformular). Was sie nicht macht: prüfen, was die Seite wirklich lädt. Maps-Einbettungen, reCAPTCHA, Calendly-Iframes, Schriftarten von Adobe, ein Hotjar-Snippet, alles potenziell trackend, alles nicht erwähnt. Das ist ein DSGVO-Verstoß und gleichzeitig ein Abmahnpunkt.

Tipp: Nutze einen Tracker-Scanner wie Webbkoll oder die DevTools (Network-Tab), um zu sehen, welche Drittanbieter wirklich aufgerufen werden.

6. Cookie-Banner ohne echte Funktion

Klassisches KI-Pattern: „OK“-Button und ein Banner-Design, aber dahinter passiert nichts. Cookies werden trotzdem vor der Einwilligung gesetzt, „Ablehnen“ ist gleichwertig zu „Akzeptieren“ oder fehlt komplett. Nach § 25 TDDDG braucht es eine aktive, informierte Einwilligung vor dem Setzen nicht-essenzieller Cookies, und das Ablehnen muss genauso einfach sein wie das Zustimmen.

7. Formulare ohne Schutz und Validierung

Kontaktformulare, die die KI baut, sind oft offene Scheunentore:

• Keine Server-seitige Validierung (nur Client-seitig, trivial umgehbar)
• Kein Spam-Schutz (Honeypot, Rate-Limiting oder Friendly-Captcha)
• Daten werden ungefiltert per Mail verschickt, also Header-Injection möglich
• Bei DB-Anbindung: String-Konkatenation statt Prepared Statements, also SQL-Injection

Letzteres ist laut Analysen von Anfang 2026 in rund einem Drittel KI-generierter Apps ausnutzbar vorhanden. Das ist kein Randproblem.

8. Permissive Defaults: CORS, Datenbankrechte, Standardpasswörter

KI optimiert auf „läuft“, nicht auf „sicher“. Typische Folgen:

• Access-Control-Allow-Origin: *, weil das Errors während der Entwicklung wegmacht
• Supabase oder Firebase ohne aktivierte Row Level Security, sodass jeder alle Daten lesen kann
• Admin-Konten mit Demo-Passwort, die in Produktion landen
• Datenbank-User mit vollen Rechten statt minimal nötigen Berechtigungen

Beim Anbieter Moltbook führte genau dieses Muster im Februar 2026 dazu, dass 1,5 Millionen Auth-Tokens und 35.000 E-Mail-Adressen öffentlich abrufbar waren. Komplett ohne Hack, nur durch unreviewte KI-Defaults.

Bonus-Fallen, die ich auch oft sehe

• Halluzinierte npm- oder pip-Pakete: Die KI schlägt Pakete vor, die es gar nicht gibt, oder die Angreifer kürzlich unter dem halluzinierten Namen registriert haben (Slopsquatting).
• Fehlende SECURITY.md und kein Update-Pfad: Keine Strategie für npm audit, pip-audit oder Dependabot.
• HTTP-Header fehlen: Keine CSP, kein HSTS, kein X-Frame-Options.
• Fehlende Barrierefreiheit: Seit Juni 2025 (BFSG) für viele Anbieter Pflicht. KI ignoriert das standardmäßig.

Mein Fazit

KI ist ein hervorragender Co-Pilot, aber ein katastrophaler Solo-Pilot. Das Vier-Augen-Prinzip, das ich in meinem Workflow mit Claude Code und Codex CLI fahre, gilt genau hier. Lass ein zweites Modell, oder besser noch einen Menschen mit Security-Mindset, gezielt nach diesen Mustern suchen. Ein Prompt wie „Prüfe diesen Code auf hardcodete Secrets, exponierte .env-Dateien, fehlende Eingabevalidierung und veraltete Rechtsverweise“ findet erstaunlich viel.

KI baut die Seite. Die Verantwortung bleibt bei dir.