Beveiliging voor de code die je met Cursor schrijft

"Cursor security" betekent twee verschillende dingen, en het loont om ze uit elkaar te houden. Het eerste is je eigen Cursor-installatie beveiligen: wat je machine verlaat, wat de agent mag uitvoeren zonder het te vragen, en welke servers en regelbestanden je vertrouwt. Het tweede is de code beveiligen die Cursor voor je schrijft, want die wordt gedeployd en staat open op internet. Deze gids behandelt beide, met een blok regels dat je zo in je project plakt en een reviewprompt voor elke deploy.

Deel 1: je Cursor-installatie beveiligen

Wat je machine verlaat

Cursor stuurt naar zijn servers, en naar die van de modelaanbieder, de context die het nodig heeft om te antwoorden: het geopende bestand, wat het van het project indexeert en alles wat je in de chat plakt. Zet de privacymodus aan in de instellingen als je niet wilt dat die code wordt opgeslagen of voor training wordt gebruikt; in teams dwing je hem af vanuit het plan. En onthoud dat alles wat je in de chat plakt onderweg gaat: plak geen databasedumps of credential-bestanden "zodat hij het snapt".

Houd secrets uit de index

Cursor indexeert het project om het model context te geven. Een .env, een service-account.json of een map met certificaten hoort niet in die index. Maak een bestand .cursorignore in de root met de patronen die je wilt uitsluiten; het volgt de syntaxis van .gitignore:

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

Was er al iets gevoeligs geïndexeerd, verwijder het dan uit de index via de instellingen en roteer de key als hij echt was.

Automatisch commando's uitvoeren

De agent van Cursor kan zelfstandig terminalcommando's uitvoeren als je dat toestaat. Dat is handig en gevaarlijk: een verkeerd begrepen prompt, of kwaadaardige tekst die de agent uit een bestand of webpagina leest, kan eindigen in een rm -rf, een git push --force of een curl | sh. Houd handmatige bevestiging voor commando's die verwijderen, publiceren of installeren, gebruik de toestemmingslijst alleen voor onschuldige dingen (tests, lint, build) en geef de agent nooit productie-credentials in zijn omgeving.

MCP-servers van derden

MCP-servers breiden uit wat de agent kan: je database lezen, API's aanroepen, de browser besturen. Elk ervan is code die met jouw rechten draait en waarvan het model de toolbeschrijvingen als instructies leest. Installeer alleen servers uit bronnen die je kent, bekijk wat ze vragen, geef de voorkeur aan servers die met read-only credentials werken en let op configuratiewijzigingen: een server die zijn definitie verandert nadat je hem hebt goedgekeurd, is een rode vlag.

Regelbestanden uit andermans repo's

Regelbestanden (.cursor/rules, .cursorrules) zijn instructies die het model bij elke aanvraag opvolgt. Als je een repository, template of voorbeeld van internet kloont, kan het regels bevatten die je niet op het eerste gezicht ziet, zelfs met onzichtbare tekens die instructies verbergen om kwaadaardige code binnen te smokkelen. Open en lees de regelbestanden van elk project dat je niet zelf hebt geschreven voordat je de agent erin laat werken.

Houd Cursor up-to-date

Zoals elke editor met een agent erin heeft Cursor eigen beveiligingsfouten gehad, verschillende rond workspace-vertrouwen en MCP. Update zodra er een nieuwe versie uitkomt en open geen projecten van twijfelachtige herkomst met automatisch uitvoeren aan.

Deel 2: de fouten die Cursor in je code stopt

Het model optimaliseert ervoor dat de code werkt, niet dat hij veilig is. Dit zijn de patronen die het vaakst terugkomen in apps die met Cursor zijn geschreven en hoe je ze herkent:

• Hardcoded secrets. Om een voorbeeld snel aan de praat te krijgen, belandt de key in de code of in een publieke variabele. Zoek in je bundle naar sk_live, service_role, AKIA en -----BEGIN. Meer in de secrets die je app in de browser lekt.
• Open CORS en auth uitgezet "om het werkend te krijgen". Bij een foutmelding is de typische suggestie om elke origin te weerspiegelen of de sessiecheck over te slaan. Het werkt op dat moment en laat de deur open in productie.
• Endpoints die de client vertrouwen. Routes die de user_id, de rol of de prijs uit de request body accepteren zonder dat op de server te controleren.
• Geen security headers. Gegenereerde code voegt bijna nooit CSP, HSTS of X-Frame-Options toe; controleer het met de headers checker.
• Oude dependencies. Het model stelt de versies voor die het kent, niet de nieuwste. Draai npm audit voordat je deployt.

Een blok beveiligingsregels voor je project

Het meest lonende dat je kunt doen, is het model één keer en voorgoed vertellen wat het niet mag doen. Plak dit in .cursor/rules/security.mdc (of in .cursorrules) met de regel ingesteld op altijd toepassen. Het is in het Engels omdat het model in die taal het best gehoorzaamt:

# 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.

Een reviewprompt vóór de deploy

Open vóór elke deploy een nieuwe chat met het hele project in de context en vraag: "Beoordeel dit project als security-auditor vóór de deployment. Som elk secret op dat in clientcode terechtkomt, elke API-route zonder sessie- of rechtencontrole, elke versoepelde CORS- of RLS-regel, de ontbrekende security headers en de cookies zonder Secure, HttpOnly of SameSite. Geef bij elke bevinding het bestand, de regel en de fix. Verander nog geen code." Los de bevindingen daarna één voor één op en vraag de review opnieuw aan.

Controleer het resultaat van buitenaf

Het model beoordeelt de code die het ziet; wat telt is wat een aanvaller ziet. Draai na de deploy Scanaris op de publieke URL: het detecteert secrets in de JavaScript, te ruime CORS, verkeerd ingestelde headers en cookies, bereikbare gevoelige bestanden en versies met bekende kwetsbaarheden, en geeft je voor elke bevinding een prompt om in Cursor te plakken. Laat je monitoring aan, dan waarschuwt het je als een vibe coding-sessie iets heropent dat al dicht was. Voor de volledige kaart lees je de beveiligingsgids voor AI-gebouwde apps en de lanceerchecklist.

Veelgestelde vragen

Is het veilig om Cursor met bedrijfscode te gebruiken?

Met de privacymodus aan, secrets uitgesloten van de index en zonder echte data in de chat te plakken, is het risico vergelijkbaar met dat van elke cloudtool. Controleer het beleid van je bedrijf en gebruik zo nodig het teamplan om de configuratie af te dwingen.

Is de code die Cursor schrijft minder veilig dan handgeschreven code?

Niet per se, maar hij faalt op voorspelbare plekken: secrets, rechten die in de weg zitten en configuratie waar niemand om vroeg. Met duidelijke regels en een review vóór de deploy is het resultaat meestal beter dan gemiddeld.

Wat doe ik als de agent al iets heeft uitgevoerd wat niet mocht?

Roteer elke credential waar hij toegang toe had, bekijk de git- en terminalgeschiedenis om te zien wat hij heeft aangeraakt, en beperk automatisch uitvoeren voordat je verdergaat.