// docs / security guides / pre-launch SaaS

Checklist de seguridad pre-lanzamiento SaaS: 35+ ítems

Estás a días de lanzar un producto SaaS creado con Cursor, Claude Code, Lovable o Bolt. Esta lista de verificación es una auditoría go/no-go que cubre las superficies de seguridad que las herramientas AI pasan por alto constantemente y que los fundadores que envían rápidamente deben abordar antes de aceptar el dinero del cliente. Ocho secciones, más de 35 elementos, cada una de las cuales se puede resolver en 30 a 90 minutos. Imprímelo, táchalo y despliégalo con confianza.

Cada elemento a continuación es esencial. Verde significa enviado y verificado; rojo significa lanzamiento no resuelto y bloqueado. Para obtener un tutorial más extenso de cada categoría con fragmentos de código y patrones de falla reales, consulte How to secure an app built with AI coding tools y The vibe coding security checklist.

Aislamiento de datos del cliente

En un SaaS multiinquilino, su primer límite de seguridad es el aislamiento de datos. Los datos de cada cliente deben ser inaccesibles para todos los demás clientes y aplicarse en la capa de base de datos, no en la capa de aplicación.

Habilite la seguridad a nivel de fila (RLS) en cada tabla Supabase con ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY;. FORCE evita que el propietario de la tabla la omita.
Para cada política RLS, verifique los alcances del predicado para el usuario u organización autenticado. Ejemplo: CREATE POLICY "users_see_own" ON public.items FOR SELECT USING (auth.uid() = user_id);. Pruebe con una segunda cuenta de usuario para confirmar que los datos permanecen aislados.
Si usa Firebase/Firestore, las reglas deben coincidir con su modelo de inquilino. No utilice allow read, write: if true; ni reglas de prueba con límite de tiempo. Utilice allow read, write: if request.auth.uid == resource.data.owner_uid; o una coincidencia equivalente con ámbito de organización.
Utilice URL firmadas o tokens de corta duración para acceder a archivos, nunca depósitos públicos. Supabase Almacenamiento: establezca ENABLE ROW LEVEL SECURITY en la tabla objects y cree políticas que limiten el acceso a archivos al usuario autenticado. Pruebe las descargas como diferentes usuarios.
En su capa API, cada solicitud debe incluir auth.uid() o el contexto de id-org. Cada consulta de base de datos debe filtrar por ese contexto. Ejemplo: no SELECT * FROM items WHERE id = $1; siempre SELECT * FROM items WHERE id = $1 AND user_id = auth.uid().

Facturación y pago

La integración Stripe es donde la confianza del cliente se une a la seguridad financiera. Una configuración incorrecta aquí significa pagos robados, bucles de reembolso o ingresos faltantes.

Utilice live Stripe keys en producción. Pruebe con una tecla de modo de prueba separada en la preparación. Nunca cambie el interruptor de prueba a vivo sin una exploración final en modo vivo.
Verifique la firma del webhook en cada evento entrante: const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);. Tirar si falla la firma. Almacene el secreto del webhook solo en una variable de entorno, nunca en código.
Implemente la idempotencia en los controladores de webhooks utilizando una tabla de base de datos con la clave event.id. Si el mismo webhook llega dos veces (lo hará), la segunda ejecución no será operativa. Escriba la fila de idempotencia en la misma transacción que el cambio de estado.
El customer.subscription.updated y customer.subscription.deleted, revoca inmediatamente el acceso. No esperes un cron. Pruebe cancelando una suscripción en Stripe Dashboard y verificando que el usuario esté bloqueado en 5 segundos.
Almacene solo el cliente Stripe ID y la suscripción ID en su base de datos, nunca la tarjeta completa o la clave API. Recupere el estado de suscripción en vivo de Stripe en cada límite de autenticación (carga de página, llamada API, verificación cron). No almacene en caché el estado de la suscripción durante más de 1 minuto.

Autenticación y sesiones

La autenticación es el objetivo de los atacantes de segundo orden en SaaS. Una cuenta de usuario es un vector de datos y métodos de pago.

