FixVibe

// docs / security guides / cursor checklist

Checklist de seguridad de Cursor: 28 ítems antes de enviar

¿Construyendo con Cursor? Las funciones de autocompletar, modo Composer y Agente de Cursor son excepcionalmente poderosas y crean puntos ciegos de seguridad predecibles. Esta lista de verificación se centra en patrones específicos de Cursor: inserción de claves de función de servicio, archivos completos generados por Composer sin revisión, comandos de terminal en modo agente y el archivo <code>.cursorrules</code> como su primera barrera de seguridad. 28 elementos entre secretos, base de datos, autenticación, encabezados, implementación y errores específicos de Cursor.

PRE = implementación previa (audite su fuente). DEPLOY = en el momento de la implementación. POST = verificación posterior a la implementación. Referencia de artículos FixVibe verifique los ID en formato category.check-id cuando sea relevante.

Secretos y claves API (5 artículos)

El autocompletado de Cursor se basa en código de fuente abierta donde los secretos son comunes. El modelo los sugiere libremente, especialmente después de un intento de autenticación fallido.

  1. PRE — Write security rules into .cursorrules. Agregue una línea: "Nunca incluya SUPABASE_SERVICE_ROLE_KEY, sk_live_* o cualquier variable de entorno que comience con un acrónimo de proveedor en el código del lado del cliente. Utilice siempre importaciones solo del servidor". Cursor lee .cursorrules y lo tiene en cuenta en cada sugerencia.
  2. PRE — Audit Composer-generated files. Cuando el Composer de Cursor crea un archivo completo (especialmente los controladores de autenticación), revíselo línea por línea. Composer a veces incluye variables de entorno que deberían permanecer solo en el servidor. Busque NEXT_PUBLIC_ o referencias directas a claves de servicio en las importaciones de componentes.
  3. PRE — Reject auto-imports of service clients into client components. Si Composer importa import { supabase } from '@/lib/supabase/service' a un archivo React, elimínelo inmediatamente y enrútelo a través de un punto final API. Las importaciones solo del servidor están marcadas explícitamente; no las omita.
  4. PRE — Scan Agent-mode commits. El modo agente ejecuta comandos de terminal y puede confirmarlos directamente. Audite git log --oneline -20 y git diff HEAD~5 para garantizar que no se hayan confirmado cadenas que parezcan secretas durante la ejecución del Agente.
  5. POST — Run secrets.browser-storage. Escaneo pasivo en el URL implementado. Si aparece una clave de servicio en el paquete JS, gírela inmediatamente; el autocompletado de Cursor probablemente la incluya.

Control de acceso a la base de datos (4 artículos)

Composer a menudo genera un código de autenticación que funciona pero omite RLS; el momento de "funciona" ciega a las personas ante la falta de aplicación de políticas.

  1. PRE — Force Cursor to generate migrations with RLS. En .cursorrules: "Cada migración CREATE TABLE public.* debe incluir ALTER TABLE ... ENABLE ROW LEVEL SECURITY y FORCE ROW LEVEL SECURITY". Luego pídale a Composer que genere la migración.
  2. PRE — Review Composer-generated policies. Composer a veces escribe políticas sin verificar auth.uid(). Políticas como allow select on public.items sin una cláusula using son peligrosamente amplias. Requiere coincidencia de user_id.
  3. DEPLOY — Confirm FORCE ROW LEVEL SECURITY is live. Abra Supabase Studio, verifique el interruptor RLS de cada tabla. Si la migración de Composer tenía ENABLE pero olvidó FORCE, los propietarios de la tabla (sus migraciones) omiten RLS. Esta es una brecha real.
  4. POST — Run the baas.supabase-rls active check. Intenta escribir con la tecla anon. Si tiene éxito, RLS en realidad no se está aplicando; es probable que falte la palabra clave FORCE.

Autenticación y sesiones (4 artículos)

Cursor genera flujos de autenticación rápidamente pero a menudo pasa por alto la sutil validación del lado del servidor que mantiene los tokens seguros.

  1. PRE — Ensure all auth routes use getUser(). Busque getSession() en sus rutas API y reemplácelas con await supabase.auth.getUser(). getSession() lee una cookie no verificada; getUser() valida con Supabase backend.
  2. PRE — Check Composer auth handlers for token expiry. Los tokens Magic-link necesitan expires_at aplicados por el servidor. El Supabase predeterminado es 1 hora; no le pida a Cursor que lo anule sin una razón real.
  3. PRE — Audit the sign-in redirect guard. La redirección del parámetro de consulta next después del inicio de sesión debe validarse: debe comenzar con /, nunca //. El compositor a veces se salta esto. Agréguelo manualmente si falta.
  4. POST — Test logout server-side state destruction. Iniciar sesión, cerrar sesión, inspeccionar las cookies (DevTools → Aplicación → Cookies). La cookie de sesión debe borrarse inmediatamente. Si persiste, el controlador de cierre de sesión no está destruyendo el estado.

