FixVibe

// docs / security guides / pre-ship checklist

Die Vibe-Coding-Security-Checkliste: 51 Punkte vor dem Deploy

Eine praktische, nach Phasen gegliederte Checkliste für Apps, die mit Cursor, Claude Code, Lovable, Bolt, v0, Replit und Windsurf erstellt wurden. Jeder Punkt ist in weniger als fünf Minuten umsetzbar. Gehen Sie es durch, bevor Sie mit der Produktion beginnen, und dann noch einmal vor jeder Hauptversion. Elemente werden in sieben Kategorien gruppiert – Geheimnisse, Datenbank, Authentifizierung, Header, Drittanbieter, Bereitstellung, Überwachung – und mit der Bereitstellungsphase gekennzeichnet, für die sie gelten.

PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

Geheimnisse und API Schlüssel (8 Artikel)

Hartcodierte Schlüssel sind der häufigste Befund in Vibe-codierten Apps. Acht Dinge, um sie fernzuhalten:

  1. PRE — Audit NEXT_PUBLIC_ env vars. Alles mit dem Präfix NEXT_PUBLIC_ wird in Client-Paketen geliefert. Wenn einer ein Supabase service_role-Schlüssel ist (dekodiert zu JWT mit "role":"service_role"), löschen Sie ihn und leiten Sie ihn über einen Nur-Server-Client (src/lib/supabase/service.ts mit import 'server-only') weiter.
  2. PRE — Grep for hardcoded provider keys. Suchquelle für sk_live_, pk_live_, STRIPE_SECRET, sk-ant-, sk-, AIza, AKIA und JWT-aussehenden Zeichenfolgen (eyJ). Verschieben Sie jeden Treffer in .env.local und referenzieren Sie ihn nur serverseitig über process.env.*.
  3. PRE — Verify .gitignore. Bestätigen Sie .env*.local, .npmrc, .yarnrc und alle anbieterspezifischen Anmeldeinformationsdateien werden ignoriert. Führen Sie git ls-files durch Ihre Providermuster weiter, um alles zu finden, was bereits festgeschrieben wurde.
  4. PRE — Scan the built bundle. Führen Sie npm run build aus, dann grep .next/static und alle dist/-Ausgaben für die gleichen Muster. Wenn ein Schlüssel das Bundle erreicht, hatte der Entwickler nie eine saubere Umgebungstrennung.
  5. DEPLOY — Set secrets per environment. Vercel: Einstellungen → Umgebungsvariablen, jeweils auf ProProduktion / Vorschau / Entwicklung anwendbar. Teilen Sie niemals sk_live_* mit der Vorschauumgebung. Verwenden Sie den verschlüsselten Env-Var-Speicher von Vercel, keine Inline-Workflow-Geheimnisse.
  6. DEPLOY — Disable build-log secret echo. Einige CI Konfigurationen echo Umgebungsvariablen während des Builds. Überprüfen Sie Ihre vercel.json-, GitHub Aktions-Workflows oder Cloudflare Seiteneinstellungen auf alle echo $SECRET, die den Wert in öffentliche Build-Protokolle verschieben würden.
  7. Die Stufe Free von POST — Run a passive scan. FixVibe deckt Folgendes ab: Fügen Sie das bereitgestellte URL ein, warten Sie ca. 20 Sekunden und suchen Sie nach secrets.*-Ergebnissen. Der Secrets in JavaScript Bundles-Check fängt Schlüssel ab, die durch einen Missbrauch von SDK in localStorage oder sessionStorage gelandet sind.
  8. POST — Rotate any key that ever shipped. Wenn ein Schlüssel gerade Minuten lang in einem öffentlichen Paket war, behandeln Sie ihn als kompromittiert. Rotieren Sie Supabase Dienstrollenschlüssel über das Dashboard, generieren Sie Stripe eingeschränkte Schlüssel neu und widerrufen Sie Anthropic-/OpenAI-/Google-Schlüssel über ihre Konsolen.

Datenbankzugriffskontrolle: RLS und Firestore-Regeln (6 Elemente)

