Ist Cursor AI sicher? Editor, Code und die App, die du veröffentlichst

Du hast etwas in Cursor gebaut, es funktioniert, und du willst echte Menschen darauf lassen. Irgendwann in dieser Woche hast du „ist cursor ai sicher“ in ein Suchfeld getippt, und zurück kamen eine Seite über Cursors Datenschutzeinstellungen, eine Seite darüber, ob KI-geschriebener Code etwas taugt, und eine Seite über einen Download für individuelle Mauszeiger. Keine davon hat ein Wort über die App verloren, die du gleich veröffentlichst.

Hier ist der Teil, den die meisten dieser Antworten falsch machen: „Ist Cursor AI sicher?“ sind drei Fragen in einem Satz, und sie haben drei verschiedene Antworten. Zwei davon handeln von Cursor und den Modellen dahinter. Die dritte handelt von dem, was du veröffentlicht hast, und sie ist die, die entscheidet, ob ein Fremder die Daten deiner Nutzer lesen kann.

Stell dir Cursor als Bauunternehmer vor, den du für ein Haus engagiert hast. Ob er eine Kopie deiner Pläne behält, ist die eine Frage. Ob das, was er baut, den Bauvorschriften entspricht, ist die zweite. Ob die Türen abschließen, wenn du eingezogen bist, ist die dritte, und sie bleibt deine Frage, solange du dort wohnst.

Ist Cursor AI sicher?

Als Editor ist es ein gewöhnliches Cloud-Werkzeug: ein Datenschutzschalter, eine veröffentlichte Sicherheitsseite und ein SOC-2-Typ-II-Testat. Das beantwortet eine der drei Fragen, und nicht die, die entscheidet, ob Fremde die Daten deiner Nutzer lesen können.

1. Der Editor. Behält Cursor deinen Code, trainiert damit oder gibt ihn an jemand anderen weiter. Das ist die Kopie der Pläne beim Bauunternehmer.
2. Der Code. Ist das, was die KI schreibt, sicher. Das ist die Frage, ob das Haus den Bauvorschriften entspricht, und niemand prüft das beim Einzug.
3. Die App, die du veröffentlicht hast. Was ein Fremder von der Straße aus erreicht: ein Schlüssel im Code, den ein Browser herunterlädt, eine Datenbank, die ohne Anmeldung antwortet, eine Datei, die nie eine URL hätte haben dürfen. Das sind die Türen.

Nichts auf Cursors Seite kann die dritte beantworten. Nichts auf unserer Seite kann die ersten beiden beantworten.

Behält Cursor meinen Code?

So lange, wie es dauert, dir zu antworten, ja. Danach hängt es von einem Schalter ab.

Cursor ist ein Cloud-Werkzeug. Wenn du es etwas fragst, verlassen die relevanten Teile deines Projekts deinen Rechner, gehen auf Cursors Server und werden zur Beantwortung an einen Modellanbieter weitergereicht (OpenAI, Anthropic, Google, je nachdem, welches Modell du gewählt hast). So funktioniert das Produkt. Die Pläne müssen den Bauunternehmer erreichen.

Was danach passiert, ist der Schalter, und Cursors Seite zur Datennutzung stellt beide Positionen in einem Absatz dar. Mit eingeschaltetem Privacy Mode werden „Kundendaten nicht von Cursor zum Training verwendet“ und Cursor „unterhält mit allen Anbietern Vereinbarungen ohne Datenspeicherung (Zero Data Retention)“, was heißt, dass auch die Unternehmen hinter den Modellen zusagen, nichts zu behalten. Mit ausgeschaltetem Schalter darf Cursor „Codebase-Daten, Prompts, Editor-Aktionen, Code-Ausschnitte und andere Code-Daten und -Aktionen verwenden und speichern, um unsere KI-Funktionen zu verbessern und unsere Modelle zu trainieren“.

