FixVibe

// docs / security guides / cursor checklist

Cursor security checklist: 25 items before ship

Building with Cursor? Cursor's autocomplete and Agent features are exceptionally powerful — and create predictable security blind spots. This checklist targets Cursor-specific patterns: service-role key inlining, generated multi-file edits merged without review, Agent-mode terminal commands, and project rules (.cursor/rules) as your first security guardrail. 25 items across secrets, database, auth, headers, deployment, and Cursor-specific gotchas.

PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

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 your project rules. Add a rule in .cursor/rules (Cursor docs): "Never inline SUPABASE_SERVICE_ROLE_KEY, sk_live_*, or any server secret into client-side code. Always use server-only imports." Cursor applies project rules as context for Agent and chat.
  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 in JavaScript Bundles. 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 — Make Cursor generate migrations with RLS. In your project rules: "Every CREATE TABLE public.* migration must include ALTER TABLE ... ENABLE ROW LEVEL SECURITY and a policy per command scoped to auth.uid()." Then ask Cursor to generate the migration.
  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 RLS and policies are live. Open Supabase Studio and check that every table's RLS toggle is on and that each table has policies. A table with RLS on and no policies denies everything; one with USING (true) allows everyone.
  4. POST — Run a FixVibe scan on the deployed app. Check the Supabase Row-Level Security result: it shows any table an anonymous visitor can read with your public key.

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 your project rules. Add: "Generate a src/middleware.ts with Content-Security-Policy. Use nonce for script-src, no unsafe-inline." Then ask Cursor to generate it. Without this hint, middleware is skipped.
  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 HTTP 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 (51 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.

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • 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.
Ejecuta un escaneo gratis →

sin registro

Cursor security checklist: 25 items before ship · FixVibe