Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Ein Nicht-Entwickler aus dem Team baut mit Vibe-Coding-Tools wie v0 oder Cursor innerhalb von drei Tagen eine beeindruckende Web-App. Der Chef ist begeistert und möchte sie sofort an die Produktions-DB anbinden und für Kunden freigeben. In diesem Moment bricht den Entwicklern oder dem CTO der kalte Schweiß aus. Wirft man einen Blick in den vom KI-Tool generierten Code, findet man mitten in einer Client-Komponente den Datenbank-Connection-String (DSN) im Klartext oder sieht, wie SQL-Queries völlig ohne Validierung abgefeuert werden.
Bringt man das so auf den Produktionsserver, ist ein Vorfall nur eine Frage der Zeit. Auch der OWASP Top 10 for LLM Applications 2025 Report hebt die übermäßige Rechtevergabe bei KI-generiertem Code (LLM06) sowie die fehlende Eingabevalidierung (LLM05) als die gefährlichsten Sicherheitsrisiken hervor. In der Praxis zielen tatsächlich 73 % aller Sicherheitsverletzungen bei Webanwendungen auf eine fehlende Eingabevalidierung ab.
Um die Produktivität von Nicht-Entwicklern nicht einzuschränken und gleichzeitig die Unternehmens-DB zu schützen, muss eine solide Kontrollschicht zwischen Prototyp und Datenbank eingezogen werden.
Der erste Schritt besteht darin, dem von Nicht-Entwicklern erstellten App-Code den direkten Zugriff auf die DB zu versperren. Ein Server Route Handler in Next.js App Router dient als Proxy, der die eingehenden Daten auf halbem Weg in Echtzeit über die Zod-Bibliothek überprüft. Die Typprüfung von TypeScript funktioniert nur während der Entwicklung – sie schützt nicht davor, dass der Server abstürzt, wenn ein echter Benutzer fehlerhafte Daten sendet.
| Prüfpunkt | Browser-UI-Validierung | Serverseitige Zod-Proxy-Schicht |
|---|---|---|
| Ausführungsort | Kunden-Browser | Vercel Serverless Runtime |
| Sicherheit | Über Entwicklertools leicht zu umgehen | Erzwungener Block auf Serversebene zum Schutz der DB |
| Datenvalidierung | Formeller Text-Check | Präzise Prüfung von Wertebereichen und Typen zur Laufzeit |
| Fehlerbehandlung | Warnmeldung auf dem Bildschirm anzeigen | HTTP 400 zurückgeben und Fehler in Sentry protokollieren |
Der Aufbau ist einfach:
app/api/v1/customer-records/route.ts im Projekt.companyName muss mindestens 2 Zeichen lang sein, contactEmail muss ein gültiges E-Mail-Format haben und employeeCount akzeptiert nur positive ganze Zahlen.request.json() mit schema.parse(). Nur geprüfte Nutzdaten werden über das Prisma ORM in die Datenbank eingefügt. Schlägt die Prüfung fehl, wird sofort ein 400-Fehler zurückgegeben und die Anfrage abgelehnt.Zusätzlich zur Validierung auf App-Ebene muss auch die Datenbank selbst geschützt werden. Wer Supabase auf PostgreSQL-Basis nutzt, findet die Antwort in Row Level Security (RLS). Speichern Sie Benutzerrollen nicht in raw_user_meta_data, da diese vom Nutzer manipuliert werden können, sondern in raw_app_meta_data, die nur von Administratoren geändert werden können, und verifizieren Sie das JWT.
`sql
-- 1. RLS für die Tabelle aktivieren
ALTER TABLE public.enterprise_documents ENABLE ROW LEVEL SECURITY;
-- 2. Funktion zur Extraktion der Benutzerrolle aus dem JWT erstellen
CREATE OR REPLACE FUNCTION get_user_role()
RETURNS text AS
LANGUAGE sql STABLE;
-- 3. Richtlinie definieren: Abfrage nur erlauben, wenn die Abteilung übereinstimmt oder der Benutzer Admin ist
CREATE POLICY "Department Access Policy" ON public.enterprise_documents
FOR SELECT USING (
get_user_role() = 'admin' OR
department = (current_setting('request.jwt.claims', true)::json->'app_metadata'->>'department')
);
`
Wenn diese Vorkehrung getroffen ist, führt selbst ein versehentliches Veröffentlichen des Service Role Keys durch einen Nicht-Entwickler nicht dazu, dass Sicherheitsdokumente anderer Abteilungen kompromittiert werden.
KI-Tools sind darauf ausgelegt, möglichst schnell ein Ergebnis auf dem Bildschirm anzuzeigen. Deshalb platzieren sie API-Schlüssel oder DB-Connection-Strings oft an Stellen, die im Browser einsehbar sind. Der häufigste Fehler ist das wahllose Hinzufügen des Präfix NEXT_PUBLIC_. In Next.js werden Variablen mit diesem Präfix im Klartext in die JavaScript-Dateien des Browsers eingebunden. Sobald eine Variable wie NEXT_PUBLIC_OPENAI_API_KEY erstellt wird, kann jeder, der die Entwicklertools (F12) öffnen kann, den API-Schlüssel entwenden und nach Belieben nutzen.
Das zeigt auch der Sicherheitsvorfall in der Vercel-Infrastruktur im April 2026. Durch eine Sicherheitslücke bei den Berechtigungen eines angebundenen Drittanbieter-KI-Tools wurden ungeschützte Umgebungsvariablen offengelegt. Zahlreiche Teams mussten die Nacht durcharbeiten, um Datenbankpasswörter und API-Schlüssel einzeln neu zu generieren.
Solche Fehler manuell durch menschliche Code-Reviews abzufangen, ist unmöglich. Man sollte das statische Analysetool Gitleaks in GitHub Actions einbinden, um solche Sicherheitslücken vor dem Mergen des Codes automatisch aufzuspüren.
`yaml
name: Security Scan
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
gitleaks-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install and Run Gitleaks
run: |
wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.0/gitleaks_8.18.0_linux_x64.tar.gz
tar -xzvf gitleaks_8.18.0_linux_x64.tar.gz
sudo mv gitleaks /usr/local/bin/
gitleaks detect --source=. --verbose --redact --exit-code=1
public-env-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check Unsafe Public Keys
run: |
UNSAFE=(grep -rn "NEXT_PUBLIC_.*\(SECRET\|KEY\|PASSWORD\|TOKEN\|DSN\)" . || true)
if [ -n "UNSAFE" ]; then
echo "Sensible Variablen im Client-Code gefunden:"
echo "$UNSAFE"
exit 1
fi
`
Ist diese Pipeline eingerichtet, wird das Deployment automatisch blockiert, sobald ein Nicht-Entwickler einen API-Schlüssel direkt in den Quellcode oder in eine NEXT_PUBLIC_-Variable einfügt und pusht.
Auch beim Registrieren von Variablen im Vercel-Dashboard müssen die Scopes für Development, Preview und Production klar getrennt werden. Aktivieren Sie unbedingt das Kontrollkästchen für Sensitive Environment Variables. Dadurch wird verhindert, dass die Werte in den Build-Logs ausgegeben werden oder im Dashboard als Klartext kopiert werden können.
Fallen die Server von OpenAI oder Anthropic aus oder reagieren nur verzögert, geraten die gesamten Serverless-Handler in einen Wartezustand, was zu Kaskadenausfällen führt. In solchen Fällen sollte ein Circuit Breaker mit der Node.js-Bibliothek opossum eingerichtet werden.
`typescript
import CircuitBreaker from 'opossum';
async function callLLM(prompt: string) {
// LLM API Call-Logik
}
const options = {
timeout: 5000, // Als Fehlversuch werten, wenn es länger als 5 Sekunden dauert
errorThresholdPercentage: 50, // Circuit Breaker öffnen, wenn die Fehlerrate 50 % übersteigt
resetTimeout: 30000 // Nach 30 Sekunden erneut versuchen
};
const breaker = new CircuitBreaker(callLLM, options);
breaker.fallback(() => ({ error: "Die AI-Antwort verzögert sich. Bitte versuchen Sie es in Kürze erneut." }));
`
Verzögert sich die API-Antwort, wird innerhalb von 0,1 Sekunden eine vorbereitete Hinweismeldung gesendet, wodurch der Ausfall des gesamten Dienstes verhindert wird.
Um den Ersteller des Prototyps bei Störungen sofort zu benachrichtigen, werden Sentry und Slack-Webhooks miteinander verknüpft.
`typescript
// app/api/webhooks/sentry-to-slack/route.ts
import { NextResponse } from 'next/server';
export async function POST(request: Request) {
try {
const event = await request.json();
const webhookUrl = process.env.SLACK_INCOMING_WEBHOOK_URL;
if (!webhookUrl) return NextResponse.json({ error: 'Kein Webhook vorhanden' }, { status: 500 });
const title = event.data?.issue?.title || 'Unbekannter Systemfehler';
const issueUrl = event.data?.issue?.permalink || '#';
await fetch(webhookUrl, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
blocks: [
{
type: 'header',
text: { type: 'plain_text', text: '🚨 Produktionsfehler aufgetreten' }
},
{
type: 'section',
text: { type: 'mrkdwn', text: `*Fehlerdetails:*
${title}` }
},
{
type: 'actions',
elements: [
{
type: 'button',
text: { type: 'plain_text', text: 'Sentry-Bericht anzeigen' },
url: issueUrl,
style: 'danger'
}
]
}
]
})
});
return NextResponse.json({ success: true });
} catch (err) {
return NextResponse.json({ error: 'Webhook fehlgeschlagen' }, { status: 500 });
}
}
`
Weitet sich ein Fehler aus und führt zu einer P1-Störung, bei der die Hauptseite nicht mehr lädt, muss man nicht einmal auf einen Entwickler warten. Vercel bewahrt frühere Deployments auf, sodass mit wenigen Klicks der vorherige Zustand wiederhergestellt werden kann.
Nach nur 30 Sekunden verweist das Domain-Routing wieder auf die vorherige Version. Mit Zod-Validierung, Gitleaks-Scans und dem Vercel-Rollback-Prozess können Sie Nicht-Entwickler nach Herzenslust Apps bauen lassen und nachts trotzdem beruhigt schlafen.