Der Schalter ist in jedem Tarif verfügbar, auch im kostenlosen, und ein Team- oder Enterprise-Admin kann ihn für alle einschalten und verhindern, dass Mitglieder ihn ausschalten. Cursors eigener Härtungsleitfaden sagt, dass er bei Enterprise-Konten standardmäßig an ist. In einem Einzeltarif ist er eine Einstellung, und diese Einstellung lohnt sich heute zu suchen.

Noch etwas dazu, denn es hat schon jemanden erwischt. Seit Mitte 2025 gibt es zwei Versionen: „Privacy Mode“, der Cursor erlaubt, für Funktionen wie seine Cloud-Agenten und Memories einige Daten zu speichern, und „Privacy Mode (Legacy)“, der nichts speichert. Im Juli 2026 hat ein Nutzer auf Hacker News beschrieben, wie er sich in der iOS-App angemeldet hat und sein Konto danach von der Legacy-Einstellung auf die aktuelle umgestellt war. Ein Mitarbeiter von Cursor antwortete, dass die Aufforderung, Cloud-Agenten einzuschalten, das ausgelöst habe, „ohne klarzumachen, was das bedeutet oder dass es schwer rückgängig zu machen ist“, und dass ein Zurückwechseln in der App nicht verfügbar sei. Wenn du die strengere gewählt hast, prüfe, ob sie noch ausgewählt ist.

Die Zertifikate beantworten eine engere Frage, als sie aussehen. Cursors Sicherheitsseite führt ein SOC-2-Typ-II-Testat, ISO/IEC 27001 und ISO/IEC 42001 auf. Sie bedeuten, dass ein externer Prüfer bestätigt hat, dass Cursor Kontrollen für den Umgang mit den Daten hat, die es hält, so wie die Versicherungsbescheinigung eines Bauunternehmers sagt, dass der Bauunternehmer versichert ist. Sie sagen nichts über den Code, den er schreibt, und nichts über die App, die du damit veröffentlichst.

Was lädt die Codebase-Indexierung hoch?

Einen Index deines Projekts, der auf Cursors Servern liegt, mit verschlüsselten Dateipfaden und einem Code, der nie als lesbarer Text gespeichert wird.

Die Indexierung ist der Weg, auf dem Cursor eine Frage zu deinem ganzen Projekt beantwortet und nicht nur zur Datei, die du offen hast. Es zerlegt deine Dateien in Stücke, schickt sie auf Cursors Server, wo daraus Embeddings werden (eine numerische Zusammenfassung dessen, worum es in jedem Stück geht), und behält diese Embeddings, damit es die richtigen Stücke findet, wenn du fragst „wo behandeln wir Rückerstattungen“. Cursors Dokumentation sagt: „Dateipfade werden verschlüsselt, bevor sie an Cursors Server gesendet werden. Code-Inhalte werden nie im Klartext gespeichert.“ Was auf seiner Seite bleibt, ist eine Karte deines Codes, und das ist etwas anderes als eine Kopie davon.

Zwei Dinge lohnt es sich über die Karte zu wissen.

Einige Dateien werden standardmäßig ausgelassen, und du kannst weitere hinzufügen. Cursor überspringt alles in deiner .gitignore sowie eine Standardliste, die .env* enthält, die Datei, in der deine geheimen Schlüssel meist liegen. Eine .cursorignore-Datei im Projektstamm, in derselben Syntax wie .gitignore geschrieben, hält alles andere, was du nennst, aus dem Index und aus dem heraus, was die KI zu sehen bekommt.

