Datos de clientes accesibles: la prueba de dos minutos en una aplicación creada por IA

Tu aplicación muestra una pantalla de acceso, por tanto tus datos de clientes están protegidos. Los proveedores que reparan estas aplicaciones describen lo contrario en tres muestras diferentes. Tres comprobaciones que puedes hacer esta noche y tres preguntas para quien construye.

Un proveedor que repara aplicaciones no-code escribe en Reddit (r/lovable, julio de 2026) que aproximadamente un tercio de las que ha revisado deja sus datos de clientes accesibles a cualquier visitante, y que tarda dos minutos en comprobarlo. Tu aplicación creada por IA muestra una pantalla de acceso; eso no dice nada sobre lo que protege la base de datos.

Lo que ven quienes reparan estas aplicaciones

Dos proveedores que viven de reparar aplicaciones no-code describen el mismo fallo. El primero dice haber salvado más de treinta en un año (r/nocode, junio de 2026) y no haber encontrado ninguna que proteja todos sus tipos de datos: siempre queda uno abierto durante la construcción y nunca cerrado. El segundo, que revisa aplicaciones de Lovable, cuenta aproximadamente un tercio cuya base responde a quien la solicita (r/lovable, julio de 2026). Un comentarista de Hacker News que dice auditar este tipo de sitios a diario añade haber encontrado al menos treinta claves de acceso en texto claro (febrero de 2026). Estas tres voces venden un servicio de seguridad: sus cifras describen a su clientela, no a todo el mercado. Aun así, se refieren a tres muestras distintas y cuentan lo mismo.

La pantalla de acceso no protege nada

Tu aplicación tiene una interfaz por un lado y una base de datos por otro. La interfaz decide lo que aparece en pantalla; la base decide lo que sale cuando se le pide. Si nadie ha escrito reglas tabla por tabla (quién tiene derecho a leer los clientes y quién a leer los pedidos), la base responde igual a cualquier petición y la pantalla sigue pareciendo normal. Una aplicación puede, por tanto, funcionar durante meses, cobrar pagos y servir a usuarios reales mientras la puerta trasera permanece abierta. La seguridad se decide en la base, tabla por tabla, y la pantalla no puede compensarla.

Tres comprobaciones que puedes hacer esta noche

La primera: abre la dirección pública de tu aplicación en una ventana de navegación privada, sin iniciar sesión, y anota cada página que muestre algo real (una lista, una ficha de cliente, un panel o una página de ajustes). La segunda: crea dos cuentas de prueba con direcciones distintas, introduce un dato reconocible en cada una y después comprueba desde la primera que no aparece nada de la segunda en ninguna parte, incluidas búsquedas y exportaciones. La tercera: solicita una exportación de tus datos desde una cuenta normal y lee lo que contiene; una exportación más generosa que la cuenta que la pidió señala una regla ausente. Estas tres acciones se hacen en tu propia aplicación, en un cuarto de hora y sin instalar nada.

Tres preguntas para quien construye

Se plantean en francés, a una agencia, a un freelance o al equipo de agentes que trabaja para ti. Una: ¿cada tabla de mi base tiene su propia regla de acceso escrita y cuál es? Dos: cuando una cuenta reclama un dato que no le pertenece, ¿qué responde el servidor y qué prueba lo demuestra? Tres: ¿qué impide que un visitante de la demostración escriba en la base que sirve a mis clientes reales? Una respuesta que tranquiliza sin nombrar una sola regla equivale a no responder y merece que se vuelva a preguntar por escrito. Observa que estas preguntas se hacen en francés corriente: exigen un interlocutor que acepte responder con claridad, como ya muestran las cinco trampas del desarrollo con IA.

Lo que cambia una metodología y lo que no cambia

En Maestro, los permisos de acceso se deciden en el documento de requisitos, antes de construir: quién ve qué, quién modifica qué y a qué puede acceder un visitante sin sesión iniciada. Marcel divide después el trabajo en etapas y Félix escribe las pruebas de cada etapa antes de que exista una línea de código, lo que obliga a formular expresamente la regla de acceso en lugar de darla por supuesta. Ninguna de estas protecciones vuelve invulnerable una aplicación, y nosotros no estamos en posición de afirmarlo: un probador de la beta encontró en agosto una clave de base de datos visible en nuestro propio código, corregida desde entonces. Una metodología reduce el número de lugares donde falta la regla. No sustituye la revisión de alguien que se dedica profesionalmente a la seguridad.

En la práctica

Haz esta noche las tres comprobaciones en tu aplicación en producción, por orden, y escribe en una hoja lo que encuentres. Si alguna te preocupa, corta el acceso público mientras entiendes el problema: una aplicación fuera de línea durante dos días cuesta menos que un archivo de clientes circulando. Si todavía estás construyendo, añade la línea «quién tiene derecho a leer qué» a tu documento de requisitos antes de la primera etapa de construcción y mantenla a la vista en cada validación. Nuestra página Tus datos detalla dónde viven los tuyos cuando trabajas con Maestro.