Los riesgos de conectar un frontend directamente a una base de datos

En el desarrollo de software, como en casi todo, el camino más corto entre dos puntos suele ser el que genera más problemas a largo plazo. Uno de los atajos más frecuentes —y más peligrosos— que aparecen en proyectos con presupuestos ajustados o con equipos sin experiencia en arquitectura es conectar la interfaz de usuario directamente a la base de datos, sin una capa intermedia que controle, valide y proteja el acceso a la información.

Para quien no programa, la idea puede sonar razonable: si la aplicación necesita mostrar datos que están en la base de datos, ¿para qué poner algo en el medio? Pero esa capa intermedia —técnicamente llamada backend o API— no es un lujo ni una complejidad innecesaria: es un requisito de seguridad y de integridad. Prescindir de ella es como tener un negocio con una caja registradora abierta al público y confiar en que nadie va a meter la mano.

Este artículo explica, sin jerga técnica, por qué esta arquitectura es peligrosa y cuáles son los riesgos concretos para un negocio.

Cómo funciona la arquitectura insegura

Para entender el riesgo, primero hay que entender qué significa "conectar el frontend a la base de datos".

En una arquitectura bien diseñada, cuando un usuario usa una aplicación —ya sea web o móvil—, la aplicación se comunica con un servidor intermedio. Ese servidor recibe la solicitud, verifica que el usuario tenga permiso para hacer lo que está pidiendo, aplica reglas de negocio, consulta la base de datos, y devuelve únicamente la información que corresponde.

En la arquitectura insegura, ese servidor intermedio no existe. La aplicación del usuario —el frontend— se conecta directamente a la base de datos. Para hacerlo, necesita conocer las credenciales de acceso: dirección del servidor, nombre de la base de datos, usuario y contraseña. Esas credenciales viajan en el código de la aplicación, que está en el teléfono o en el navegador de cada usuario.

El problema fundamental es que todo lo que está del lado del usuario —en su dispositivo, en su navegador— puede ser inspeccionado, modificado y manipulado. No importa qué tan segura parezca la aplicación: si las credenciales de la base de datos están en el código que se ejecuta en el dispositivo del usuario, un atacante con conocimientos básicos puede extraerlas.

Riesgo 1: exposición completa de las credenciales de la base de datos

El primer riesgo es el más directo. Cualquier persona que use la aplicación puede, con herramientas gratuitas y disponibles en internet, inspeccionar el código que se ejecuta en su propio dispositivo y encontrar las credenciales de la base de datos.

Una vez que un atacante tiene esas credenciales, puede conectarse a la base de datos desde cualquier lugar, sin pasar por la aplicación. Desde su propia computadora, sin ningún control, puede:

• Leer toda la información almacenada: datos de clientes, transacciones, precios, información financiera.
• Modificar datos: cambiar precios, alterar saldos, borrar registros.
• Insertar datos falsos o maliciosos.
• En el peor de los casos, borrar la base de datos completa.

Esto no es un escenario teórico. Ocurre con frecuencia en aplicaciones que salen al mercado sin una revisión de seguridad adecuada, y el daño suele descubrirse semanas o meses después, cuando ya se filtró información sensible o se manipularon datos críticos.

Riesgo 2: falta de una capa de validación

La capa intermedia no solo protege el acceso a la base de datos. También valida que los datos que entran al sistema tengan sentido y no sean maliciosos.

Sin esa capa de validación, cualquier usuario de la aplicación —o cualquier atacante que se haya conectado directamente a la base de datos— puede:

• Insertar datos inconsistentes: un precio negativo, una fecha de nacimiento en el año 3000, un correo electrónico sin formato válido. La base de datos va a aceptar esos datos si no hay una capa que los rechace antes.
• Ejecutar código malicioso: si la aplicación permite que los usuarios escriban texto —nombres, comentarios, direcciones—, un atacante puede insertar código en esos campos que, cuando otro usuario los vea, se ejecute en su navegador. Esto se conoce como inyección de código o cross-site scripting, y permite robar sesiones, redirigir a sitios falsos o capturar información que el usuario ingrese.
• Manipular la lógica de negocio: si no hay una capa intermedia que aplique las reglas del negocio, un usuario técnicamente habilidoso podría, por ejemplo, modificar el precio de un producto en el momento de la compra, o marcarse a sí mismo como administrador del sistema.

La capa intermedia actúa como un filtro: todo lo que entra y todo lo que sale del sistema pasa por un punto de control donde se verifican permisos, se validan formatos y se aplican reglas.

Riesgo 3: imposibilidad de controlar quién accede a qué

En un sistema con capa intermedia, los permisos son granulares: el usuario de ventas puede ver los datos de clientes pero no las cuentas bancarias de la empresa; el administrador puede ver todo pero el cliente final solo puede ver su propia información.

