Checklist de seguridad antes de lanzar una app hecha con IA

Las herramientas de IA son muy buenas haciendo que una app funcione. Lo que no siempre hacen por su cuenta es que sea segura: suelen optimizar para que la vista previa se vea bien, no para que un desconocido no pueda leer los datos de tus usuarios.

La buena noticia es que la mayoría de los problemas de seguridad en apps hechas con vibe coding se repiten y se pueden revisar con una lista. Esta es la que usamos como punto de partida. No sustituye una auditoría profesional, pero te ayuda a detectar lo más grave antes de compartir el enlace.

1. Ninguna clave secreta en el código del navegador

Todo lo que se ejecuta en el navegador lo puede ver cualquiera. No importa que esté "escondido" en un archivo: si llega al navegador, es público.

Cómo revisarlo:

1. Abre tu app publicada, haz clic derecho → Inspeccionar → pestaña Sources (o Fuentes).
2. Busca en todos los archivos (Ctrl + Shift + F, o Cmd + Option + F en Mac) textos como sk_live, sk-, service_role, secret o private.
3. Revisa también tus variables de entorno: en proyectos con Vite, las que empiezan por VITE_ terminan en el navegador; en Next.js, las que empiezan por NEXT_PUBLIC_.

Qué es normal y qué no:

• La clave pública (anon o publishable) de Supabase o la configuración web de Firebase están pensadas para ir en el navegador. Son seguras solo si las reglas de acceso de tu base de datos están bien hechas (punto 2).
• La clave service_role (o secreta) de Supabase, las claves secretas de Stripe y las de OpenAI u otros proveedores de IA nunca deben estar en el frontend. Van en el servidor: una Edge Function, una función serverless o tu backend.

Si encuentras una clave expuesta: borrarla del código no basta, porque puede seguir en el historial de Git o en copias anteriores. Hay que rotarla: revocarla en el panel del proveedor, crear una nueva y guardarla solo en el servidor.

2. Row Level Security activado en todas las tablas

Si usas Supabase, este es el punto más importante. Con la clave pública, cualquiera puede hacer consultas directas a tu base de datos. Lo único que decide qué puede ver o cambiar cada persona son las políticas de Row Level Security (RLS).

Revisa:

• Que todas las tablas con datos de usuarios tengan RLS activado. El panel de Supabase incluye un asesor de seguridad (Security Advisor) que avisa de tablas sin RLS.
• Que las políticas no sean del tipo "cualquiera puede leer todo" (using (true)) en tablas privadas.
• Que las políticas comparen con el usuario autenticado, por ejemplo auth.uid() = user_id.
• Que las políticas de insert y update también existan y validen el dueño, no solo las de lectura.
• Que los buckets de Storage con archivos privados no estén marcados como públicos.

Prueba práctica: crea dos cuentas de usuario. Con la cuenta B, intenta ver o editar algo de la cuenta A (cambiando un ID en la URL, por ejemplo). Si puedes, hay un problema.

En Firebase, el equivalente son las Security Rules de Firestore y Storage. Si siguen en "modo de prueba", cualquiera puede leer y escribir.

3. Un login que no se pueda saltar

Ocultar un botón no es proteger una función. Si la pantalla de administración solo "no aparece" para usuarios normales, pero la base de datos acepta la petición, cualquiera con un poco de curiosidad puede usarla.

Comprueba:

• Que los permisos (por ejemplo, "es administrador") se verifiquen en la base de datos o en el servidor, no solo en la interfaz.
• Que un usuario no pueda cambiar su propio rol editando su perfil.
• Que el servidor no confíe en un user_id enviado desde el navegador; debe tomarlo de la sesión.
• Que las rutas privadas no muestren datos por un instante antes de redirigir al login.
• Que las URL de redirección de autenticación (en Supabase: Site URL y Redirect URLs) apunten solo a tus dominios reales.

4. Secretos y archivo .env bajo control

• El archivo .env debe estar en .gitignore. Revisa que no esté subido a tu repositorio.
• Si tu repositorio es o fue público, revisa también el historial: un secreto que estuvo en un commit antiguo sigue expuesto.
• Guarda los secretos de producción en el panel de tu hosting (Vercel, Netlify, Render…) o en los secretos de tus Edge Functions, no en el código.
• Usa claves distintas para pruebas y para producción.

5. Límites para que nadie abuse de tu app

Sin límites, alguien puede crear miles de cuentas, enviar miles de mensajes por tu formulario o gastar tu saldo de IA en una tarde.

• Pon un CAPTCHA (como Cloudflare Turnstile o hCaptcha) en registro, login y formularios públicos. Supabase Auth permite activarlo.
• Si tienes funciones que llaman a una API de IA o envían correos, limita cuántas veces por minuto puede usarlas cada usuario.
• Configura límites o alertas de gasto en los paneles de tus proveedores cuando lo ofrezcan.
• Revisa los límites de tasa de la autenticación en tu backend.

6. Validar lo que entra

Nunca confíes solo en la validación del formulario: se puede saltar enviando la petición directamente.

• Define restricciones en la base de datos: campos obligatorios (not null), longitudes máximas, valores permitidos.
• Valida en el servidor los datos que llegan a tus funciones.
• En subidas de archivos, limita tipo y tamaño.
• No muestres contenido de usuarios como HTML sin limpiarlo (en React, cuidado con dangerouslySetInnerHTML).
• Que los mensajes de error para el usuario no muestren detalles internos como consultas SQL o claves.

7. Respaldos que sepas restaurar

La seguridad también es poder recuperarte. Un prompt que borra una tabla o un error al migrar puede costarte todos tus datos.

• Revisa qué respaldos incluye tu plan de base de datos y cada cuánto se hacen.
• Haz además tu propia copia periódica (por ejemplo, con supabase db dump o pg_dump) y guárdala fuera del proveedor.
• Recuerda que los archivos de Storage no siempre van incluidos en el respaldo de la base de datos.
• Prueba restaurar al menos una vez en un proyecto aparte. Un respaldo que nunca restauraste es una suposición.

8. Dependencias al día

Ejecuta npm audit en el proyecto para ver paquetes con vulnerabilidades conocidas, y actualiza las que tengan solución. Hazlo con calma y probando la app después: actualizar todo de golpe también puede romper cosas.

Checklist resumida

1. Ninguna clave secreta en el navegador; las expuestas, rotadas.
2. RLS activado y probado con dos cuentas.
3. Permisos verificados en el servidor, no solo en la interfaz.
4. .env fuera del repositorio y secretos en el hosting.
5. CAPTCHA y límites en lo que cuesta dinero o se puede abusar.
6. Validación en base de datos y servidor.
7. Respaldos propios y una restauración probada.
8. npm audit revisado.

¿Quieres una segunda mirada?

Si algo de esta lista te generó dudas, es buena señal: es mejor encontrarlo tú que un desconocido. En Devonauts hacemos revisiones de seguridad para apps creadas con IA, en Supabase, Firebase y otros backends, y te explicamos cada hallazgo en palabras simples. Conoce nuestro rescate de apps hechas con IA o escríbenos. Si además estás por publicar, revisa cómo pasar de la vista previa a producción.