Das Terminal des Agenten liest diese Liste nicht. Das ist der Haken, der bei Schlüsseln zählt. Cursors Seite zu Ignore-Dateien sagt, dass „die Terminal- und MCP-Server-Werkzeuge, die der Agent verwendet, den Zugriff auf Code, der unter .cursorignore fällt, nicht blockieren können“, und dass „vollständiger Schutz wegen der Unvorhersehbarkeit von LLMs nicht garantiert ist“. Wenn der Agent auf deinem Rechner einen Befehl ausführt, kann er .env lesen, wie jeder Befehl es kann. Die Datei ist aus dem Index heraus und trotzdem in Reichweite. Liegt ein Schlüssel in dem Projektordner, den du in Cursor geöffnet hast, behandle ihn als Schlüssel, den der Agent sehen kann.

Ist der Code sicher, den Cursor schreibt?

Standardmäßig nicht, und das ist gemessen, wobei die Messung die Modelle betrifft, die Cursor verwendet, und nicht Cursor selbst.

Veracode, ein Unternehmen, das Code-Sicherheitstests verkauft, hat über 150 Modelle durch dieselben 80 Programmieraufgaben in vier Sprachen geschickt, wobei jede Aufgabe einen sicheren und einen unsicheren Weg anbietet, sie zu lösen. Sein Frühjahrsupdate 2026, veröffentlicht am 24. März 2026, ergab, dass nur 55 % der Ergebnisse sicher waren, ein Wert, den Veracode „praktisch identisch mit dem Stand vor zwei Jahren“ nennt, während der Anteil, der kompilierte, über 95 % lag. Bei zwei der vier Fehlerarten haben die Modelle fast nie die sichere Variante gewählt: Cross-Site-Scripting, bei dem der Text eines Besuchers im Browser eines anderen Besuchers als Code ausgeführt wird, bestanden sie in 15 % der Fälle, und Log Injection in 13 %.

Veracodes eigene Zusammenfassung lautet, dass die Modelle „hervorragend darin geworden sind, Code zu schreiben, der kompiliert. Daran, Code zu schreiben, der sicher ist, sind sie gescheitert.“

Für dich, die Person, die den Code nicht geschrieben hat, ist die Lücke zwischen diesen beiden Zahlen der ganze Befund. Der Test, den du bei einem Cursor-Projekt ausführst, ist, ob es funktioniert: Du klickst dich durch die App, und die richtigen Dinge erscheinen. Das sind die 95 %. Der Test, den niemand ausführt, ist, ob der Code entschieden hat, wer was sehen darf, und die 55 % sagen, dass diese Entscheidung etwa in der Hälfte der Fälle getroffen wurde. Eine App kann den ersten Test vollständig bestehen und beim zweiten durchfallen, denn eine Seite, die dir deine Bestellungen zeigt, und eine Seite, die jedem die Bestellungen aller zeigt, sehen für die Person, der das Konto gehört, identisch aus.

Wohin diese Entscheidung gehört und warum „lade die Bestellungen“ sie nie von allein trifft, steht in der Mitte des Cursor-Leitfadens.

Prompt Injection, einfach erklärt

Das Modell behandelt Anweisungen als Anweisungen, wo immer es sie findet, auch in Dingen, die es nur lesen sollte.

Du sagst Cursor „fass diesen Thread zusammen“ oder „räum diese Datei auf“, und dafür liest es den Thread oder die Datei. Enthält der Thread einen Satz, der so geschrieben ist, dass er wie eine Anweisung an eine KI aussieht, folgt das Modell ihm womöglich, denn es hat keine zuverlässige Möglichkeit, deine Stimme von der der Seite zu unterscheiden. Das ist Prompt Injection, und bei einem Coding-Agenten, der Dateien bearbeiten und Befehle auf deinem Rechner ausführen kann, gehen die Folgen über eine schlechte Zusammenfassung hinaus.

