Sicherheit für den Code, den du mit Cursor schreibst

„Cursor-Sicherheit" bedeutet zwei verschiedene Dinge, und es lohnt sich, sie auseinanderzuhalten. Das erste ist der Schutz deiner eigenen Cursor-Einrichtung: was deinen Rechner verlässt, was der Agent ausführen darf, ohne dich zu fragen, und welchen Servern und Regeldateien du vertraust. Das zweite ist der Schutz des Codes, den Cursor für dich schreibt, denn der landet deployt und offen im Internet. Dieser Guide behandelt beides, mit einem Regelblock zum Einfügen in dein Projekt und einem Review-Prompt für jeden Deploy.

Teil 1: deine Cursor-Einrichtung absichern

Was deinen Rechner verlässt

Cursor schickt an seine Server, und an die des Modellanbieters, den Kontext, den es zum Antworten braucht: die geöffnete Datei, das, was es vom Projekt indexiert, und alles, was du in den Chat einfügst. Aktiviere den Privacy Mode in den Einstellungen, wenn dieser Code weder gespeichert noch fürs Training genutzt werden soll; in Teams erzwingst du ihn über den Plan. Und denk daran, dass alles, was du in den Chat einfügst, unterwegs ist: Füge keine Datenbank-Dumps oder Credential-Dateien ein, „damit es versteht".

Secrets aus dem Index heraushalten

Cursor indexiert das Projekt, um dem Modell Kontext zu geben. Eine .env, eine service-account.json oder ein Zertifikatsordner gehören nicht in diesen Index. Lege im Stammverzeichnis eine Datei .cursorignore mit den auszuschließenden Mustern an; sie folgt der Syntax von .gitignore:

.env
.env.*
*.pem
*.key
**/service-account*.json
secrets/

War etwas Sensibles bereits indexiert, entferne es in den Einstellungen aus dem Index und rotiere den Key, falls er echt war.

Automatisches Ausführen von Befehlen

Der Cursor-Agent kann Terminalbefehle selbstständig ausführen, wenn du es erlaubst. Das ist bequem und gefährlich: Ein missverstandener Prompt oder ein bösartiger Text, den der Agent aus einer Datei oder Webseite liest, kann in einem rm -rf, einem git push --force oder einem curl | sh enden. Behalte die manuelle Bestätigung für Befehle, die löschen, veröffentlichen oder installieren, nutze die Allow-Liste nur für Harmloses (Tests, Lint, Build) und gib dem Agenten nie Produktions-Credentials in seine Umgebung.

MCP-Server von Dritten

MCP-Server erweitern, was der Agent tun kann: deine Datenbank lesen, APIs aufrufen, den Browser steuern. Jeder davon ist Code, der mit deinen Rechten läuft und dessen Tool-Beschreibungen das Modell als Anweisungen liest. Installiere nur Server aus bekannten Quellen, prüfe, was sie verlangen, bevorzuge solche, die mit schreibgeschützten Credentials auskommen, und achte auf Konfigurationsänderungen: Ein Server, der seine Definition ändert, nachdem du ihn genehmigt hast, ist ein Warnsignal.

Regeldateien aus fremden Repos

Regeldateien (.cursor/rules, .cursorrules) sind Anweisungen, denen das Modell bei jeder Anfrage folgt. Wenn du ein Repository, ein Template oder ein Beispiel aus dem Internet klonst, kann es Regeln mitbringen, die du auf den ersten Blick nicht siehst, sogar mit unsichtbaren Zeichen, die Anweisungen zum Einschleusen von Schadcode verstecken. Öffne und lies die Regeldateien jedes Projekts, das du nicht selbst geschrieben hast, bevor du den Agenten darin arbeiten lässt.

Halte Cursor aktuell

Wie jeder Editor mit eingebautem Agenten hatte Cursor eigene Sicherheitslücken, mehrere rund um Workspace-Vertrauen und MCP. Aktualisiere, sobald eine neue Version erscheint, und öffne keine Projekte zweifelhafter Herkunft mit aktiviertem Auto-Run.

Teil 2: die Lücken, die Cursor in deinen Code baut

Das Modell optimiert darauf, dass der Code läuft, nicht darauf, dass er sicher ist. Das sind die Muster, die sich in mit Cursor geschriebenen Apps am häufigsten wiederholen, und wie du sie erkennst:

• Hartkodierte Secrets. Damit ein Beispiel schnell läuft, landet der Key im Code oder in einer öffentlichen Variable. Durchsuche dein Bundle nach sk_live, service_role, AKIA und -----BEGIN. Mehr in den Secrets, die deine App im Browser preisgibt.
• Offenes CORS und deaktivierte Auth, „damit es läuft". Bei einem Fehler lautet der typische Vorschlag, jede Herkunft zu spiegeln oder die Session-Prüfung zu überspringen. Im Moment funktioniert das und lässt in der Produktion die Tür offen.
• Endpoints, die dem Client vertrauen. Routen, die user_id, Rolle oder Preis aus dem Request-Body übernehmen, ohne sie auf dem Server zu prüfen.
• Keine Sicherheits-Header. Generierter Code fügt fast nie CSP, HSTS oder X-Frame-Options hinzu; prüfe es mit dem Header-Checker.
• Alte Abhängigkeiten. Das Modell schlägt die Versionen vor, die es kennt, nicht die neuesten. Führe vor dem Deploy npm audit aus.

Ein Block Sicherheitsregeln für dein Projekt

Das Lohnendste, was du tun kannst: dem Modell ein für alle Mal sagen, was es nicht tun darf. Füge das in .cursor/rules/security.mdc (oder in .cursorrules) ein, mit der Regel auf „immer anwenden". Es ist auf Englisch, weil das Modell in dieser Sprache am zuverlässigsten gehorcht:

# Security rules (always apply)
- Never hardcode API keys, tokens or passwords. Read them from
  environment variables on the server only.
- Never put secrets in variables prefixed NEXT_PUBLIC_, VITE_ or NUXT_PUBLIC_.
- Never disable authentication, authorization or Row Level Security
  to make something work. Fix the policy instead and explain why.
- CORS: allow only an explicit list of origins. Never reflect the
  request origin together with credentials.
- Validate input and authorize every API route on the server, even if
  the UI hides the action.
- Set security headers: CSP, HSTS, X-Frame-Options,
  X-Content-Type-Options, Referrer-Policy.
- Session cookies must be Secure, HttpOnly and SameSite=Lax.
- Add a dependency only when necessary, pinned to a maintained version.
- If a request conflicts with these rules, stop and explain the
  security trade-off before writing code.

Ein Review-Prompt vor dem Deploy

Öffne vor jedem Deploy einen neuen Chat mit dem ganzen Projekt im Kontext und bitte: „Prüfe dieses Projekt vor dem Deployment als Security-Auditor. Liste jedes Secret auf, das in Client-Code gelangt, jede API-Route ohne Session- oder Berechtigungsprüfung, jede gelockerte CORS- oder RLS-Regel, die fehlenden Sicherheits-Header und die Cookies ohne Secure, HttpOnly oder SameSite. Gib zu jedem Fund Datei, Zeile und die Korrektur an. Ändere noch keinen Code." Behebe die Funde dann einzeln und fordere das Review erneut an.

Prüfe das Ergebnis von außen

Das Modell prüft den Code, den es sieht; was zählt, ist, was ein Angreifer sieht. Lass nach dem Deploy Scanaris über die öffentliche URL laufen: Es erkennt Secrets im JavaScript, freizügiges CORS, falsch konfigurierte Header und Cookies, erreichbare sensible Dateien und Versionen mit bekannten Schwachstellen, und liefert dir zu jedem Fund einen Prompt zum Einfügen in Cursor. Lässt du das Monitoring an, meldet es sich, wenn eine Vibe-Coding-Session etwas wieder öffnet, das schon geschlossen war. Die vollständige Karte findest du im Sicherheitsguide für KI-gebaute Apps und in der Launch-Checkliste.

Häufig gestellte Fragen

Ist es sicher, Cursor mit Firmencode zu nutzen?

Mit aktiviertem Privacy Mode, aus dem Index ausgeschlossenen Secrets und ohne echte Daten im Chat ist das Risiko mit dem jedes Cloud-Tools vergleichbar. Prüfe die Richtlinien deiner Firma und erzwinge die Konfiguration bei Bedarf über den Team-Plan.

Ist der Code, den Cursor schreibt, unsicherer als handgeschriebener?

Nicht zwangsläufig, aber er scheitert an vorhersehbaren Stellen: Secrets, störende Berechtigungen und Konfiguration, nach der niemand gefragt hat. Mit klaren Regeln und einem Review vor dem Deploy ist das Ergebnis meist besser als der Durchschnitt.

Was tun, wenn der Agent schon etwas ausgeführt hat, das er nicht sollte?

Rotiere alle Credentials, auf die er Zugriff hatte, prüfe die Git- und Terminal-Historie, um zu sehen, was er angefasst hat, und schränke Auto-Run ein, bevor du weitermachst.