FixVibe

// docs / security guides / pre-ship checklist

La checklist de seguridad de vibe coding: 51 ítems antes de enviar

Una checklist práctica y organizada por fase para apps creadas con Cursor, Claude Code, Lovable, Bolt, v0, Replit y Windsurf. Cada ítem es accionable en menos de cinco minutos. Recórrela antes de enviar a producción y otra vez antes de cada release importante. Los ítems se agrupan en siete categorías — secretos, base de datos, autenticación, cabeceras, terceros, despliegue, monitoreo — y se etiquetan con la fase de deploy a la que aplican.

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

Secretos y claves API (8 artículos)

Las claves codificadas son el hallazgo más común en aplicaciones codificadas por vibración. Ocho elementos para mantenerlos alejados:

  1. PRE — Audit NEXT_PUBLIC_ env vars. Cualquier elemento con el prefijo NEXT_PUBLIC_ se envía en paquetes de clientes. Si una es una clave Supabase service_role (se decodifica a JWT con "role":"service_role"), elimínela y enrútela a través de un cliente de solo servidor (src/lib/supabase/service.ts con import 'server-only').
  2. PRE — Grep for hardcoded provider keys. Fuente de búsqueda para sk_live_, pk_live_, STRIPE_SECRET, sk-ant-, sk-, AIza, AKIA y JWT- buscando cadenas (eyJ). Mueva cada visita a .env.local y haga referencia a través de process.env.* únicamente en el lado del servidor.
  3. PRE — Verify .gitignore. Confirme .env*.local, .npmrc, .yarnrc y se ignorarán los archivos de credenciales específicos del proveedor. Ejecute git ls-files canalizado a través de los patrones de su proveedor para encontrar cualquier cosa que ya esté comprometida.
  4. PRE — Scan the built bundle. Ejecute npm run build, luego grep .next/static y cualquier salida dist/ para los mismos patrones. Si una clave llega al paquete, el desarrollador nunca tuvo una separación de entorno limpia.
  5. DEPLOY — Set secrets per environment. Vercel: Configuración → Variables de entorno, alcance cada una a Producción/Vista previa/Desarrollo. Nunca comparta sk_live_* con el entorno de vista previa. Utilice el almacenamiento env-var cifrado de Vercel, no los secretos de flujo de trabajo en línea.
  6. DEPLOY — Disable build-log secret echo. Algunas CI configuraciones echo variables de entorno durante la compilación. Audite sus flujos de trabajo de acciones vercel.json, GitHub o la configuración de páginas Cloudflare para detectar cualquier echo $SECRET que introduzca el valor en los registros de compilación públicos.
  7. El nivel Free de POST — Run a passive scan. FixVibe cubre esto: pegue el URL implementado, espere ~20 segundos, busque los resultados de secrets.*. El cheque Secrets in JavaScript Bundles captura claves que aterrizaron en localStorage o sessionStorage a través de un mal uso del SDK.
  8. POST — Rotate any key that ever shipped. Si una clave estuvo en un paquete público incluso durante minutos, trátela como comprometida. Gire las claves de función de servicio Supabase a través del panel, regenere las claves restringidas Stripe, revoque las claves Anthropic / OpenAI / Google a través de sus consolas.

Control de acceso a la base de datos: RLS y reglas de Firestore (6 elementos)

Los valores predeterminados de BaaS son permisivos a propósito, por lo que el primer tutorial funciona. Producción necesita políticas explícitas.

  1. PRE — Enable RLS on every public.* table. In Supabase: each table needs ALTER TABLE ... ENABLE ROW LEVEL SECURITY plus explicit policies for each role. RLS is what stops the anon and authenticated API roles; FORCE ROW LEVEL SECURITY only extends it to the table owner and is optional defence in depth.
  2. PRE — Write a policy per (table, role, action). Mínimo: una política SELECT que se une el auth.uid(). Mejor: separe las políticas INSERT / UPDATE / DELETE para que un UPDATE no pueda contrabandear cambios user_id que redireccionen la propiedad.
  3. PRE — Replace default Firebase rules. Las reglas predeterminadas del modo de prueba dicen allow read, write: if true;. Reemplace con reglas vinculadas a autenticación por colección: match /users/{userId} con allow read, write: if request.auth.uid == userId;
  4. PRE — Lint migrations in CI. Ejecute supabase db lint o un equivalente antes de fusionar. CI debería fallar en la compilación si algún CREATE TABLE public.* carece de una política RLS coincidente.
  5. DEPLOY — Confirm RLS survived deploy. Vuelva a verificar en Supabase Studio después de la implementación: Tablas → cada fila → RLS alternar es ON. Producción Las migraciones de bases de datos ocasionalmente se adelantan a los archivos de políticas; Verifique que la política esté activa.
  6. POST — Run an active scan against a verified domain. La verificación activa Supabase Row-Level Security escribe en una pequeña fila de semillas usando la tecla anónima e informa si la escritura se realizó correctamente: i.e. RLS en realidad no está haciendo cumplir.

