FixVibe

// docs / security guides / cursor checklist

Cursor-Security-Checkliste: 28 Punkte vor dem Deploy

Bauen mit Cursor? Die Autovervollständigung, der Composer-Modus und die Agent-Funktionen von Cursor sind außergewöhnlich leistungsstark – und schaffen vorhersehbare Sicherheitslücken. Diese Checkliste zielt auf Cursor-spezifische Muster ab: Inlining von Dienstrollenschlüsseln, vom Composer generierte ganze Dateien ohne Überprüfung, Terminalbefehle im Agentenmodus und die <code>.cursorrules</code>-Datei als Ihre erste Sicherheitsleitplanke. 28 Elemente zu Geheimnissen, Datenbank, Authentifizierung, Headern, Bereitstellung und Cursor-spezifischen Fallstricken.

PRE = Vorbereiten (Prüfen Sie Ihre Quelle). DEPLOY = zum Zeitpunkt der Bereitstellung. POST = Überprüfung nach der Bereitstellung. Artikel verweisen auf FixVibe Prüf-IDs im category.check-id-Format, sofern relevant.

Geheimnisse und API Schlüssel (5 Artikel)

Die automatische Vervollständigung von Cursor wird auf Open-Source-Code trainiert, bei dem Geheimnisse häufig vorkommen. Das Modell schlägt sie frei vor, insbesondere nach einem fehlgeschlagenen Authentifizierungsversuch.

  1. PRE — Write security rules into .cursorrules. Fügen Sie eine Zeile hinzu: „Inline niemals SUPABASE_SERVICE_ROLE_KEY, sk_live_* oder eine beliebige Umgebungsvariable, die mit einem Provider-Akronym beginnt, in clientseitigen Code. Verwenden Sie immer nur serverseitige Importe.“ Cursor liest .cursorrules und berücksichtigt es in jedem Vorschlag.
  2. PRE — Audit Composer-generated files. Wenn der Composer von Cursor eine ganze Datei erstellt (insbesondere Authentifizierungshandler), überprüfen Sie sie Zeile für Zeile. Composer integriert manchmal Umgebungsvariablen, die nur für den Server gelten sollten. Suchen Sie nach NEXT_PUBLIC_ oder direkten Verweisen auf Dienstschlüssel in Komponentenimporten.
  3. PRE — Reject auto-imports of service clients into client components. Wenn Composer import { supabase } from '@/lib/supabase/service' in eine React-Datei importiert, löschen Sie es sofort und leiten Sie es stattdessen über einen API-Endpunkt weiter. Nur-Server-Importe sind explizit markiert – überspringen Sie sie nicht.
  4. PRE — Scan Agent-mode commits. Der Agentenmodus führt Terminalbefehle aus und kann direkt festschreiben. Überprüfen Sie git log --oneline -20 und git diff HEAD~5, um sicherzustellen, dass während einer Agentenausführung keine geheimnisvollen Zeichenfolgen festgeschrieben wurden.
  5. POST — Run secrets.browser-storage. Passiver Scan auf dem bereitgestellten URL. Wenn ein Dienstschlüssel im JS-Bundle erscheint, rotieren Sie ihn sofort – die automatische Vervollständigung von Cursor hat ihn wahrscheinlich eingefügt.

Datenbankzugriffskontrolle (4 Artikel)

Composer generiert häufig funktionierenden Authentifizierungscode, überspringt jedoch RLS – der „Es funktioniert“-Moment macht die Leute blind für die fehlende Richtliniendurchsetzung.

  1. PRE — Force Cursor to generate migrations with RLS. In .cursorrules: „Jede CREATE TABLE public.* Migration muss ALTER TABLE ... ENABLE ROW LEVEL SECURITY und FORCE ROW LEVEL SECURITY enthalten.“ Bitten Sie dann Composer, die Migration zu generieren.
  2. PRE — Review Composer-generated policies. Composer schreibt manchmal Richtlinien, ohne auth.uid() zu überprüfen. Richtlinien wie allow select on public.items ohne eine using-Klausel sind gefährlich weit gefasst. user_id-Abgleich erforderlich.
  3. DEPLOY — Confirm FORCE ROW LEVEL SECURITY is live. Öffnen Sie Supabase Studio und überprüfen Sie den RLS-Schalter jeder Tabelle. Wenn die Composer-Migration ENABLE hatte, aber FORCE vergessen hat, umgehen Tabelleneigentümer (Ihre Migrationen) RLS. Das ist eine echte Lücke.
  4. POST — Run the baas.supabase-rls active check. Es wird versucht, mit der Anon-Taste zu schreiben. Wenn dies gelingt, wird RLS nicht wirklich durchgesetzt – wahrscheinlich fehlt das Schlüsselwort FORCE.

Authentifizierung und Sitzungen (4 Elemente)

Cursor generiert Authentifizierungsflüsse schnell, vermisst jedoch häufig die subtile serverseitige Validierung, die die Sicherheit der Token gewährleistet.

  1. PRE — Ensure all auth routes use getUser(). Suchen Sie in Ihren API Routen nach getSession() und ersetzen Sie es durch await supabase.auth.getUser(). getSession() liest ein ungeprüftes Cookie; getUser() validiert mit Supabase Backend.
  2. PRE — Check Composer auth handlers for token expiry. Magic-Link-Tokens benötigen vom Server erzwungenes expires_at. Der Standardwert für Supabase beträgt 1 Stunde – bitten Sie Cursor nicht, ihn ohne triftigen Grund zu überschreiben.
  3. PRE — Audit the sign-in redirect guard. Die Umleitung des Abfrageparameters next nach der Anmeldung muss validiert werden: Sie muss mit / beginnen, niemals mit //. Der Komponist überspringt dies manchmal. Fügen Sie es manuell hinzu, falls es fehlt.
  4. POST — Test logout server-side state destruction. Anmelden, abmelden, Cookies überprüfen (DevTools → Anwendung → Cookies). Das Sitzungscookie muss sofort gelöscht werden. Wenn es weiterhin besteht, zerstört der Logout-Handler den Status nicht.