Zwei benannte Fälle, beide gegen Cursor. Im März 2025 hat Pillar Security „Rules File Backdoor“ veröffentlicht: Anweisungen, mit unsichtbaren Unicode-Zeichen in einer .cursor/rules-Datei versteckt, der Konfigurationsdatei, die Cursor sagt, wie du deinen Code geschrieben haben willst. Die Datei sah im Editor und in einem GitHub-Diff sauber aus und wies die KI im Stillen an, jeder erzeugten Seite ein Skript von der Domain eines Angreifers hinzuzufügen und das nie zu erwähnen. Cursors Antwort war, dass dies keine Schwachstelle seiner Plattform sei und die Verantwortung beim Nutzer liege. Im August 2025 hat Aim Security CVE-2025-54135 offengelegt, von ihnen CurXecute genannt: Eine Nachricht in einem öffentlichen Slack-Kanal, die Cursor über einen MCP-Server las (ein Plug-in, mit dem der Agent externe Werkzeuge erreicht), konnte den Agenten dazu bringen, einen Eintrag in seine eigene mcp.json-Konfiguration zu schreiben, und Cursor hat diesen Eintrag gestartet und den Befehl des Angreifers ausgeführt, bevor du die Änderung genehmigt hattest. Cursor hat das am 29. Juli 2025 in Version 1.3 behoben, und jede Änderung an dieser Datei wartet jetzt auf deine Genehmigung.

Was für dich daraus folgt, ist kurz. Eine Rules-Datei, die du aus einem Repository oder einem Blogbeitrag kopiert hast, ist Code, und sie steuert alles, was der Agent danach schreibt, also lies sie wie Code. Halte Cursor aktuell, denn die Behebung von CurXecute war eine Versionsnummer. Und jeder MCP-Server, den du anschließt und der Text von außen liest, ein Posteingang, eine Ticket-Warteschlange, eine Suche, reicht dem Agenten Sätze weiter, die du nicht geschrieben hast.

Was ein Scan von 30.998 laufenden Apps über die dritte Frage sagt

Dass nichts vom Editor die App erreicht, die du veröffentlicht hast. Wir können eine Cursor-App von außen nicht von einer anderen unterscheiden, und das ist der Befund.

Zwischen dem 12. und 14. August 2026 haben wir die neun externen Checks, die jeder kostenlos auf unserer Startseite laufen lassen kann, über 30.998 laufende Apps geschickt. Gefunden haben wir sie über den Ort ihrer Veröffentlichung: 18.554 auf der Domain von Lovable, 5.438 auf der von Base44, 3.042 auf der von Replit und so weiter. Ein Cursor-Projekt wird dort deployt, wo du es hinstellst, auf Vercel, auf Netlify, auf einer Domain, die du gekauft hast, und die Seite, die ein Besucher herunterlädt, trägt keine Spur des Editors, der sie geschrieben hat. Es gibt also keine Cursor-Spalte im Bericht, und es kann keine geben.

Was es gibt, bei jedem Builder, den wir gemessen haben, ist dieselbe kurze Liste von Dingen, die ein Besitzer offen gelassen hat, und keines davon entscheidet der Editor. Jeder Anteil unten bezieht sich auf die Apps, bei denen der jeweilige Check geantwortet hat, denn ein Check, der nicht fertig wurde, ist unbekannt und nicht bestanden. Keine App wird hier oder irgendwo sonst von uns genannt.

Die erste Zeile ist über die 3.680 Apps gemessen, die ein Supabase-Projekt genannt haben und deren Datenbank die Frage beantwortet hat, weshalb ihr Nenner kleiner ist; was dieser Check liest und was nicht hat die ganze Leiter. Die fünfte Zeile ist die, die ganz allein Geld kostet: ein geheimer Schlüssel von OpenAI, Anthropic, AWS oder Stripe oder ein service_role-Schlüssel von Supabase im Code, den ein Browser herunterlädt.