Autenticación y sesiones (7 artículos)

Los errores de autenticación en aplicaciones codificadas con AI- tienden a ser sutiles: un error uno por uno en la verificación del token, un indicador HttpOnly perdido, un getSession() donde debería haber un getUser().

  1. PRE — Replace getSession() with getUser(). getSession() lee la cookie y confía en ella; getUser() verifica con el backend Supabase. En las rutas del servidor utilice siempre getUser().
  2. PRE — Confirm token expiry. Los tokens de enlace mágico, restablecimiento de contraseña y verificación de correo electrónico necesitan una caducidad impuesta por el servidor. Los enlaces mágicos Supabase predeterminados caducan después de 1 hora; no lo anule a un número mayor sin una razón real.
  3. PRE — Verify JWT aud and exp. Si decodifica tokens manualmente en cualquier lugar, verifique ambas afirmaciones. Mejor: usa el getUser() del SDK que lo hace por ti.
  4. PRE — Audit cookie flags. Las cookies de sesión personalizadas deben ser Secure; HttpOnly; SameSite=Lax (o Strict para flujos que no sean OAuth). No hay material de sesión en localStorage.
  5. PRE — Validate the next redirect param. El parámetro de consulta next después de iniciar sesión debe comenzar con / y no con // (redireccionamiento abierto a attacker.example). Rechace cualquier otra cosa del lado del servidor.
  6. POST — Test logout. Iniciar sesión, cerrar sesión, inspeccionar las cookies (DevTools → Aplicación → Cookies). La cookie de sesión debe borrarse en la misma respuesta. Si persiste, el controlador de cierre de sesión en realidad no está destruyendo el estado del lado del servidor.
  7. POST — Active probe. Las comprobaciones Auth Flow Defects y Account Enumeration muestran límites de autenticación rotos: diferentes respuestas sobre "el usuario existe" frente a "contraseña incorrecta", falta el límite de velocidad al iniciar sesión, tokens de reinicio sin firmar.

HTTP encabezados de seguridad y política de seguridad de contenido (6 elementos)

Los encabezados son el refuerzo más barato de todo el proceso y el que Codegen omite con mayor frecuencia.

  1. PRE — Ship a real CSP. Mínimo: script-src 'nonce-{NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. No 'unsafe-inline' en script-src. Next.js aplica automáticamente el nonce cuando el middleware establece el encabezado de solicitud x-nonce.
  2. PRE — Add the legacy three. X-Content-Type-Options: nosniff, X-Frame-Options: DENY (o confiar solo en CSP frame-ancestors), Strict-Transport-Security: max-age=31536000; includeSubDomains.
  3. PRE — Tighten Referrer-Policy. El valor predeterminado strict-origin-when-cross-origin está bien para la mayoría de las aplicaciones. No envíe unsafe-url ni ningún encabezado.
  4. PRE — Replace Access-Control-Allow-Origin: *. búscalo. Reemplace con una lista de permitidos de origen explícito. En cualquier lugar donde esté * junto a credentials: include, el navegador rechazará la solicitud, pero eso no es una defensa contra un backend mal configurado.
  5. DEPLOY — Verify headers post-deploy. Abra DevTools → Red → haga clic en su documento raíz → pestaña Encabezados. CSP, HSTS, X-Frame-Options, X-Content-Type-Options deben estar presentes. CSP no debe tener 'unsafe-inline' en script-src.
  6. POST — Run HTTP Security Headers. La verificación pasiva del encabezado informa cada encabezado faltante con una guía de corrección de la plataforma de implementación (Vercel vercel.json, Cloudflare Pages _headers, Netlify _headers, Next.js middleware).

Integraciones de terceros y APIs (5 artículos)

Cada script que incluya es una exención CSP y una posible superficie de la cadena de suministro. Trate a terceros como parte de su límite de confianza.

  1. PRE — Reverse-proxy analytics where possible. PostHog, Plausible y Umami admiten el proxy a través de su propio dominio (e.g. /api/posthog). Esto mantiene a connect-src en el mismo origen y sobrevive a los bloqueadores de anuncios.
  2. PRE — CSP-allowlist the rest. Para Google Analytics, Stripe.js, Sentry, Intercom, GTM, etc., agregue los orígenes de cada proveedor a la directiva CSP correspondiente (script-src para cargadores, connect-src para telemetría, frame-src para iframes, img-src para píxeles).
  3. PRE — Use Stripe Checkout, not raw card forms. Stripe El pago es una redirección de nivel superior; no se necesita ninguna entrada CSP para el script. La superficie alojada PCI vive completamente en el dominio de Stripe. Haz el tuyo solo si tienes una buena razón.
  4. PRE — Lock package-lock.json in CI. Ejecute npm ci (no npm install) en compilaciones de producción. Audite las dependencias con npm audit o Snyk antes de cada lanzamiento.
  5. POST — Watch Technology Fingerprinting. El descubrimiento pasivo de la pila tecnológica muestra las versiones de la biblioteca visibles para un rastreador. Si envía un EOL React, jQuery o Bootstrap, FixVibe lo marca y lo vincula a CVE conocidos.

