Cursor
Mit Cursor gebaut: was Sie am Code prüfen sollten
Cursor ist ein Code-Editor mit eingebauter KI. Anders als Lovable oder Bolt arbeitet er in Ihrem eigenen Projekt, mit jeder Sprache und jedem Framework. Damit verschieben sich die Risiken: weniger vorgegebene Struktur, mehr Verantwortung bei Ihnen.
Was bei Cursor anders ist
Bei Lovable und Bolt ist der Aufbau der Anwendung weitgehend vorgegeben. In Cursor entscheiden Sie oder die KI über Sprache, Framework, Datenbank und Hosting. Der Agent kann Dateien anlegen, Pakete installieren und Befehle im Terminal ausführen. Das ist mächtig, und jede dieser Fähigkeiten hat eine eigene Fehlerquelle.
1. Zugangsdaten im Projekt
Ihre .env-Datei liegt im Projektordner, und die KI kann sie lesen. Prüfen Sie, ob sie in der .gitignore steht, damit sie nicht im Repository landet. Mit einer .cursorignore schliessen Sie Dateien aus dem Kontext der KI aus. Prüfen Sie ausserdem, ob die KI Schlüssel zur Vereinfachung direkt in den Code geschrieben hat, etwa in eine Testdatei. Mehr im Artikel API-Schlüssel im Frontend.
2. Abhängigkeiten, die die KI vorschlägt
Der Agent installiert Pakete, wenn er sie braucht. Dabei kommen veraltete Versionen vor und gelegentlich Paketnamen, die es nicht gibt oder die einem bekannten Paket nur ähneln. Angreifer registrieren solche Namen gezielt. Prüfen Sie jedes neue Paket: Gibt es es wirklich, wird es gepflegt, wie viele Projekte nutzen es? Und lassen Sie regelmässig eine Prüfung auf bekannte Lücken laufen, etwa npm audit oder pip-audit.
3. Befehle, die der Agent ausführt
Cursor kann Terminalbefehle selbst ausführen, je nach Einstellung nach Rückfrage oder ohne. Ein Befehl gegen die falsche Datenbank, ein Löschbefehl im falschen Ordner, eine Migration in der Produktion: Das passiert selten, aber es passiert. Lassen Sie Befehle nur nach Bestätigung ausführen und geben Sie dem Projekt keine Zugangsdaten zur Produktionsdatenbank.
4. Sicherheit, die der Rahmen nicht mitbringt
Wo kein Baukasten Anmeldung, Rechte und Eingabeprüfung vorgibt, baut die KI sie nach Bedarf. Ob eine API-Route prüft, wer sie aufruft, ob Eingaben vor der Datenbankabfrage maskiert werden, ob Fehlermeldungen interne Details verraten: Das müssen Sie im Code nachsehen. Die typischen Stellen stehen im Überblick über die häufigsten Sicherheitslücken.
5. Tests und Struktur
Cursor schreibt Tests, wenn Sie danach fragen, und hält sich an Regeln, die Sie im Projekt hinterlegen. Nutzen Sie das: Legen Sie fest, wie Code gegliedert wird, dass Rechte immer auf dem Server geprüft werden und dass jede neue Funktion einen Test bekommt. Mehr im Artikel Vibe-Coding und Wartbarkeit.
Bevor Sie damit live gehen
Ihre Lösung läuft. Diese Punkte sollten Sie prüfen, bevor echte Daten daran hängen:
- Steht die .env-Datei in der .gitignore, und liegt kein Schlüssel im Code?
- Haben Sie jedes Paket geprüft, das der Agent installiert hat?
- Prüft jede API-Route auf dem Server, wer sie aufruft?
Sie wollen sicher sein? Das Vibe-Code-Review prüft genau diese Grundlagen. Mehr zum Review →
Lieber selbst anfangen? Die kostenlose Schnellprüfung aus dem Vibecode-Testing-Kit zeigt Ihnen, wo Sie stehen. Zur Schnellprüfung →
Sie haben schon gebaut? Lassen Sie es prüfen.
Beschreiben Sie Ihr Produkt in ein paar Sätzen. Ich melde mich persönlich.