Hoy cualquiera puede publicar una app en días, y muchas funcionan bien. Lo que casi nadie prueba es lo que no se ve: qué pasa si alguien consulta la base de datos directamente, sin pasar por la pantalla de la app. Para el dueño del negocio, el sistema “se ve bien” y, aun así, los datos de sus clientes pueden estar abiertos.
Cómo se ve el problema (sin tecnicismos)
- La app y la base de datos hablan directo: La llave de acceso viaja dentro de la app instalada. Si la base de datos no tiene reglas por usuario (lo que se llama RLS o reglas de seguridad), esa llave puede leer los datos de todos, no solo los del usuario que inició sesión.
- Hosting compartido: Tu información convive con la de cientos de sitios, con paneles de administración expuestos, software sin actualizar y respaldos que nadie ha probado.
- Código generado con IA y nunca revisado: Se prueba que funcione, no que esté protegido.
- Una sola persona con todas las llaves: Si se va, no sabes qué accesos quedaron abiertos.
Pruébalo tú mismo en 3 preguntas
- ¿Si alguien tuviera la llave que está dentro de la app, qué podría ver?
- ¿Existen reglas de acceso por usuario en la base de datos? ¿Quién las escribió y quién las revisó?
- ¿Dónde está alojado, y quién tiene acceso al servidor además de quien lo programó?
Si la respuesta es “no sé”, no significa que tengas un problema, pero sí que nadie lo ha verificado.
Por qué en Google Workspace es distinto
No porque Google sea mágico, sino porque ahí puedes verificarlo. No hay una llave incrustada en una app que cualquiera pueda extraer: se entra con tu cuenta de Google. El acceso lo ves y lo controlas desde tu consola de administración, y existe un registro de quién entró y quién descargó.
Y lo que Workspace tampoco resuelve solo
Un archivo compartido con “cualquiera con el enlace”, una app de Apps Script publicada con acceso abierto o permisos de edición demasiado amplios exponen tus datos igual. Por eso cada sistema que entregamos lleva configuración de permisos y una revisión de seguridad antes de salir.