Utilice supabase.auth.getUser() en cada ruta protegida, nunca getSession(). getSession() lee una cookie no verificada; getUser() valida el lado del servidor JWT. En Next.js: const { data: { user } } = await supabase.auth.getUser(); antes de publicar contenido protegido.
Configure SameSite=Lax en las cookies de autenticación (Supabase Auth hace esto de forma predeterminada). Verifique en DevTools → Aplicación → Cookies. Si ve SameSite=None, agregue sameSite: 'Lax' a la configuración de su sesión.
Habilite MFA en su propia cuenta de administrador. Para el usuario MFA, pruébelo de un extremo a otro antes del lanzamiento: regístrese, inscriba un dispositivo TOTP, cierre sesión, vuelva a iniciar sesión con el token TOTP, verifique que funciona.
Los tokens Magic-link deben caducar en 15 minutos. Los tokens de restablecimiento de contraseña deben caducar en 1 hora. Los tokens de sesión (JWTs) pueden durar más (24 horas a 7 días), pero deben validarse en cada uso. Verifique los valores predeterminados de su proveedor de autenticación.
Pruebe la integridad del cierre de sesión: después de que un usuario hace clic en cerrar sesión, el navegador elimina la sesión de autenticación, el servidor revoca cualquier token y el usuario no puede acceder a las páginas protegidas. En Supabase: llame a await supabase.auth.signOut() y verifique que JWT ya no sea válido en la siguiente solicitud.

PII y cumplimiento

Si recopila correo electrónico, nombre, información de pago o cualquier PII, tiene obligaciones legales: minimización de datos, almacenamiento seguro, eliminación a pedido y preparación para DPA.

Redactar y publicar una política de privacidad (no opcional, incluso para SaaS independiente). Indique qué datos recopila, por qué, durante cuánto tiempo los conserva y los derechos del usuario (acceso, rectificación, supresión). Utilice una plantilla de Termly o similar, pero personalícela.
Implemente un punto final de eliminación de cuenta API que purgue a PII de la base de datos. Pruébelo: cree una cuenta, agregue datos, elimine la cuenta, verifique que los datos hayan desaparecido (use la inspección directa de la base de datos).
Para cumplir con GDPR / CCPA, responder a las solicitudes de los interesados (acceso/corrección/eliminación) dentro de los 30 días. Documente su proceso. Si su aplicación está basada en EU- o sirve a EU usuarios, se requiere un Anexo de acceso de datos Pro (DPA) con Stripe, Supabase y cualquier procesador.
Cifre los campos confidenciales en reposo (su proveedor de autenticación aplica hash a las contraseñas; pero la tokenización de tarjetas de crédito, las claves API y los secretos deben usar pgcrypto o una bóveda externa). Nunca almacene números de tarjetas de crédito en texto plano (use la tokenización Stripe en su lugar).

Preparación operativa

La seguridad es continua. La respuesta a incidentes, el seguimiento y los runbooks comienzan antes del primer día.

Configure una página de estado (Statuspage.io, Uptime Robot o un simple index.html). Los clientes necesitan saber si hay un apagón. Actualízalo en cada incidente.
Tener una rotación de guardia documentada y probada. ¿Quién se despierta con una alerta a las 2 a. m.? ¿Quién tiene claves de implementación? ¿Quién puede revocar un token comprometido? Documentarlo y realizar un simulacro de incendio antes del lanzamiento.
Escriba un manual de respuesta a incidentes de seguridad: qué hacer si un cliente informa una infracción, si pierde una clave, si un servicio deja de funcionar. Distribúyelo a tu equipo. Pruebe un escenario (e.g., simule una fuga de claves) para verificar que el plan funcione.
Los procedimientos de copia de seguridad y restauración deben ser probados, no teóricos. ¿Puedes restaurar desde copias de seguridad? Calcula el tiempo. Supabase: habilite copias de seguridad automatizadas (retención de 7 días gratis, 30 días pago). Pruebe una restauración en un proyecto independiente trimestralmente.
Habilite el registro de auditoría para operaciones privilegiadas: Stripe inicios de sesión en el panel, Supabase administrador API llamadas, cambios en el esquema de la base de datos, conciliación de pagos. Herramientas: CloudTrail (AWS), Supabase registros de auditoría, extensión PostgreSQL pgaudit.

