En corto
- Empezar con IA no fue el error. Validar rápido y barato es lo que hay que hacer. Lo que cambia el problema es que entren usuarios, datos personales y dinero.
- Lo que estas herramientas generan bien es lo que se ve. Lo que falla está debajo: reglas de acceso a los datos, permisos, validación en el servidor, copias y despliegue.
- El orden manda: primero lo que expone datos o dinero, después lo que impide recuperarse, después lo que impide avanzar y al final el rendimiento.
- Una copia de seguridad que no has restaurado nunca no es una copia, es una casilla marcada.
- Si nadie sabe desplegar, ningún arreglo llega a producción: por eso el despliegue va antes que la velocidad.
- Al final tienes una lista de comprobaciones que puedes hacer tú, con un navegador y el panel de tu proveedor, sin contratar a nadie.
Antes de seguir
No somos abogados ni delegados de protección de datos: somos el equipo de desarrollo que cierra el agujero. Si encuentras datos personales expuestos, las obligaciones que eso genera las tiene que valorar tu asesor, no yo.
¿Por qué mi app hecha con IA falla justo cuando empieza a funcionar?
La demo y la producción no se parecen. En la demo hay tres usuarios y los tres eres tú: nadie pulsa dos veces, nadie sube un archivo de cuarenta megas, nadie paga dos veces el mismo pedido. Todo lo que se ve funciona, porque lo que se ve es justo lo que estas herramientas generan bien.
Lo que falla está debajo: reglas de acceso a los datos, permisos por rol, validación en el servidor, control de errores, copias y despliegue. Nada de eso lo pediste en el prompt, así que nada de eso apareció.
Validar rápido fue lo correcto. Ahora hay gente dentro y toca poner el suelo.
En qué orden hay que arreglar las cosas cuando ya hay usuarios dentro
El orden importa más que la lista, porque con usuarios dentro no puedes pararlo todo. Ordeno por lo que pasa si no lo tocas.
Lo que expone datos o dinero va primero: es lo único que no se deshace. Si tu tabla de clientes es pública, cada día alguien más ha podido copiarla. Después, lo que impide recuperarse: un borrado con copia probada es un susto, y sin copia es el final. Luego, lo que impide avanzar: si nadie sabe desplegar, ningún arreglo llega a producción.
Y al final el rendimiento. Que vaya lenta molesta. Que esté abierta te puede cerrar el negocio.
Cómo saber hoy si mi base de datos está abierta
Muchas aplicaciones generadas con IA hablan con la base de datos directamente desde el navegador. Cuando es así, la seguridad no vive en tu código: vive en las reglas del servidor de datos. En Supabase son las políticas por fila; en Firebase, las reglas de seguridad. Si nunca las tocaste, siguen como las dejó la plantilla.
Compruébalo sin instalar nada. Pulsa F12, abre la pestaña de red y recarga. Copia una de las peticiones que salen hacia tu base de datos y repítela en una ventana de incógnito, sin iniciar sesión. Si contesta con datos, cualquiera puede hacer lo mismo.
Y ojo: la clave pública está hecha para ir en el navegador. Que se vea no es el fallo. El fallo es que detrás no haya reglas que filtren.
¿Qué claves puedo tener expuestas en el navegador sin saberlo?
Hay dos tipos de clave y confundirlas sale caro. Las públicas identifican tu proyecto y están hechas para viajar al navegador. Las secretas se saltan todas las reglas: la de servicio de la base de datos, la privada de la pasarela de pago, la del proveedor de correo, la de la API de IA que uses. Si una acaba en el código que descarga el navegador, quien la copie puede borrarlo todo, cobrar en tu nombre o gastarte el saldo.
Búscalas con Ctrl+U, para ver el código fuente, y Ctrl+F con palabras como secret, service, private o sk_. Repite la búsqueda en el historial del repositorio: quitar una clave en el último cambio no la borra de los anteriores.
Si aparece alguna, no basta con borrarla. Se revoca y se genera otra.
Una copia de seguridad que no has restaurado nunca no es una copia
Tener las copias activadas no significa nada. Lo que cuenta es haber restaurado una entera, en un sitio aparte, y comprobado que los datos estaban completos. Hasta entonces sabes que hay una casilla marcada, no que tienes copias.
Responde hoy a tres preguntas. Qué se copia y cada cuánto. Cuánto historial se guarda, porque un borrado que descubres tres semanas después no se arregla con siete días. Y quién puede borrar esas copias, porque si la misma cuenta que te pueden comprometer también las borra, no hay copia.
Y una cuarta si el proyecto vive dentro de la herramienta que lo generó: cómo sacarías de ahí datos y código.
Nadie sabe desplegar la app y eso bloquea todos los arreglos
Aquí se atascan muchos proyectos: sabes lo que hay que arreglar y no hay forma de subirlo. Pasa cuando solo se despliega desde un botón dentro de la herramienta, cuando el código vive en el portátil de alguien, o cuando hay tres versiones y nadie sabe cuál está online.
Se sale en este orden. El código, en un repositorio a tu nombre. Las claves, en variables de entorno del servidor. El despliegue, automático al confirmar un cambio. Un entorno de pruebas con su propia base de datos, para equivocarte sin romper lo real. Y un registro de errores que te avise, porque enterarte de las caídas por un cliente enfadado no es monitorización.
Va lenta, ¿por qué el rendimiento es lo último que hay que tocar?
Porque la lentitud avisa y los otros tres problemas no. Los usuarios te dicen que va lenta. Una base de datos abierta no dice nada: te enteras cuando tus datos aparecen en otro sitio.
Cuando llega su turno, los culpables suelen ser pocos: consultas que se lanzan una vez por cada fila de una lista, columnas sin índice, imágenes servidas al tamaño original y pantallas que esperan todos los datos antes de pintar nada. Casi nunca hay que reescribir la aplicación para eso.
Lista de comprobaciones que puedes hacer hoy sin contratar a nadie
Ninguna exige programar ni instalar nada: basta un navegador y el panel de tu proveedor. Hazlas en orden y apunta el resultado de cada una: ese documento ya es media auditoría, y sirve igual si lo arreglas tú que si se lo pasas a alguien.
Si falla alguna de las cinco primeras y guardas datos de personas o cobras dinero, eso va antes que todo lo demás.
- Sin iniciar sesión, repite una petición a tu base de datos copiada de la pestaña de red: si devuelve datos, está abierta
- Comprueba que las reglas de acceso están activadas tabla por tabla, no solo en el proyecto
- Cambia el identificador de un pedido en la dirección y mira si ves el de otro usuario
- Busca en el código fuente de la página las palabras secret, service, private y sk_
- Mira si el importe final de un pago se recalcula en el servidor o llega desde el navegador
- Con una cuenta de usuario normal, escribe a mano la dirección de una pantalla de administración
- Revisa el historial del repositorio: las claves que se quitaron siguen estando ahí
- Restaura una copia en un proyecto aparte, comprueba que está completa y mira cuánto historial guarda
- Descarga hoy un volcado de la base de datos y el código a un sitio tuyo
- Comprueba que dominio, hosting, base de datos y pagos están a tu nombre
- Sube un cambio mínimo y anota cuántos pasos y qué personas hacen falta
Preguntas frecuentes
¿Fue un error montar mi aplicación con Lovable, Bolt o v0?+
No. Estas herramientas sirven para llegar rápido a algo que se ve y se toca, y validar la idea antes de gastar un presupuesto entero. El error no es usarlas: es dejar la aplicación tal cual cuando ya hay usuarios reales, datos personales y cobros. Lo que falta añadir después son reglas de acceso a los datos, permisos, validación en el servidor, copias probadas y un despliegue propio.
¿Cómo compruebo yo mismo si mi base de datos está abierta?+
Pulsa F12 en tu aplicación y ve a la pestaña de red. Recarga y localiza las peticiones que salen hacia tu base de datos. Copia una y repítela en una ventana de incógnito, sin iniciar sesión. Si devuelve datos, cualquiera con un navegador puede hacer lo mismo. Después confirma en el panel que las reglas de acceso están activadas tabla por tabla, no solo en el proyecto.
He encontrado una clave secreta en el código de mi web, ¿basta con borrarla?+
No. Una clave que ha estado publicada se da por comprometida: hay que revocarla en el panel del proveedor y generar otra, guardada en variables de entorno del servidor y nunca en el código. Revisa además el historial del repositorio, porque borrarla en el último cambio no la quita de los anteriores, y el consumo del servicio por si hubo uso ajeno.
¿Puedo sacar mi proyecto de la herramienta con la que lo generé?+
En general sí, y conviene hacerlo antes de necesitarlo. Se baja el código a un repositorio a tu nombre, se exporta un volcado completo de la base de datos, se pasan las claves a variables de entorno y se monta el despliegue donde la cuenta sea tuya. Puedes seguir usando la herramienta, pero ya no dependes de que siga existiendo.
Si mi base de datos ha estado abierta con datos de clientes dentro, ¿es solo un problema técnico?+
No, también tiene consecuencias legales. Si guardas nombres, correos, teléfonos, direcciones o documentos, estás tratando datos personales, y un acceso no autorizado se considera un incidente de seguridad con obligaciones para quien responde del tratamiento. Lo urgente es cerrar el acceso, revocar claves y documentar qué datos han podido verse y desde cuándo. En paralelo, consúltalo con quien lleve tu protección de datos.
Si alguna comprobación te ha salido mal, escríbenos
Cuéntanos qué hace la aplicación, con qué se hizo y qué comprobaciones de la lista te han salido mal. Te decimos qué es urgente, qué puede esperar y si compensa arreglarlo o rehacerlo, antes de que gastes un euro más en parches.
Contarme qué está roto