5 Sicherheitsfehler, die jeder Vibe Coder macht (und wie man sie behebt)

Von KI generierter Code funktioniert. Er läuft. Er sieht richtig aus. Er wird aber auch mit den gleichen fünf Sicherheitslücken in fast jedem Projekt ausgeliefert. Das sind keine theoretischen Risiken — das sind die spezifischen Lücken, die in fast jedem von Claude, Cursor, Replit oder Copilot erstellten Codebase auftauchen, wenn du nicht ausdrücklich um Sicherheit fragst.

Ich habe im vergangenen Jahr Dutzende von vibe-codierten Projekten überprüft, und die gleichen fünf Fehler treten in mindestens 80% von ihnen auf. Jeder davon dauert weniger als 30 Minuten, um ihn zu beheben. Hier ist, worauf du achten musst und wie du es genau behebst.

Fehler 1: API-Schlüssel im Frontend-Code hartcodiert

Wie es passiert: Du sagst Claude „verbinde mit Supabase" oder „füge Stripe-Zahlungen hinzu", und es generiert Code mit dem API-Schlüssel, der direkt in eine React-Komponente eingefügt ist. Der Code funktioniert perfekt — und dein geheimer Schlüssel ist für jeden sichtbar, der die Browser DevTools öffnet und den Network-Tab oder die JavaScript-Quelle überprüft.

Warum es gefährlich ist: Dein Supabase-Service-Role-Schlüssel umgeht alle Datenbanksicherheitsmaßnahmen. Dein Stripe-Geheimschlüssel ermöglicht es jemandem, Karten zu belasten oder Rückerstattungen zu erteilen. Dein OpenAI-Schlüssel ermöglicht es jemandem, Tausende in API-Aufrufen auf deinem Konto zu verursachen. Bots scannen aktiv öffentliche GitHub-Repos und bereitgestellte Websites nach exponierten Schlüsseln.

Die Lösung: Verschiebe alle Geheimnisse in Umgebungsvariablen. In Next.js erreichen nur Variablen, die mit NEXT_PUBLIC_ beginnen, den Browser. Alle Schlüssel, die Schreibzugriff, Admin-Zugriff oder Finanzzugriff gewähren, sollten nur serverseitig sein.

Nachdem du Schlüssel in .env.local verschoben hast, suche deine gesamte Codebasis nach den alten Schlüsselwerten, um sicherzustellen, dass sie weg sind. Überprüfe dann dein Git-Verlauf — wenn der Schlüssel jemals committed wurde, ist er immer noch in deinem Repo-Verlauf, auch wenn du ihn gelöscht hast. Regeneriere (rotiere) jeden Schlüssel, der jemals exponiert war, auch nur kurz.

Zeit zum Beheben: 15–30 Minuten.

Fehler 2: Supabase-Tabellen ohne Row-Level Security

Wie es passiert: KI generiert Supabase-Tabellen-Abfragen und CRUD-Operationen, aktiviert aber Row-Level Security (RLS) nicht. Standardmäßig sind Supabase-Tabellen mit deaktiviertem RLS vollständig für jeden mit deiner Projekt-URL und deinem Anon-Schlüssel zugänglich — beide sind öffentlich (und sollten es sein).

Warum es gefährlich ist: Ohne RLS kann Nutzer A die Daten von Nutzer B abfragen. Ein einfacher fetch-Aufruf von der Browser-Konsole kann jede Zeile aus jeder Tabelle ziehen. Deine gesamte Datenbank ist praktisch öffentlich.

Wie du es erkennst: Gehe zu deinem Supabase-Dashboard → Table Editor. Wenn eine Tabelle „RLS Disabled" anzeigt, hast du dieses Problem. Überprüfe auch, ob dein Client-seitiger Code den service_role-Schlüssel anstelle des anon-Schlüssels verwendet — das ist noch schlimmer.

Die Lösung: Aktiviere RLS für jede Tabelle. Erstelle dann Policies, die den Zugriffsmustern deiner App entsprechen. Die häufigste Policy: Benutzer können nur Zeilen auswählen, einfügen, aktualisieren und löschen, bei denen auth.uid() = user_id gilt. Teste, indem du dich als ein Benutzer anmeldest und versuchst, auf die Daten eines anderen Benutzers über die Supabase REST API zuzugreifen.

Zeit zum Beheben: 30–60 Minuten je nach Tabellenzahl.

Fehler 3: Keine Eingabevalidierung auf Formularen oder API-Routen

Wie es passiert: KI generiert Formulare, die jede Eingabe akzeptieren, und API-Routen, die allen eingehenden Daten vertrauen. Das Formular hat ein „required"-Attribut in HTML, aber keine serverseitige Validierung. Jemand umgeht das Formular vollständig, indem er eine direkte API-Anfrage mit der gewünschten Nutzlast sendet.

Warum es gefährlich ist: Ohne serverseitige Validierung können Angreifer Scripts in deine Datenbank einschleusen (Stored XSS), übergroße Nutzlasten senden, die deinen Server zum Absturz bringen, oder Daten einfügen, die die Logik deiner App unterbricht (wie ein negativer Preis oder ein E-Mail-Feld mit SQL).

Wie du es erkennst: Öffne jede API-Route oder Server-Aktion in deiner Codebasis. Wenn sie req.body oder Formulardaten verwendet, ohne die Form, den Typ und die Länge jedes Feldes zu überprüfen, hast du dieses Problem.

Die Lösung: Füge serverseitige Validierung zu jedem Endpoint mit einer Schema-Validierungsbibliothek hinzu. Zod ist der Standard für TypeScript-Projekte:

import { z } from 'zod';

