"¿Es Cursor seguro?" son dos preguntas con un mismo abrigo. La gente quiere decir o bien "¿es seguro usar Cursor con mi código?" o bien "¿es seguro el código que Cursor escribe?" — y las respuestas son muy distintas.

Pregunta 1: ¿Es segura la herramienta Cursor?

Cursor es un editor basado en VS Code. Corre local y tu proyecto queda en tu máquina. Para la mayoría es razonable confiar en la herramienta:

  • Privacy Mode — activado, Cursor indica que tu código no se almacena ni se usa para entrenar. Activalo para código propietario.
  • Local-first — el editor trabaja sobre tus archivos locales; vos hosteás la app resultante.
  • Comandos del agente — el agente puede correr comandos. Revisá lo que propone antes de aprobar.

Para datos exactos y actuales (SOC 2, retención), revisá la página de trust/seguridad oficial de Cursor.

Pregunta 2: ¿Es seguro el código que genera Cursor?

Acá está el riesgo real: no, salvo que lo asegures vos. Cursor es brillante produciendo código que funciona. "Funciona" y "seguro" no son lo mismo. Las vulnerabilidades de las apps hechas con Cursor son las mismas de toda app vibe-coded: secretos hardcodeados, sin auth, input sin validar, RLS de Supabase apagado.

El peligro específico de Cursor es la velocidad de aceptación: apretás "accept" en un diff, anda, seguís — y la clave hardcodeada ya se publicó. Un .cursorrules guía el estilo, pero no obliga seguridad.

Cómo hacer que Cursor escriba código más seguro

  • Pedilo explícito: "usá variables de entorno, validá el input y agregá auth".
  • Sumá reglas en .cursorrules (sin secretos en el cliente, siempre limitar queries al usuario).
  • Leé el diff antes de aceptar: claves, findMany() sin where, SQL armado con strings.

Verificá lo que realmente publicaste

Nurbak escanea tu app hecha con Cursor desde afuera: secretos expuestos, endpoints sin auth, RLS abierto y headers faltantes, con informe priorizado. Pegás la URL y tenés el resultado en segundos.

Artículos relacionados