HTTP encabezados de seguridad y CSP (3 elementos)

Cursor rara vez genera middleware de forma predeterminada. Si no pregunta explícitamente, CSP y HSTS normalmente no están allí.

  1. PRE — Demand CSP in .cursorrules. Agregar: "Genere un src/middleware.ts con Content-Security-Policy. Utilice nonce para script-src, no unsafe-inline". Luego pídele a Cursor que lo genere. Sin esta sugerencia, se omite el middleware.
  2. PRE — Verify src/middleware.ts exists. Con el diseño del directorio src/, Next.js solo selecciona src/middleware.ts. Un middleware.ts de nivel raíz se ignora silenciosamente. Si CSP no llega, verifique que el archivo esté en el lugar correcto.
  3. POST — Run headers.security-headers. Faltan informes de escaneo pasivo CSP, HSTS, X-Frame-Options, X-Content-Type-Options. Abra el informe y siga las instrucciones de reparación para su plataforma de implementación.

Higiene del despliegue (5 artículos)

Las aplicaciones Cursor a menudo aterrizan en Vercel, que tiene buenos valores predeterminados pero necesita un refuerzo explícito para el límite build/deploy.

  1. DEPLOY — Check Vercel env-var scoping. Configuración → Variables de entorno → cada secreto debe tener como ámbito Producción únicamente. Nunca comparta sk_live_* con Vista previa o Desarrollo.
  2. DEPLOY — Disable build-log secret echo. Si su flujo de trabajo de acciones vercel.json o GitHub tiene echo $SECRET, elimínelo. Los registros de compilación se archivan públicamente; Los secretos en los registros están comprometidos.
  3. La configuración de DEPLOY — Use Vercel's managed secrets, not inline workflow vars. Vercel → Variables de entorno está cifrada en reposo. Los secretos de las acciones GitHub son mejores que nada, pero están diseñados para CI, no para la integración de la plataforma de implementación.
  4. POST — Verify CSP nonce on the deployed preview. Abra un enlace de vista previa Vercel en el navegador, abra DevTools → Red → la respuesta raíz HTML. El encabezado CSP debe estar presente e incluir 'strict-dynamic' con un nonce único por solicitud.
  5. POST — Rotate any key that ever shipped, even to Preview. Si una clave llegó al paquete de producción incluso durante 10 minutos, está comprometida. Girar inmediatamente.

Cursor errores específicos (4 artículos)

Patrones exclusivos del flujo de trabajo de Cursor que crean riesgos de seguridad:

  1. Agent mode auto-fixes propagate old patterns. Si le pide al Agente que "arregle los errores de autenticación", puede regenerar el mismo archivo de autenticación varias veces, cada vez insertando la misma clave de servicio si está en el contexto del código base. Primero limpie el original y luego pídale al Agente que lo arregle.
  2. La indexación @codebase de Cursor Index leaks intent. Cursor es poderosa, pero si su directorio .cursor alguna vez queda expuesto (S3 mal configurado, historial de git), el índice revela su arquitectura y patrones secretos. Mantenga .cursor local.
  3. Composer mode loses context between files. Cada archivo que genera Composer es nuevo. Si le pide que genere un archivo de cliente, luego una ruta API, pueden usar diferentes configuraciones de cliente Supabase. Revise ambos y asegúrese de que coincidan con su arquitectura.
  4. Autocomplete bias toward "working" over "secure". Cursor sugiere el código más rápido que pasa por su contexto actual. Si su prueba tiene NEXT_PUBLIC_SERVICE_KEY, la función de autocompletar la recuerda y la vuelve a sugerir. Limpie los dispositivos de prueba antes de compartir el código con el modelo.

Próximos pasos

Una vez que haya bloqueado los patrones específicos de Cursor, verifique con general vibe coding security checklist (44 elementos) y luego con step-by-step hardening. Consulte también Claude Code checklist si está mezclando herramientas.

// escanea tu app

Deja de leer. Empieza a encontrar las brechas en la tuya.

Pega una URL — FixVibe ejecuta todas las verificaciones pasivas de esta guía más 200 adicionales en menos de un minuto. Gratis, sin instalación, sin tarjeta.

  • Tier gratis — 3 escaneos / mes, sin tarjeta.
  • Escaneos pasivos contra cualquier URL — sin verificación de dominio.
  • Afinado para Cursor, Claude Code, Lovable, Bolt, v0, Replit.
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
Checklist de seguridad de Cursor: 28 ítems antes de enviar — Docs · FixVibe