const taskSchema = z.object({
  title: z.string().min(1).max(200),
  description: z.string().max(2000).optional(),
  priority: z.enum(['low', 'medium', 'high']),
});

// In deiner API-Route:
const parsed = taskSchema.safeParse(req.body);
if (!parsed.success) {
  return Response.json({ error: parsed.error }, { status: 400 });
}

Für alle Felder, die als HTML gerendert werden (Kommentare, Beschreibungen, Bios), bereinige auch die Ausgabe mit DOMPurify, bevor du sie anzeigst.

Zeit zum Beheben: 30–60 Minuten.

Fehler 4: Keine Rate Limiting auf API-Endpoints

Wie es passiert: KI fügt Rate Limiting nie hinzu, außer du fragst danach. Jeder API-Route, den deine App verfügbar macht, kann tausendmal pro Sekunde von jemandem mit einem Script abgerufen werden.

Warum es gefährlich ist: Ohne Rate Limiting kann jemand deinen Login-Endpoint brute-forcen, deine Datenbank scrapen, indem er repeatedly auf List-Endpoints trifft, deinen Server überlasten (Denial of Service), oder dein API-Kontingent verbrauchen, wenn deine Endpoints externe Services wie OpenAI oder Stripe aufrufen.

Wie du es erkennst: Wenn keine deiner API-Routen überprüft, wie viele Anfragen eine einzelne IP oder ein einzelner Nutzer kürzlich gestellt hat, hast du kein Rate Limiting.

Die Lösung: Der einfachste Ansatz für Vercel-gehostete Apps ist ein In-Memory-Rate-Limiter für die Entwicklung und ein Redis-basierter für Production. Vercels Edge Middleware kann grundlegendes Rate Limiting verwalten. Upstash Redis (kostenlos) mit @upstash/ratelimit gibt dir Production-Grade-Rate Limiting mit wenig Code.

Ein angemessener Startpunkt: 60 Anfragen pro Minute für authentifizierte Nutzer, 20 pro Minute für nicht authentifizierte Nutzer, und 5 pro Minute für Login/Signup-Endpoints (um Brute Forcing zu verhindern).

Zeit zum Beheben: 20–45 Minuten.

Fehler 5: Fehlende Auth-Checks auf geschützten Seiten und APIs

Wie es passiert: KI generiert ein wunderschönes Dashboard und API-Routen, die Benutzerdaten zurückgeben, aber fügt keine Middleware hinzu, um zu überprüfen, dass der Benutzer wirklich angemeldet ist. Die Seite „funktioniert", weil du während der Entwicklung immer angemeldet bist. In Production kann jemand die Dashboard-URL direkt öffnen, ohne sich anzumelden, oder den API-Endpoint treffen und Daten zurückbekommen.

Warum es gefährlich ist: Nicht authentifizierter Zugriff auf geschützte Seiten bedeutet, dass jeder Benutzer-Dashboards, Admin-Panels oder private Daten nur durch das Erraten der URL sehen kann. Ungeschützte API-Routes bedeuten, dass jedes Tool wie Postman oder curl Daten ohne Anmeldedaten ziehen kann.

Wie du es erkennst: Öffne ein Inkognito-Browserfenster (nicht angemeldet) und navigiere direkt zu deinem Dashboard, den Settings oder Admin-URLs. Wenn du ohne Umleitung zur Login-Seite Inhalte sehen kannst, hast du dieses Problem. Versuche dann, deine API-Routes direkt zu treffen — wenn sie Daten ohne einen gültigen Session-Cookie oder Auth-Token zurückgeben, sind diese ungeschützt.

Die Lösung: Füge Authentication-Middleware hinzu, die vor jeder geschützten Route ausgeführt wird. In Next.js App Router erstelle eine middleware.ts in deinem Projekt-Root:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const session = request.cookies.get('session');
  if (!session) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*', '/api/protected/:path*'],
};

Passe den Matcher an, um jede Route zu abdecken, die Authentifizierung erfordern sollte. Teste im Inkognito-Modus nach der Implementierung.

Zeit zum Beheben: 15–30 Minuten.

Wie du diese in zukünftigen Projekten verhinderst

Das Muster ist klar: KI generiert funktionierenden Code, überspringt aber Sicherheit, weil du nicht danach fragst. Die Lösung ist, von Anfang an danach zu fragen.

Füge dies am Ende deines initialen Prompts für jedes vibe-codierte Projekt hinzu:

SICHERHEITSANFORDERUNGEN:
- Alle Geheimnisse in Umgebungsvariablen (niemals hartcodiert)
- Supabase RLS auf allen Tabellen mit Per-User-Policies aktiviert
- Serverseitige Eingabevalidierung auf jeder API-Route (nutze Zod)
- Rate Limiting auf allen öffentlichen Endpoints
- Authentication Middleware auf allen geschützten Routen
- Kein Service-Role-Schlüssel in Client-seitigem Code

Das wird nicht alles fangen, aber es eliminiert die fünf häufigsten Sicherheitslücken beim ersten Durchgang, anstatt später eine Bereinigung zu erfordern.

Wenn du besser darin werden möchtest, Prompts zu schreiben, die sicherer Code vom Anfang an produzieren, kann dir unser kostenloser Prompt Optimizer helfen, deine Anweisungen zu strukturieren. Und für einen kompletten Sicherheits-Walkthrough siehe unseren Schritt-für-Schritt-Leitfaden: Wie du eine Vibe-Coded-App vor der Übergabe an Clients absicherst.

Offenlegung: Einige Links in diesem Artikel sind Affiliate-Links. Wir empfehlen nur Tools, die wir persönlich getestet haben und regelmäßig nutzen. Siehe unsere vollständige Offenlegungsrichtlinie.