Die Standardeinstellungen von BaaS sind absichtlich freizügig, sodass das erste Tutorial funktioniert. Production benötigt explizite Richtlinien.

  1. PRE — Enable RLS on every public.* table. In Supabase: each table needs ALTER TABLE ... ENABLE ROW LEVEL SECURITY plus explicit policies for each role. RLS is what stops the anon and authenticated API roles; FORCE ROW LEVEL SECURITY only extends it to the table owner and is optional defence in depth.
  2. PRE — Write a policy per (table, role, action). Minimum: eine SELECT-Richtlinie, die am auth.uid() beitritt. Besser: separate INSERT / UPDATE / DELETE Richtlinien, damit ein UPDATE keine user_id Änderungen einschleusen kann, die den Besitz umleiten.
  3. PRE — Replace default Firebase rules. Die Standardregeln für den Testmodus lauten allow read, write: if true;. Durch authentisierungsgebundene Regeln pro Sammlung ersetzen: match /users/{userId} durch allow read, write: if request.auth.uid == userId;
  4. PRE — Lint migrations in CI. Führen Sie vor dem Zusammenführen supabase db lint oder ein Äquivalent aus. CI sollte beim Build fehlschlagen, wenn einem CREATE TABLE public.* eine passende RLS-Richtlinie fehlt.
  5. DEPLOY — Confirm RLS survived deploy. Nach der Bereitstellung erneut in Supabase Studio einchecken: Tabellen → jede Zeile → RLS Umschalter ist ON. Production-Datenbankmigrationen eilen gelegentlich den Richtliniendateien voraus; Überprüfen Sie, ob die Richtlinie aktiv ist.
  6. POST — Run an active scan against a verified domain. Die aktive Prüfung Supabase Row-Level Security schreibt mit der Anon-Taste in eine kleine Startzeile und meldet zurück, ob der Schreibvorgang erfolgreich war – i.e. RLS ist nicht wirklich erzwingend.

Authentifizierung und Sitzungen (7 Elemente)

Authentifizierungsfehler in AI--codierten Apps sind in der Regel subtil: ein Fehler bei der Token-Verifizierung, ein fehlendes HttpOnly-Flag, ein getSession(), wo eigentlich ein getUser() stehen sollte.

  1. PRE — Replace getSession() with getUser(). getSession() liest das Cookie und vertraut ihm; getUser() überprüft mit dem Supabase Backend. Verwenden Sie auf Serverrouten immer getUser().
  2. PRE — Confirm token expiry. Magic-Link-, Passwort-Reset- und E-Mail-Verifizierungs-Tokens benötigen einen vom Server erzwungenen Ablauf. Standardmäßige Supabase Magic-Links laufen nach einer Stunde ab – überschreiben Sie diese Zahl nicht ohne triftigen Grund mit einer höheren Zahl.
  3. PRE — Verify JWT aud and exp. Wenn Sie Token irgendwo manuell entschlüsseln, überprüfen Sie beide Ansprüche. Besser: Verwenden Sie SDKs getUser(), das das für Sie erledigt.
  4. PRE — Audit cookie flags. Benutzerdefinierte Sitzungscookies sollten Secure; HttpOnly; SameSite=Lax sein (oder Strict für Nicht-OAuth-Flows). Kein Sitzungsmaterial in localStorage.
  5. PRE — Validate the next redirect param. Der Abfrageparameter next nach der Anmeldung muss mit / und nicht mit // beginnen (offene Weiterleitung zu attacker.example). Alles andere serverseitig ablehnen.
  6. POST — Test logout. Anmelden, abmelden, Cookies überprüfen (DevTools → Anwendung → Cookies). Das Sitzungscookie muss bei derselben Antwort gelöscht werden. Wenn es weiterhin besteht, zerstört der Logout-Handler den serverseitigen Status nicht wirklich.
  7. POST — Active probe. Die Auth Flow Defects- und Account Enumeration-Prüfungen zeigen gebrochene Authentifizierungsgrenzen auf – unterschiedliche Antworten auf „Benutzer existiert“ vs. „falsches Passwort“, fehlendes Ratenlimit bei der Anmeldung, nicht signierte Reset-Tokens.

HTTP Sicherheitsheader und Inhaltssicherheitsrichtlinie (6 Elemente)

