Lanzar rápido está bien, pero hay una lista corta de cosas que conviene revisar antes de abrir tu app al mundo. Ninguna requiere ser experto en seguridad, y todas se comprueban desde fuera en un par de minutos. Esto es lo que de verdad importa, por qué afecta cada punto y cómo arreglarlo.
Cómo los encuentra un atacante en minutos
La mayoría de brechas en apps hechas con IA no son hackeos ingeniosos. Alguien abre tu web, pulsa F12, lee el JavaScript que tu app ya envió a su navegador y copia una URL que tu app ya llama. Los escáneres automáticos hacen lo mismo a escala, probando rutas comunes como /.env o /.git en miles de sitios al día. Todo lo de abajo es algo que pueden comprobar sin ningún acceso a tu código, y por eso deberías comprobarlo tú primero.
1. Nada de secretos en el frontend
Las claves de API y los tokens van solo en el servidor. Cuando una IA "conecta" un servicio, a menudo mete la clave directamente en el código del cliente, donde cualquiera la lee en las DevTools. Una clave de Stripe sk_live_ filtrada puede mover dinero real; una service_role de Supabase entrega toda tu base de datos. Guarda las claves secretas en variables de entorno del servidor y expón solo las públicas pensadas para el navegador. Mira los secretos que tu app filtra en el navegador.
2. HTTPS y cabeceras de seguridad
Sirve todo por HTTPS y redirige HTTP hacia él, para que nadie pueda leer ni manipular el tráfico. Luego añade las cabeceras que el navegador usa para defender a tus usuarios: Content-Security-Policy para contener inyecciones, Strict-Transport-Security para fijar el HTTPS y X-Frame-Options para bloquear el clickjacking. La mayoría de apps generadas salen sin ninguna por defecto. Mira las cabeceras de seguridad HTTP explicadas.
3. Reglas de base de datos (RLS) en cada tabla
Si usas Supabase o Firebase, tu app habla con la base de datos directamente desde el navegador, así que las reglas de la base de datos son lo único que separa a un visitante de tus datos. Activa Row-Level Security en todas las tablas (no solo en las importantes) con una política de denegar por defecto, y nunca confíes en ocultar un botón en la interfaz. Sin eso, cualquiera con la clave pública lee y escribe tus tablas sin iniciar sesión: justo el fallo detrás de la vulnerabilidad RLS de Lovable.
4. Sin archivos sensibles expuestos
Asegúrate de que .env, .git, los backups de la base de datos y los source maps no son accesibles desde un navegador. Es sorprendentemente común: una sola petición a /.env puede entregar todos los secretos que usa tu app, y unos source maps publicados dejan reconstruir tu código original. Bloquéalos en la config de tu host o framework.
5. CORS bien cerrado
Una política CORS permisiva que refleja cualquier origen con credenciales permite que un sitio malicioso lea los datos de tus usuarios usando su sesión. Restringe los orígenes permitidos a los dominios que controlas de verdad, y nunca combines Access-Control-Allow-Origin: * con credenciales.
6. Cookies y sesiones bien configuradas
Las cookies de sesión deben llevar Secure (solo HTTPS), HttpOnly (ilegibles desde JavaScript, para que un XSS no las robe) y SameSite (defiende del CSRF). Estos tres atributos son una línea de configuración y cierran toda una clase de fallos de robo de cuenta.
Tu checklist de 2 minutos antes de lanzar
- Sin
sk_live_,service_roleni claves privadas en tu JavaScript. - HTTPS forzado, con CSP, HSTS y X-Frame-Options puestas.
- Row-Level Security en todas las tablas de la base de datos.
.env,.git, backups y source maps no accesibles.- CORS limitado a tus propios orígenes, sin comodín con credenciales.
- Cookies con Secure, HttpOnly y SameSite.
Hazlo de una vez
En vez de revisar todo esto a mano, pasa Scanaris: comprueba estos puntos y unos 40 más en tu web en vivo en 30 segundos, ordena los hallazgos por impacto y te da un prompt listo para pegar para arreglar cada uno con tu IA, antes de que lo encuentre otro.