// guía de seguridad
Seguridad para apps hechas con Cursor
Cursor es distinto a Lovable/Bolt/v0: es un IDE con asistencia de IA, no un builder que despliega solo. Eso significa que vos controlás el deploy y el repo, pero también que la responsabilidad de seguridad recae más en vos. Estos son los patrones que vemos en proyectos donde Cursor (o Claude Code, GitHub Copilot, similar) fue el asistente principal.
// contexto del stack
Contexto de Cursor
En Cursor, el modelo lee tu codebase completo como contexto. Tiende a continuar patrones existentes — bueno cuando los patrones son seguros, malo cuando no. La revisión humana de los diffs es la primera línea de defensa. Cuando ese patrón heredado es una regla de autorización débil, el resultado puede ser grave: la CVE-2025-48757 (CVSS 9.3) describe RLS insuficiente que permitía lectura y escritura no autenticada vía anon key —marcada DISPUTED por el proveedor, pero un recordatorio de que copiar políticas inseguras escala el riesgo.
// hallazgos frecuentes
Vulnerabilidades más comunes en Cursor
01 Secretos commiteados accidentalmente
Cuando le pedís a Cursor "agregá la integración con OpenAI", a veces escribe la clave en un archivo de config que vos commiteás sin notar. Una vez en el historial, rotar la clave es la única salida.
→ cómo arreglarlo
Configurá pre-commit hooks con `trufflehog`, `gitleaks` o `detect-secrets`. Bloquean commits que incluyen patrones de claves. Si ya filtraste algo, rotalo inmediatamente y rewritea el historial con `git filter-repo`.
02 Dependencias vulnerables sin actualizar
Cursor sugiere `npm install <paquete>` y termina la tarea. La verificación de vulnerabilidades es trabajo separado que rara vez hace el modelo.
→ cómo arreglarlo
Corré `npm audit` (o `pnpm audit`) regularmente. Agregá Dependabot/Renovate al repo para PRs automáticos de updates de seguridad. Idealmente, no aceptes deps con vulnerabilidades critical/high.
03 Validación insuficiente en endpoints generados
Cuando Cursor genera un endpoint API, suele incluir validación básica (presencia de campos requeridos) pero no maneja edge cases (strings demasiado largos, formatos incorrectos, valores fuera de rango).
→ cómo arreglarlo
Validá con Zod cada endpoint. `z.string().max(1000)`, `z.number().int().min(0).max(100)`, etc. Si Cursor genera un endpoint, pedile explícitamente que agregue Zod schema.
04 Tests que pasan pero no cubren security
Cursor genera tests felices ("happy path") rápidamente. Tests que verifiquen seguridad (un usuario A no puede leer datos de B, inputs maliciosos no rompen el endpoint) son menos comunes.
→ cómo arreglarlo
Por cada feature de auth/autorización, agregá explícitamente tests negativos. "Como user A intento leer recurso de user B → debe fallar con 403". Hacé que Cursor genere estos tests pidiéndolos por nombre.
05 Comentarios "TODO: agregar auth" que nunca se completaron
Cursor a veces deja un comentario tipo `// TODO: implementar verificación de permisos` antes de hacer algo sensible. Si confiás en el commit sin leer, el TODO va a producción.
→ cómo arreglarlo
Configurá un linter rule que falle el build si encuentra `TODO`, `FIXME`, `HACK` en directorios sensibles (`src/api/`, `src/auth/`). ESLint plugin `eslint-plugin-no-warning-comments`.
// checklist pre-launch
Checklist pre-launch para Cursor
- Configurar pre-commit hook con gitleaks o trufflehog
- Correr `pnpm audit` y resolver vulnerabilidades critical/high
- Validar todos los endpoints API con Zod (en servidor)
- Tests negativos para cada feature de autorización
- Linter rule que bloquea TODO/FIXME en código de producción
- Code review humano de cada diff que toca auth, payments o secrets
- Headers de seguridad configurados en el hosting
- Si usás Supabase: RLS en todas las tablas
- Auditar con VibeAuditt antes del launch y después de cada release mayor
// lectura relacionada
Posts relacionados
// escaneá ahora
Audita tu app Cursor gratis
VibeAuditt detecta automáticamente los errores de este checklist en menos de un minuto. Sin tarjeta, sin instalación.