Seguridad para el código que escribes con Cursor

"Seguridad en Cursor" significa dos cosas distintas, y conviene separarlas. La primera es proteger tu propia configuración de Cursor: qué sale de tu máquina, qué puede ejecutar el agente sin preguntarte y en qué servidores y archivos de reglas confías. La segunda es proteger el código que Cursor escribe por ti, que es lo que acaba desplegado y expuesto a internet. Esta guía cubre las dos, con un bloque de reglas listo para pegar en tu proyecto y un prompt de revisión para antes de desplegar.

Parte 1: proteger tu configuración de Cursor

Qué sale de tu máquina

Cursor envía a sus servidores, y a los del proveedor del modelo, el contexto que necesita para responder: el archivo abierto, lo que indexa del proyecto y lo que tú pegas en el chat. Activa el modo privacidad en los ajustes si no quieres que ese código se almacene ni se use para entrenar; en equipos, imponlo desde el plan. Y recuerda que todo lo que pegues en el chat viaja: no pegues volcados de base de datos ni archivos de credenciales "para que lo entienda".

Excluye los secretos de la indexación

Cursor indexa el proyecto para dar contexto al modelo. Un .env, un service-account.json o una carpeta de certificados no deberían formar parte de ese índice. Crea un archivo .cursorignore en la raíz con los patrones a excluir; sigue la sintaxis de .gitignore:

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

Si algo sensible ya estaba indexado, bórralo del índice desde los ajustes y, si era una clave real, rótala.

Auto-ejecución de comandos

El agente de Cursor puede ejecutar comandos de terminal por su cuenta si se lo permites. Es cómodo y es peligroso: un prompt mal entendido, o un texto malicioso que el agente lee de un archivo o de una web, puede acabar en un rm -rf, un git push --force o un curl | sh. Mantén la confirmación manual para comandos que borran, publican o instalan, usa la lista de permitidos solo para cosas inofensivas (tests, lint, build) y nunca le des al agente credenciales de producción en el entorno.

Servidores MCP de terceros

Los servidores MCP amplían lo que el agente puede hacer: leer tu base de datos, llamar a APIs, controlar el navegador. Cada uno es código que corre con tus permisos y cuyas descripciones de herramientas lee el modelo como instrucciones. Instala solo servidores de fuentes que conozcas, revisa qué piden, prefiere los que funcionan con credenciales de solo lectura y vigila los cambios de configuración: un servidor que cambia su definición después de que lo aprobaras es una señal de alarma.

Archivos de reglas de repos ajenos

Los archivos de reglas (.cursor/rules, .cursorrules) son instrucciones que el modelo obedece en cada petición. Si clonas un repositorio, una plantilla o un ejemplo de internet, puede traer reglas que no ves a simple vista, incluso con caracteres invisibles que esconden instrucciones para colar código malicioso. Abre y lee los archivos de reglas de cualquier proyecto que no hayas escrito tú antes de dejar que el agente trabaje en él.

Mantén Cursor actualizado

Como cualquier editor con un agente dentro, Cursor ha tenido fallos de seguridad propios, varios relacionados con la confianza en espacios de trabajo y con MCP. Actualiza cuando salga una versión nueva y no abras proyectos de origen dudoso con la auto-ejecución activada.

Parte 2: los fallos que Cursor mete en tu código

El modelo optimiza para que el código funcione, no para que sea seguro. Estos son los patrones que más se repiten en apps escritas con Cursor y cómo detectarlos:

• Secretos hardcodeados. Para que un ejemplo arranque rápido, la clave acaba en el código o en una variable pública. Busca sk_live, service_role, AKIA y -----BEGIN en tu bundle. Más en los secretos que tu app filtra en el navegador.
• CORS abierto y auth desactivada "para que funcione". Ante un error, la sugerencia típica es reflejar cualquier origen o saltarse la comprobación de sesión. Funciona en el momento y deja la puerta abierta en producción.
• Endpoints que confían en el cliente. Rutas que aceptan el user_id, el rol o el precio desde el cuerpo de la petición sin comprobarlo en el servidor.
• Sin cabeceras de seguridad. El código generado casi nunca añade CSP, HSTS o X-Frame-Options; compruébalo con el verificador de cabeceras.
• Dependencias viejas. El modelo propone las versiones que conoce, no las últimas. Pasa npm audit antes de desplegar.

Un bloque de reglas de seguridad para tu proyecto

Lo más rentable que puedes hacer es decirle al modelo, una vez y para siempre, lo que no debe hacer. Pega esto en .cursor/rules/security.mdc (o en .cursorrules) con la regla marcada para aplicarse siempre. Está en inglés porque es el idioma en el que mejor obedece el modelo:

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

Un prompt de revisión antes de desplegar

Antes de cada despliegue, abre un chat nuevo con todo el proyecto en contexto y pídele: "Revisa este proyecto como auditor de seguridad antes del despliegue. Lista cada secreto que llegue al código del cliente, cada ruta de API sin comprobación de sesión o permisos, cada regla de CORS o RLS relajada, las cabeceras de seguridad que faltan y las cookies sin Secure, HttpOnly o SameSite. Para cada hallazgo indica archivo, línea y el arreglo. No cambies código todavía." Después arregla los hallazgos uno a uno y vuelve a pedir la revisión.

Comprueba el resultado desde fuera

El modelo revisa el código que ve; lo que importa es lo que ve un atacante. Cuando despliegues, pasa Scanaris sobre la URL pública: detecta secretos en el JavaScript, CORS permisivo, cabeceras y cookies mal configuradas, archivos sensibles accesibles y versiones con vulnerabilidades conocidas, y te devuelve un prompt para pegar en Cursor por cada hallazgo. Si lo dejas en monitorización, te avisa cuando una sesión de vibe coding vuelva a abrir algo que ya estaba cerrado. Para el mapa completo, lee la guía de seguridad para apps hechas con IA y la checklist de lanzamiento.

Preguntas frecuentes

¿Es seguro usar Cursor con código de empresa?

Con el modo privacidad activado, los secretos excluidos de la indexación y sin pegar datos reales en el chat, el riesgo es comparable al de cualquier herramienta en la nube. Comprueba las políticas de tu empresa y, si hace falta, usa el plan de equipo para imponer la configuración.

¿El código que escribe Cursor es menos seguro que el escrito a mano?

No necesariamente, pero falla en sitios predecibles: secretos, permisos que estorban y configuración que nadie pidió. Con reglas claras y una revisión antes de desplegar, el resultado suele ser mejor que la media.

¿Qué hago si el agente ya ejecutó algo que no debía?

Rota cualquier credencial a la que tuviera acceso, revisa el historial de git y de la terminal para ver qué tocó, y restringe la auto-ejecución antes de seguir.