Reeve Ist deine Cursor-App sicher?
Ist Cursor sicher für Produktions-Apps? Der Code läuft meist einwandfrei. Läuft und geschützt sind verschiedene Prüfungen, und nur eine wird ausgeführt.
Logos sind Eigentum ihrer jeweiligen Inhaber und dienen nur zur Kennzeichnung der Kompatibilität.
Kurz gesagt
- Eine mit Cursor gebaute App lässt sich meist bedenkenlos ausführen. Ob sie sich bedenkenlos veröffentlichen lässt, ist eine eigene Prüfung, und die führt niemand für dich aus.
- Erzeugter Code beantwortet die Frage, die du gestellt hast. Welche Zeilen ein Besucher sehen darf, ist eine Frage, die in die Datenbank gehört.
- Der übliche Weg, auf dem ein geheimer Schlüssel veröffentlicht wird: ein Refactoring vom Server in den Browser, dann NEXT_PUBLIC_ oder VITE_ ergänzen, damit der Fehler verschwindet.
Cursor gibt dir echte Kontrolle (dein Repository, deine Dateien, dein Deploy) und das verschiebt, wo das Risiko sitzt. Du rätselst nicht, was ein Builder in deinem Namen getan hat. Du siehst schnell sehr viel funktionierenden Code durch und entscheidest, was du genau liest.
Hier ist der Punkt, den Anleitung um Anleitung falsch darstellt: Zu fragen, ob die KI unsicheren Code schreibt, ist die falsche Frage. Erzeugter Code wird geschrieben, um zu erfüllen, wonach du gefragt hast. „Lade die Bestellungen des Nutzers" wird von Code erfüllt, der Bestellungen lädt. In diesem Satz steht nicht, wessen, also entscheidet die Antwort es auch nicht, und der Ort, an den diese Entscheidung gehört, ist nicht die Datei, die du gerade durchsiehst.
Läuft und geschützt sind zwei verschiedene Prüfungen
Nur eine davon läuft von allein.
Stell es dir als Laden vor. Deine App ist die Ladenfront: Jede Seite, die du baust, wird jedem Besucher vollständig ausgehändigt, weil ein Browser nicht darstellen kann, was ihm nicht geschickt wurde. Deine Datenbank ist das Lager, ein eigenes Gebäude im Internet mit eigenem Schloss und eigener Adresse.
Wenn du deine App startest und sie funktioniert, hast du die Ladenfront geprüft: Für dich erscheinen die richtigen Dinge auf den richtigen Bildschirmen. Das Schloss hast du nicht geprüft. Das Lager ist direkt erreichbar, ganz ohne durch deinen Laden zu gehen, und dass deine App korrekt lädt, sagt nichts darüber aus, was sie jemandem zurückgibt, der den Vordereingang auslässt.
Das ist die Prüfung, die in keinem Projekt von allein läuft, ob erzeugt oder von Hand geschrieben. Sie zu überspringen wird leichter, wenn der Code schneller ankommt, als du ihn lesen kannst.
Wo in einem Cursor-Projekt Schlüssel schiefgehen
Fast immer beim Umzug vom Server in den Browser.
Es gibt zwei Sorten Zugangsdaten, und sie sehen fast gleich aus. Ein
öffentlicher Schlüssel benennt dein Projekt und sonst nichts
(sb_publishable_… in neuen Supabase-Projekten, anon in älteren) und ist dafür
gemacht, in einem Browser zu leben. Ein geheimer Schlüssel, sb_secret_…
oder das ältere service_role, ignoriert jede Regel, die du geschrieben hast,
und kann jede Zeile lesen und schreiben, die du hast.
Die Abfolge, die einen davon veröffentlicht, ist gewöhnlich. Code, der auf dem
Server einen geheimen Schlüssel benutzte, wird in eine Komponente umgebaut, die
im Browser läuft. Der Wert kommt als undefined zurück, also wird die Variable
auf das Präfix umbenannt, das das Build-Werkzeug will (NEXT_PUBLIC_ in
Next.js, VITE_ in Vite), und die App läuft. Vites eigene Dokumentation sagt
unverblümt, was dieses Präfix tut: Diese Werte werden beim Bauen in deinen
Quellcode gebündelt.
.gitignore hilft hier nicht. Es regelt, was eingecheckt wird, und deine
Build-Ausgabe entsteht danach. Wenn du sicher sein willst, welcher deiner Schlüssel welcher ist,
es gibt eine Ein-Minuten-Prüfung.
Die Prüfung, die in die Datenbank gehört
Row Level Security, wenn deine Daten in Supabase liegen, ein Schalter pro Tabelle, der Zeile für Zeile entscheidet, wer was lesen darf.
Das ist die Antwort auf das „Lade die Bestellungen"-Problem. Statt jeder Abfrage im Code zu vertrauen, dass sie richtig filtert, weigert sich die Datenbank, Zeilen zurückzugeben, auf die der Besucher keinen Anspruch hat, was auch immer die Abfrage sagte und wer auch immer sie schrieb. Eine Regel, durchgesetzt an der einzigen Stelle, durch die jede Anfrage muss.
Zwei Details entscheiden, ob du sie hast. Supabase aktiviert Row Level Security standardmäßig für Tabellen, die im Table Editor des Dashboards entstehen, und nicht für Tabellen, die per SQL angelegt werden, und genau so legt sie eine Migrationsdatei an. Und die Einstellung schaltet nur die Prüfung ein; wer durchkommt, entscheidet die Policy dahinter, und eine Policy kann trotzdem alle durchlassen.
So prüfst du dein eigenes Cursor-Projekt in etwa zehn Minuten
Durchsuche deine Build-Ausgabe, nicht deinen Quellcode. Baue die App und such
dann in den erzeugten Dateien nach service_role, sb_secret_ und sk_live_.
Was dort auftaucht, ist veröffentlicht. Das ist schneller und ehrlicher als
Quellcode zu lesen, weil es das ist, was Besucher tatsächlich bekommen.
Lies deine Umgebungsdatei auf Präfixe hin. Jede NEXT_PUBLIC_- oder
VITE_-Variable ist von Natur aus öffentlich. Frag dich bei jeder, ob du sie auf
deine Startseite drucken würdest.
Öffne in Supabase Authentication → Policies. Jede Tabelle, die Row Level Security als deaktiviert anzeigt, ist für jeden lesbar, der deine Projektadresse hat, und die steckt in deiner App.
Und dann schau von außen. Unser kostenloser Scan macht den letzten Schritt für dich: Er liest deine Live-Seite als Besucher und gibt dir in etwa 20 Sekunden eine Note, ganz ohne Konto: App scannen.
Was zu tun ist
- Eine App, die läuft, hat eine Prüfung bestanden. Ob die Datenbank einen Fremden abweist, ist eine eigene Prüfung, die niemand für dich ausführt.
- Erzeugter Code beantwortet die Frage, die du gestellt hast. „Welche Zeilen darf diese Person sehen" ist eine Frage, die in die Datenbank gehört.
- Der übliche Weg, auf dem ein geheimer Schlüssel veröffentlicht wird, ist ein Refactoring vom Server in den Browser, gefolgt von einer Präfix-Umbenennung.
.gitignoreschützt dein Repository, nicht deine Build-Ausgabe.- In Supabase starten Tabellen, die per SQL entstehen, ohne Row Level Security, und sie zu aktivieren lässt weiterhin jede Zeile lesbar, bis eine Policy etwas anderes sagt.
Baue dein Projekt und durchsuche die Ausgabe nach service_role und sk_live_,
bevor du sonst etwas tust; es dauert eine Minute und die Antwort ist eindeutig.
Danach ist die Sicherheits-Checkliste in 10 Minuten der kürzeste
Weg durch den Rest.
Was bei einer mit Cursor gebauten App tatsächlich schiefgehen kann
Nichts davon bedeutet, dass du etwas falsch gemacht hast: Es sind die normalen Nebenwirkungen davon, die KI schnell Code schreiben zu lassen. Das ist einen Blick wert:
Ein geheimer Schlüssel, direkt in den Code geschrieben
Wenn die KI einen Dienst anbindet, setzt sie den Schlüssel manchmal direkt in den Code, damit es funktioniert, und wenn dieser Code im Browser läuft, kann ihn jeder lesen. Manche Schlüssel sollen öffentlich sein, und das ist in Ordnung; Reeve liest den geladenen Code deiner App, findet alle Schlüssel und sagt dir, welche sicher sind und welche auf den Server umziehen müssen.
Eine committete .env oder ein offengelegter .git-Ordner
Schlüssel sollen in einer .env-Datei leben, die nie ausgeliefert wird. Aber es ist leicht, versehentlich .env zu committen, oder den versteckten .git-Ordner zu deployen, sodass die ganze Historie, Schlüssel inklusive, herunterladbar wird. Reeve prüft, ob eines von beiden von außen erreichbar ist.
Deine Datenbank offen gelassen (RLS aus)
Wenn deine App Daten speichert (oft in Supabase oder einem anderen Postgres), gibt es eine Regel (Row Level Security) dafür, wer jede Zeile lesen oder ändern darf. Ist sie aus, können deine Tabellen für jeden offen sein, der die Adresse findet. Es ist das häufigste ernste Problem, und es ist unsichtbar, wenn du nicht nachprüfst.
Öffentlicher Dateispeicher
Wenn deine App Uploads annimmt, leben diese in Speicher-„Buckets“. Ein öffentlicher Bucket bedeutet, dass jeder auflisten oder herunterladen kann, was drin ist, sodass eine private Datei für alle sichtbar werden kann. Reeve prüft, ob deine Buckets auflistbar sind; es lädt nie die Dateien von jemandem herunter.
Source Maps eingeschaltet gelassen
Eine „Source Map“ legt den Original-Code deiner App jedem offen, der nachsieht. Nützlich beim Bauen, aber in der Produktion gibt sie Fremden eine lesbare Kopie davon, wie deine App funktioniert, und macht andere Lücken leichter auffindbar. Es lohnt sich, aufzuräumen. Reeve prüft, ob deine offengelegt sind.
Fehlende Sicherheits-Header & offene Endpunkte
Kleine Einstellungen, die Browsern sagen, wie sie deine Besucher schützen sollen, plus ob deine Daten-Endpunkte jedem oder jeder Website antworten. Allein geringfügig; zusammen summieren sie sich. Reeve markiert, was fehlt.
Was Reeve ist, und was nicht
Reeve ist eine kostenlose, nur-lesende Prüfung von außen, wie ein Inspektor, der die Türen probiert, ohne hineinzugehen. Sie ist schnell und fängt die häufigen, folgenreichen Fehler ab. Sie ist kein vollständiges Sicherheitsaudit, und eine saubere Note ist keine Garantie. Sie bedeutet, dass die offensichtlichen Türen zu sind.
Cursor ist ein Editor, kein Hoster, deployt oder bewacht deine App also nicht für dich; mehr davon liegt bei dir und dem Code, den die KI erzeugt hat. Cursors eigene Werkzeuge können helfen, Code beim Schreiben zu prüfen, und wenn du Supabase nutzt, meldet dessen Berater Datenbankprobleme. Was Reeve ergänzt: eine Außensicht auf die App, die du tatsächlich ausgeliefert hast, in verständlichen Worten, mit denen du etwas anfangen kannst. Und wenn du am liebsten nicht daran denken möchtest, können wir sie für dich im Blick behalten.
Willst du es erledigt, nicht nur geprüft?
Reeve Care behält deine App im Blick, sichert deine Daten und hilft dir, Dinge zu reparieren, wenn sie kaputtgehen, damit du weiterbauen kannst, statt dir Sorgen zu machen.
Mehr über Reeve Care erfahrenFAQ
Ist von Cursors KI geschriebener Code sicher?
Es kann guter Code sein, aber „von KI geschrieben“ bedeutet nicht „auf Sicherheit geprüft“. Die KI optimiert darauf, dass Dinge funktionieren, was manchmal einen Schlüssel am falschen Ort oder eine fehlende Datenbankregel bedeutet. Der einzige Weg, es zu wissen, ist zu prüfen, was offengelegt ist. Reeve macht das kostenlos in etwa 20 Sekunden.
Ich glaube, ich habe eine .env-Datei committet. Ist das gefährlich?
Es kann es sein, wenn die Datei (oder der versteckte .git-Ordner) auf deiner deployten Seite erreichbar ist, denn sie kann Live-Schlüssel enthalten. Reeve prüft von außen, ob eines von beiden herunterladbar ist, sodass du weißt, ob du diese Schlüssel rotieren musst.
Woran erkenne ich, ob meine Cursor-App API-Schlüssel leakt?
Die übliche Ursache ist ein Schlüssel, der direkt in Code geschrieben ist, der im Browser läuft. Reeve liest den geladenen Code deiner App, findet alle Schlüssel und sagt dir, welche sicher öffentlich sein können und welche auf den Server umziehen müssen, ohne die echten Werte zu speichern.
Ändert das Scannen meiner App etwas?
Nein. Reeve sieht sich nur an, was von außen ohnehin öffentlich ist. Es loggt sich nie ein, ändert nie etwas und lädt nie deine Dateien herunter. Nur lesend, wie das Prüfen, ob eine Tür abgeschlossen ist, ohne einzutreten.
Schreibt Cursor unsicheren Code?
Das ist die falsche Frage an jede Assistenz, auch an eine menschliche. Erzeugter Code wird geschrieben, um das zu erfüllen, wonach du gefragt hast, und „lass diese Seite die Bestellungen laden" wird von Code erfüllt, der alle Bestellungen lädt. In deiner Anfrage stand nicht, welche, also entscheidet die Antwort das auch nicht. Wie du die Anfrage auch formulierst, die Regel darüber, wer welche Zeilen lesen darf, muss in der Datenbank stehen.
Meine .env-Datei steht in .gitignore. Bin ich damit abgesichert?
Für dein Repository weitgehend ja. Aber .gitignore hat keinerlei Wirkung darauf, was dein Build-Werkzeug veröffentlicht. Eine Variable mit Browser-Präfix (NEXT_PUBLIC_ in Next.js, VITE_ in Vite) wird in das JavaScript kompiliert, das deine Besucher herunterladen, ganz gleich wo sie gespeichert war; und sie bleibt in deiner Versionsgeschichte, wenn die Datei je vor der Regel eingecheckt wurde.
Wie prüfe ich, was meine App tatsächlich preisgibt, statt den Code zu lesen?
Lade deine eigene Seite, öffne die DevTools deines Browsers und sieh dir beim Laden den Tab Netzwerk an. Alles, was dort steht, bekommt ein Besucher. Das so zu lesen dauert ein paar Minuten und sagt dir mehr als der Quellcode, weil es genau die Sicht ist, die ein Außenstehender hat.