Higiene e infraestructura del despliegue (8 artículos)

La forma de implementar importa tanto como lo que se implementa. Las aplicaciones AI-codificadas se benefician especialmente del refuerzo de implementación explícito.

  1. PRE — Disable x-powered-by. En next.config.js: poweredByHeader: false. Elimina una señal de divulgación de versión gratuita.
  2. PRE — Confirm middleware lives at src/middleware.ts. Con el diseño del directorio src/, Next.js ignora un middleware.ts de nivel raíz. El middleware mal colocado falla silenciosamente al establecer CSP/encabezados de autenticación/límites de velocidad.
  3. PRE — Sanity-check Vercel deployment protection. Prola producción debe ser pública; La vista previa debe estar protegida con contraseña o limitada a los miembros de la organización. Vercel-Specific Exposure informa la superficie.
  4. PRE — Block dotfile and config probes at the edge. Agregue una regla de reescritura o denegación para los patrones /.env, /.git/*, /.aws/*, /.next/trace. Vercel devuelve 403 para muchos de estos de forma predeterminada; verificar por distintos modos.
  5. DEPLOY — Separate environments. Producción, Vista previa, Desarrollo. Cada uno tiene su propio conjunto de secretos. Las claves en vivo nunca llegan a la Vista previa, el modo de prueba Stripe nunca llega a la Producción.
  6. DEPLOY — Enable Vercel Web Application Firewall. Pro y los planes Enterprise incluyen WAF con reglas administradas. Cloudflare Pages tiene el modo de lucha contra robots. Ambos reducen el abuso de los escáneres automáticos y la carga de pulverización de contraseñas.
  7. POST — Verify TLS configuration. SSL Labs o testssl.sh contra su dominio de producción. TLS 1.2 mínimo, prefiera TLS 1.3, sin cifrados débiles, HSTS elegible para precarga.
  8. POST — Confirm health-check endpoints are minimal. A /api/health debería devolver 200 OK sin cuerpo. No haga eco del entorno, no cree hash ni implemente marcas de tiempo sin autenticación.

Monitoreo continuo y reescaneo (4 ítems)

La seguridad no es una auditoría única previa al envío. La deriva ocurre en cada despliegue.

  1. Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT or HTTP file verification. Active scans require Hobby or above, scheduled scans require Pro or Unlimited, and live threat monitoring requires Unlimited.
  2. Schedule passive re-scans on Pro or Unlimited. Choose an available cadence for your verified domain. Scheduled runs share your scan allowance; enable completion notifications and signed webhooks as needed. A scheduled scan observes the app at run time, not continuously.
  3. Wire outbound webhooks. Account → Webhooks → agregue un punto final HTTPS, suscríbase a scan.completed + finding.created + scan.active_api.first_used. Ruta a Slack / Discord / PagerDuty.
  4. Enable live threat monitoring on Unlimited. Periodic certificate, DNS, bundle, and threat-intelligence checks can surface changes between scheduled scans. Coverage and alert timing depend on the signal and successful polling.

Replit Agent

If you build with Replit Agent, also check:

  1. Don't paste keys into the Agent prompt. Add them in Secrets and give the Agent the variable name instead, so the value never appears in generated code or chat history.
  2. Test CORS on the production domain. The preview pane and your deployed URL are different origins. Check your CORS allowlist against the domain users actually load.
  3. Replit Agent sometimes hardcodes test values. El Agente podría generar código con API_URL = 'http://localhost:5000</code>. Antes del envío, reemplácelo con <code>os.environ[API_URL'].

Firebase Studio

If you build with Firebase Studio, also check:

  1. Test-mode rules are temporary by intent, not by default. Test mode lets anyone read and overwrite data. If the generated rule carries a date cutoff, client access stops on that date; if not, the database stays open. Replace test rules before launch either way.
  2. Security rules protect data, not Hosting. Firestore and Storage rules don't govern what Firebase Hosting serves: everything in the public directory is public. Keep exports, backups and admin pages out of it.

Claude Code

If you build with Claude Code, also check:

  1. PRE — Keep personal Claude Code settings out of git. Commit .claude/settings.json for shared project settings, but keep .claude/settings.local.json out of the repo: Claude Code excludes it from git when it creates the file, so check it if you created it by hand. Session history lives in ~/.claude, outside the project (Claude Code docs).
  2. Bash operations are unverified. Claude Code ejecuta comandos bash directamente. git commit -m "fix" es conveniente, pero si el directorio de trabajo tiene un archivo .env y un globo lo incluye, se confirma. Siempre revise git diff --cached antes de que Claude Code se comprometa.

Próximos pasos

¿Quiere conocer el trasfondo educativo sobre por qué son importantes estos elementos? Leer AI-generated code security scanning. ¿Quiere fragmentos de código concretos para cada paso de endurecimiento? Ver How to secure an app built with AI coding tools.

// 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

La checklist de seguridad de vibe coding: 51 ítems antes de enviar · FixVibe