Cuando el frontend se conecta directamente a la base de datos, ese control granular es muy difícil de implementar. O bien todos los usuarios comparten las mismas credenciales genéricas y ven exactamente lo mismo, o bien se intenta manejar los permisos desde la base de datos —una configuración compleja, propensa a errores y que requiere conocimientos que la mayoría de los proyectos no tienen—.

El resultado típico es que cualquier persona que pueda conectarse a la base de datos puede ver todo lo que hay en ella. Eso significa que un empleado que accede al sistema con fines legítimos puede, si tiene la curiosidad y los conocimientos técnicos, ver información que no debería estar a su alcance: salarios, márgenes, datos personales de otros clientes.

Riesgo 4: el sistema no puede evolucionar sin romperse

Hay un riesgo menos obvio pero igualmente grave: la rigidez que genera esta arquitectura para el desarrollo futuro.

En un sistema con capa intermedia, la base de datos puede cambiar su estructura interna —renombrar columnas, dividir tablas, migrar datos a un formato nuevo— sin que la aplicación del usuario se entere, porque la capa intermedia traduce entre la nueva estructura y lo que la aplicación espera recibir.

Si la aplicación se conecta directamente a la base de datos, cualquier cambio en la estructura de los datos rompe la aplicación para todos los usuarios hasta que actualicen a una nueva versión. Esto obliga a coordinar las actualizaciones del servidor con las actualizaciones de todos los dispositivos simultáneamente, o a mantener versiones antiguas de la base de datos funcionando en paralelo —una pesadilla operativa que crece con la cantidad de usuarios.

Riesgo 5: ausencia de registro de actividad

La capa intermedia, entre sus muchas funciones, suele implementar un registro de actividad: quién hizo qué, cuándo, desde dónde. Ese registro es fundamental para:

• Detectar accesos no autorizados o patrones sospechosos de uso.
• Auditar operaciones críticas: quién modificó ese precio, quién borró ese cliente, quién cambió esa configuración.
• Cumplir con requisitos regulatorios que exigen trazabilidad de ciertas operaciones.

Cuando la aplicación se conecta directamente a la base de datos, el registro de actividad se limita a lo que la base de datos guarda por defecto —que suele ser poco y técnico—, y cualquier atacante que haya obtenido las credenciales puede borrar sus propias huellas del registro.

Cómo detectar si tu proveedor está usando esta arquitectura

No hace falta saber programar para hacer preguntas que revelen si el equipo está tomando atajos peligrosos:

• "¿Cómo se conecta la aplicación a la base de datos?" Si la respuesta es "directamente" o no menciona un servidor intermedio, hay un problema.
• "¿Las credenciales de la base de datos están en el código de la aplicación?" Si la respuesta es sí, hay un problema serio.
• "¿Qué pasa si alguien inspecciona el código de la aplicación desde su navegador?" Si el proveedor no tiene una respuesta clara y tranquilizadora, conviene investigar más.
• "¿Qué capa de validación tienen entre la aplicación y los datos?" Si no hay una capa intermedia que valide permisos, formato y reglas de negocio, la arquitectura es frágil.

Qué arquitectura deberías esperar de un proveedor serio

La alternativa a esta arquitectura insegura no es compleja de describir en términos de negocio, aunque requiera trabajo técnico implementarla:

1. Una capa intermedia (backend o API) que recibe todas las solicitudes de los usuarios, verifica identidad y permisos, aplica reglas de negocio, y recién entonces consulta o modifica la base de datos.
2. Credenciales de base de datos que nunca salen del servidor. Los usuarios no las ven, no las conocen, no pueden extraerlas de la aplicación.
3. Validación de datos del lado del servidor. Todo dato que ingresa al sistema —venga de donde venga— es verificado antes de ser aceptado.
4. Permisos granulares. Cada tipo de usuario ve y modifica únicamente lo que su rol le permite.
5. Registro de actividad. Toda operación importante queda registrada con información de quién, cuándo y desde dónde.

El artículo sobre qué preguntar sobre seguridad a tu proveedor de software amplía la lista de preguntas técnicas que conviene hacer antes de contratar, para asegurarse de que el proveedor sigue prácticas de desarrollo seguras.

También es relevante entender qué datos de tus clientes deberías proteger, porque una arquitectura insegura no solo expone datos del negocio: expone la información personal de las personas que confiaron en tu empresa.

La decisión de usar una arquitectura con capa intermedia no es un lujo técnico ni una complejidad que pueda posponerse. Es la diferencia entre un sistema donde la seguridad depende de la buena fe de los usuarios y uno donde la seguridad está garantizada por diseño. Y en un contexto donde las filtraciones de datos pueden costar millones en sanciones y pérdida de clientes, esa diferencia no es menor.