Header sind die kostengünstigste Härtung in der gesamten Pipeline und werden von Codegen am häufigsten übersprungen.

  1. PRE — Ship a real CSP. Minimum: script-src 'nonce-{NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. Kein 'unsafe-inline' in script-src. Next.js wendet die Nonce automatisch an, wenn Middleware den x-nonce-Anforderungsheader festlegt.
  2. PRE — Add the legacy three. X-Content-Type-Options: nosniff, X-Frame-Options: DENY (oder verlassen Sie sich allein auf CSP frame-ancestors), Strict-Transport-Security: max-age=31536000; includeSubDomains.
  3. PRE — Tighten Referrer-Policy. Die Standardeinstellung strict-origin-when-cross-origin ist für die meisten Apps in Ordnung. Versenden Sie nicht unsafe-url oder überhaupt keinen Header.
  4. PRE — Replace Access-Control-Allow-Origin: *. Grep dafür. Durch eine explizite Ursprungszulassungsliste ersetzen. Überall dort, wo * neben credentials: include steht, lehnt der Browser die Anfrage ab – aber das ist kein Schutz gegen ein falsch konfiguriertes Backend.
  5. DEPLOY — Verify headers post-deploy. Öffnen Sie DevTools → Netzwerk → klicken Sie auf Ihr Stammdokument → Registerkarte „Kopfzeilen“. CSP, HSTS, X-Frame-Options, X-Content-Type-Options sollten vorhanden sein. CSP darf nicht 'unsafe-inline' in script-src haben.
  6. POST — Run HTTP Security Headers. Die passive Header-Prüfung meldet jeden fehlenden Header mit Anleitung zur Fehlerbehebung auf der Bereitstellungsplattform (Vercel vercel.json, Cloudflare Seiten _headers, Netlify _headers, Next.js Middleware).

Integrationen von Drittanbietern und APIs (5 Elemente)

Jedes von Ihnen eingefügte Skript stellt eine CSP-Ausnahme und eine potenzielle Lieferkettenoberfläche dar. Behandeln Sie Dritte als Teil Ihrer Vertrauensgrenze.

  1. PRE — Reverse-proxy analytics where possible. PostHog, Plausible, Umami unterstützen alle das Proxying über Ihre eigene Domain (e.g. /api/posthog). Dadurch bleibt connect-src auf dem gleichen Ursprung und übersteht Werbeblocker.
  2. PRE — CSP-allowlist the rest. Fügen Sie für Google Analytics, Stripe.js, Sentry, Intercom, GTM usw. die Ursprünge jedes Anbieters zur entsprechenden CSP-Anweisung hinzu (script-src für Loader, connect-src für Telemetrie, frame-src für Iframes, img-src für Pixel).
  3. PRE — Use Stripe Checkout, not raw card forms. Stripe Checkout ist eine Weiterleitung auf oberster Ebene; Für das Skript ist kein CSP-Eintrag erforderlich. Die gehostete Oberfläche von PCI befindet sich vollständig auf der Domain von Stripe. Rollen Sie Ihre eigenen nur, wenn Sie einen triftigen Grund haben.
  4. PRE — Lock package-lock.json in CI. Führen Sie npm ci (nicht npm install) in Produktions-Builds aus. Prüfen Sie Abhängigkeiten mit npm audit oder Snyk vor jeder Veröffentlichung.
  5. POST — Watch Technology Fingerprinting. Die passive Tech-Stack-Erkennung zeigt Bibliotheksversionen an, die für einen Crawler sichtbar sind. Wenn Sie ein EOL React, jQuery oder Bootstrap versenden, markiert FixVibe es und verlinkt auf bekannte CVEs.

Einsatzhygiene und Infrastruktur (8 Artikel)