Superficie de ataque externa

Su límite API está bajo constante escaneo de atacantes. Ciérrelo antes de que llegue tráfico malicioso.

Limite la velocidad de cada punto final público. Ejemplo: 100 solicitudes por minuto por IP al registrarse, 10 por minuto al restablecer la contraseña. Utilice Vercel KV, Redis o similar. Falle con 429 (Demasiadas solicitudes).
Agregue CAPTCHA (hCaptcha o reCAPTCHA) para registrarse y restablecer contraseñas en los puntos finales para derrotar a los bots. Verifique el lado del servidor del token antes de aceptar la solicitud.
Utilice un WAF (Firewall de aplicaciones web) si está disponible: Cloudflare, Vercel Firewall de aplicaciones web o AWS WAF. Bloquee IP y patrones maliciosos conocidos automáticamente.
Busque puntos finales API abiertos. Ejecute un escaneo pasivo FixVibe en su dominio de producción mensualmente. Revise los hallazgos para detectar rutas de depuración expuestas, introspección GraphQL, fuga de claves API o exposición de configuración.
Rotar las credenciales (API claves, OAuth tokens, contraseñas de bases de datos) trimestralmente. Documente el procedimiento de rotación y automatícelo cuando sea posible.

Observabilidad y registro

Cuando las cosas van mal, los registros son su registro forense. Configúrelos desde el primer día.

Centralice registros: registros Supabase, registros Vercel, registros de aplicaciones y registros de autenticación en un único panel (Datadog, LogRocket o ELK autohospedado). Se puede buscar y se conserva durante al menos 90 días.
Alerta sobre eventos de seguridad: inicios de sesión fallidos repetidos (posible apropiación de cuenta), uso inusual de API (posible raspado), picos de errores (posible ataque o incidente legítimo). Establece umbrales e integraciones de Slack.
Emita registros de auditoría para cada operación privilegiada: cambios de roles de usuario, creación de nuevas cuentas de administrador, adiciones de métodos de pago, cambios de alcance en claves API. Guárdelos por separado de los registros de aplicaciones con retención inmutable.

Verificación final

Antes de anunciar, ejecute un análisis FixVibe completo y revise los hallazgos con un ojo de seguridad.

Ejecute un análisis activo FixVibe Pro en su dominio de producción. Configure su dominio para pruebas activas (DNS TXT o HTTP verificación de archivos). Autorice la exploración y revise todos los hallazgos, especialmente los críticos y de alta gravedad. Corrija o acepte cada uno explícitamente.
Habilite los nuevos análisis programados: Pro plan → 3 h, 6 h, 12 h o diariamente. Plan Unlimited → 6h, 12h, diario, cada 2 días o semanal. Emparéjelo con comprobaciones active IDOR walking, SQL injection y reflected XSS en su dominio verificado.
Configure webhooks: conecte FixVibe a Slack o envíe un correo electrónico para que los hallazgos críticos activen alertas en tiempo real. Consulte /docs/webhooks para la configuración.
Realice una revisión manual final del código centrándose en los errores de /docs/security-guides/ai-generated-code-security-scanner: secretos en paquetes, RLS/rules, límites de autenticación, CSP, ubicación del middleware. Utilice vibe coding security checklist como plantilla de revisión.

Día de lanzamiento

Has borrado la lista de verificación. Implemente con confianza. Después del lanzamiento, supervise activamente: verifique los hallazgos de FixVibe diariamente durante la primera semana, responda a las alertas dentro de 1 hora y mantenga en ejecución el programa de análisis. Para obtener una guía de refuerzo paso a paso con fragmentos de código, consulte How to secure an app built with AI coding tools.