HTTP Sicherheitsheader und CSP (3 Elemente)

Cursor generiert standardmäßig selten Middleware. Wenn Sie nicht explizit fragen, sind CSP und HSTS normalerweise nicht vorhanden.

  1. PRE — Demand CSP in .cursorrules. Hinzufügen: „Generieren Sie ein src/middleware.ts mit Content-Security-Policy. Verwenden Sie Nonce für script-src, kein unsafe-inline.“ Bitten Sie dann Cursor, es zu generieren. Ohne diesen Hinweis wird die Middleware übersprungen.
  2. PRE — Verify src/middleware.ts exists. Beim Verzeichnislayout src/ nimmt Next.js nur src/middleware.ts auf. Ein middleware.ts auf Stammebene wird stillschweigend ignoriert. Wenn CSP nicht landet, überprüfen Sie, ob sich die Datei am richtigen Ort befindet.
  3. POST — Run headers.security-headers. Passive Scan-Berichte fehlen CSP, HSTS, X-Frame-Options, X-Content-Type-Options. Öffnen Sie den Bericht und befolgen Sie die Fehlerbehebungsanleitung für Ihre Bereitstellungsplattform.

Einsatzhygiene (5 Artikel)

Cursor-Apps landen oft auf Vercel, was gute Standardeinstellungen hat, aber eine explizite Härtung für die Build/deploy-Grenze erfordert.

  1. DEPLOY — Check Vercel env-var scoping. Einstellungen → Umgebungsvariablen → Jedes Geheimnis sollte nur auf Production beschränkt sein. Teilen Sie sk_live_* niemals mit Vorschau oder Entwicklung.
  2. DEPLOY — Disable build-log secret echo. Wenn Ihr vercel.json- oder GitHub-Aktionsworkflow echo $SECRET hat, entfernen Sie es. Build-Protokolle werden öffentlich archiviert; Geheimnisse in Protokollen sind gefährdet.
  3. DEPLOY — Use Vercel's managed secrets, not inline workflow vars. Vercels Einstellungen → Umgebungsvariablen wird im Ruhezustand verschlüsselt. Die Geheimnisse von GitHub Aktionen sind besser als nichts, aber sie sind für CI konzipiert, nicht für die Integration in die Bereitstellungsplattform.
  4. POST — Verify CSP nonce on the deployed preview. Öffnen Sie einen Vercel Vorschau-Link im Browser, öffnen Sie DevTools → Netzwerk → die Stammantwort HTML. Der CSP-Header muss vorhanden sein und 'strict-dynamic' mit einer eindeutigen Nonce pro Anfrage enthalten.
  5. POST — Rotate any key that ever shipped, even to Preview. Wenn ein Schlüssel das Produktionspaket auch nur 10 Minuten lang erreicht, ist er kompromittiert. Sofort drehen.

Cursor-spezifische Fallstricke (4 Elemente)

Für den Workflow von Cursor einzigartige Muster, die Sicherheitsrisiken schaffen:

  1. Agent mode auto-fixes propagate old patterns. Wenn Sie den Agenten bitten, „Authentifizierungsfehler zu beheben“, wird möglicherweise dieselbe Authentifizierungsdatei mehrmals neu generiert, wobei jedes Mal derselbe Dienstschlüssel eingefügt wird, wenn er sich im Codebasiskontext befindet. Reinigen Sie zuerst das Original und bitten Sie dann den Agenten, das Problem zu beheben.
  2. Die @codebase-Indizierung von Cursor Index leaks intent. Cursor ist leistungsstark, aber wenn Ihr .cursor-Verzeichnis jemals offengelegt wird (falsch konfiguriertes S3, Git-Verlauf), enthüllt der Index Ihre Architektur und geheime Muster. Halten Sie .cursor lokal.
  3. Composer mode loses context between files. Jede von Composer generierte Datei ist frisch. Wenn Sie es auffordern, eine Client-Datei und dann eine API-Route zu generieren, verwenden sie möglicherweise unterschiedliche Supabase Client-Konfigurationen. Überprüfen Sie beide und stellen Sie sicher, dass sie zu Ihrer Architektur passen.
  4. Autocomplete bias toward "working" over "secure". Cursor schlägt den schnellsten Code vor, der Ihren aktuellen Kontext durchläuft. Wenn Ihr Test NEXT_PUBLIC_SERVICE_KEY hat, merkt sich die automatische Vervollständigung dies und schlägt es erneut vor. Reinigen Sie Testvorrichtungen, bevor Sie Code mit dem Modell teilen.

Nächste Schritte

Sobald Sie die Cursor-spezifischen Muster festgelegt haben, vergleichen Sie sie mit general vibe coding security checklist (44 Elemente) und dann mit step-by-step hardening. Sehen Sie sich auch Claude Code checklist an, wenn Sie Werkzeuge mischen.

// deine App scannen

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

Eine URL einfügen — FixVibe führt jeden passiven Check aus diesem Guide plus 200 weitere in unter einer Minute aus. Kostenlos, ohne Installation, ohne Karte.

  • 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

Cursor-Security-Checkliste: 28 Punkte vor dem Deploy — Docs · FixVibe