Die letzte Spalte ist das, was sich bei Cursor ändert. Auf der eigenen Domain eines Builders gehören zwei dieser Zeilen dem Host: Die Header schickt, was die Seite ausliefert, und Source-Maps folgen den Build-Einstellungen des Builders. Ein Cursor-Projekt ist dein Repository, dein Build und dein Deploy, also gehört jede Zeile in dieser Tabelle dir, auch die zwei, über die ein Lovable-Besitzer nicht bestimmt. Das ist mehr Kontrolle und mehr zu prüfen, und deshalb verbringt der Cursor-Leitfaden seine Zeit mit deiner Build-Ausgabe und deiner Datenbank statt mit dem Editor. Der Replit-Beitrag stellt dieselben drei Fragen an eine Plattform, die die App hostet und dich zugleich einen eigenen Server ausliefern lässt.

Der Fünf-Minuten-Check von außen

Nimm für die ersten drei ein privates Fenster, damit deine eigene Anmeldung nicht für einen Fremden antwortet.

1. Öffne deine veröffentlichte Adresse mit /.env am Ende, dann mit /.git/config. Beides sollte scheitern. Zeigt eines davon Text, rotiere heute jeden Schlüssel darin und repariere dann den Deploy, damit die Datei nie ausgeliefert wird.
2. Öffne auf dieselbe Weise eine deiner eigenen API-Routen, eine, die kein Fremder lesen sollte. Antwortet sie mit Daten, braucht diese Route eine Anmeldeprüfung.
3. Öffne deine laufende App und dann den Reiter „Sources“ in den Entwicklerwerkzeugen deines Browsers. Kannst du deine Originaldateien mit Kommentaren lesen, sind Source-Maps in deinem Produktions-Build an.
4. Liegen deine Daten in Supabase, steht die innere Hälfte des Checks im Cursor-Leitfaden: Durchsuche die Build-Ausgabe nach service_role und sk_live_, und öffne dann die Policies-Seite.
5. Oder lass den Scan das erledigen. Er führt diese und die übrigen der neun von außen aus, dauert etwa 20 Sekunden, braucht kein Konto und gibt für alles, was er nicht beantworten konnte, „Konnte nicht prüfen“ aus und keinen Haken: App scannen.

Was ändert sich nach dem nächsten Push?

Alles Mögliche. Ein Cursor-Projekt geht live, wenn du es pushst, und nichts zwischen deinem Editor und dem Internet liest die App noch einmal auf eine Route, die ihre Anmeldeprüfung verloren hat, einen Schlüssel, der um Mitternacht eingefügt wurde, um an einem scheiternden Build vorbeizukommen, oder eine Source-Map, die mit einer Konfigurationsänderung wieder angegangen ist. Die Veracode-Zahl ist der Grund, warum das hier mehr zählt als bei einem Builder: Jede Sitzung mit dem Agenten ist neuer Code, der kompiliert und womöglich nicht sicher ist, und ein Scan vom letzten Monat beschreibt die App vom letzten Monat.

Reeve Monitor ist dafür gebaut. Er führt alle neun Checks jede Stunde auf bis zu drei Apps aus, prüft die Erreichbarkeit alle 60 Sekunden, sagt dir Bescheid, wenn sich ein Ergebnis ändert, statt darauf zu warten, dass du nachsiehst, und schickt einen Monatsbericht. Er kostet €12 im Monat zum Listenpreis, mit sieben Tagen kostenlos, bevor er dir etwas berechnet; die Preisseite liegt manchmal unter der Zahl hier und nie darüber. Monitor beobachtet und sonst nichts. Hält deine Cursor-App ihre Daten in Supabase, ist Care der Tarif, der zusätzlich eine Kopie dieser Datenbank hält, und auch deiner hochgeladenen Dateien, sobald du einen Storage-Zugangsschlüssel verbindest. Liegen die Daten woanders, ist Monitor die Hälfte, die passt.

Was du diese Woche tun solltest

Die innere Hälfte von alldem, die Build-Ausgabe und die Datenbank, ist der Cursor-Leitfaden. Die 10-Minuten-Sicherheitscheckliste deckt ab, was sich bei jeder frisch gestarteten App zu prüfen lohnt, egal, was sie geschrieben hat.