Wie Sie bereitstellen, ist genauso wichtig wie das, was Sie bereitstellen. AI-codierte Apps profitieren besonders von der expliziten Bereitstellungshärtung.

  1. PRE — Disable x-powered-by. In next.config.js: poweredByHeader: false. Entfernt ein kostenloses Versionsoffenlegungssignal.
  2. PRE — Confirm middleware lives at src/middleware.ts. Beim Verzeichnislayout src/ ignoriert Next.js ein middleware.ts auf Stammebene. Falsch platzierte Middleware schafft es stillschweigend nicht, CSP / Authentifizierungsheader / Ratenlimits festzulegen.
  3. PRE — Sanity-check Vercel deployment protection. ProDie Verabschiedung sollte öffentlich sein; Die Vorschau sollte passwortgeschützt oder auf Organisationsmitglieder beschränkt sein. Vercel-Specific Exposure meldet die Oberfläche.
  4. PRE — Block dotfile and config probes at the edge. Fügen Sie eine Umschreibe- oder Ablehnungsregel für die Muster /.env, /.git/*, /.aws/*, /.next/trace hinzu. Vercel gibt für viele davon standardmäßig 403 zurück; Gegenprüfung.
  5. DEPLOY — Separate environments. ProProduktion, Vorschau, Entwicklung. Jeder hat seine eigenen Geheimnisse. Live-Keys erreichen nie die Vorschau, der Stripe Testmodus erreicht nie die ProReduktion.
  6. DEPLOY — Enable Vercel Web Application Firewall. Pro und Enterprise-Pläne beinhalten WAF mit verwalteten Regeln. Cloudflare Pages verfügt über einen Bot-Kampfmodus. Beides reduziert den Missbrauch automatisierter Scanner und die Belastung durch das Sprühen von Passwörtern.
  7. POST — Verify TLS configuration. SSL Labs oder testssl.sh für Ihre Produktionsdomäne. Mindestens TLS 1.2, vorzugsweise TLS 1.3, keine schwachen Chiffren, HSTS Vorladung möglich.
  8. POST — Confirm health-check endpoints are minimal. Ein /api/health sollte 200 OK ohne Text zurückgeben. Geben Sie kein Umgebungsecho ab, erstellen Sie keinen Hash und stellen Sie keinen Zeitstempel ohne Authentifizierung bereit.

Laufende Überwachung und erneutes Scannen (4 Artikel)

Sicherheit ist kein einmaliges Audit vor dem Versand. Bei jedem Einsatz kommt es zu Drift.

  1. Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT or HTTP file verification. Active scans require Hobby or above, scheduled scans require Pro or Unlimited, and live threat monitoring requires Unlimited.
  2. Schedule passive re-scans on Pro or Unlimited. Choose an available cadence for your verified domain. Scheduled runs share your scan allowance; enable completion notifications and signed webhooks as needed. A scheduled scan observes the app at run time, not continuously.
  3. Wire outbound webhooks. Account → Webhooks → einen HTTPS Endpunkt hinzufügen, scan.completed + finding.created + scan.active_api.first_used abonnieren. In Slack / Discord / PagerDuty weiterleiten.
  4. Enable live threat monitoring on Unlimited. Periodic certificate, DNS, bundle, and threat-intelligence checks can surface changes between scheduled scans. Coverage and alert timing depend on the signal and successful polling.

Replit Agent

If you build with Replit Agent, also check:

  1. Don't paste keys into the Agent prompt. Add them in Secrets and give the Agent the variable name instead, so the value never appears in generated code or chat history.
  2. Test CORS on the production domain. The preview pane and your deployed URL are different origins. Check your CORS allowlist against the domain users actually load.
  3. Replit Agent sometimes hardcodes test values. Der Agent generiert möglicherweise Code mit API_URL = 'http://localhost:5000</code>. Vor dem Versand durch <code>os.environ[API_URL'] ersetzen.

Firebase Studio

If you build with Firebase Studio, also check:

  1. Test-mode rules are temporary by intent, not by default. Test mode lets anyone read and overwrite data. If the generated rule carries a date cutoff, client access stops on that date; if not, the database stays open. Replace test rules before launch either way.
  2. Security rules protect data, not Hosting. Firestore and Storage rules don't govern what Firebase Hosting serves: everything in the public directory is public. Keep exports, backups and admin pages out of it.

Claude Code

If you build with Claude Code, also check:

  1. PRE — Keep personal Claude Code settings out of git. Commit .claude/settings.json for shared project settings, but keep .claude/settings.local.json out of the repo: Claude Code excludes it from git when it creates the file, so check it if you created it by hand. Session history lives in ~/.claude, outside the project (Claude Code docs).
  2. Bash operations are unverified. Claude Code führt Bash-Befehle direkt aus. git commit -m "fix" ist praktisch, aber wenn das Arbeitsverzeichnis eine .env-Datei hat und diese in einem Glob enthalten ist, erfolgt ein Commit. Überprüfen Sie immer git diff --cached, bevor Claude Code ein Commit durchführt.

Nächste Schritte

Möchten Sie wissen, warum diese Dinge wichtig sind? Lesen Sie AI-generated code security scanning. Möchten Sie konkrete Codeausschnitte für jeden Härtungsschritt? Siehe How to secure an app built with AI coding tools.

// deine App scannen

Genug gelesen. Finde die Lücken in deiner App.

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • Free-Tier — 3 Scans / Monat, ohne Karte.
  • Passive Scans gegen jede URL — keine Domain-Verifizierung nötig.
  • Abgestimmt auf Cursor, Claude Code, Lovable, Bolt, v0, Replit.
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
Kostenlosen Scan starten →

keine Anmeldung nötig

Die Vibe-Coding-Security-Checkliste: 51 Punkte vor dem Deploy · FixVibe