Cubadebate

Hola mis estimados lectores. En el día de hoy no vamos a empezar con la típica frase de “en la era digital, los datos son el nuevo petróleo”. Eso normalmente ya aburre. Mejor hablemos de algo más incómodo: cada vez que abres una aplicación móvil, pagas con tu tarjeta en un mercado enlínea o ves el clima en tu asistente de voz, hay una conversación invisible entre servidores. Esa conversación usa un idioma llamado API. Y hoy, dos de los dialectos más populares son REST y GraphQL. ¿El problema? Los hemos puesto bonitos por fuera, con manuales de uso, documentación automática y herramientas de prueba, pero por dentro siguen siendo puertas sin cerradura. La ciberseguridad en las API no es un complemento; es el esqueleto. Y si lo ignoramos, no tenemos una brecha, tendremos una verdadera pesadilla.

Suena complicado, pero no lo es. Vamos a usar una analogía simple. Imagina que estás en un restaurante. La aplicación en tu teléfono es el cliente, y la gran computadora de la empresa (el servidor) es la cocina. Para pedir algo, el mesero (la API) toma tu orden y la lleva a la cocina. REST, el primer idioma, es como pedir del menú tradicional: "Quiero una hamburguesa". La cocina te trae la hamburguesa exactamente como viene en el menú, ni más ni menos. Si solo querías el pan y la carne pero el menú incluye papas fritas, te traen las papas igual. Es simple, directo y la cocina no se confunde. El problema es que, en el mundo digital, este sistema tan sencillo se ha vuelto muy peligroso, no por su diseño, sino por la flojera de quienes lo programan.

¿Por qué peligroso? Porque los programadores, para ahorrar tiempo, a menudo le enseñan a la cocina que cuando alguien pide una hamburguesa, no solo envíe la carne y el pan, sino que también envíe la receta secreta, el número de la nevera donde guardan la carne y la llave de la caja registradora. Suena absurdo, pero en el mundo de las aplicaciones pasa todo el tiempo. Le pides a una app tu nombre, y ella sin querer envía también tu dirección, tu número de teléfono y hasta los últimos movimientos de tu tarjeta. El atacante, que es un comensal malicioso, no tiene más que pedir una y otra vez ese plato (un perfil de usuario, por ejemplo) cambiando un número: el 123, el 124, el 125. De repente, tiene la información de miles de personas. Eso se llama, sin muchos rodeos, un tremendo desastre.

Luego llegó el segundo idioma, un tal GraphQL. Este se vendió como la solución mágica. Su gracia es que el cliente (tu aplicación) puede decir exactamente lo que quiere. En lugar de pedir "una hamburguesa" y que le traigan todo el combo, puede decir: "Quiero solo el pan, la carne, y la cebolla". Nada más. Eso suena fantástico porque ahorra trabajo y datos. Pero aquí viene lo terrible: GraphQL permite hacer preguntas anidadas, es decir, preguntas dentro de preguntas. Sería algo así como pedir: "Dame la hamburguesa, y también dame la lista de todas las hamburguesas que pidió la mesa de al lado, y también dame el historial de todas las hamburguesas que se han cocinado hoy en esta cocina".

Para la computadora que está en la cocina, responder esa pregunta es como querer correr un maratón en un segundo. Se sobrecalienta, se colapsa, y deja de funcionar. Lo peor de todo es que el comensal malicioso puede escribir esa orden tan enredada en apenas dos líneas de texto, enviarla desde su teléfono y derrumbar el sistema entero de un banco. Lamentablemente este autor debe decirles que así de frágil es la seguridad cuando no la cuidamos.

El gran error que ha cometido la industria, y que como usuarios normales debemos entender, es que todos asumen que el que pide la comida es buena persona. Los programadores confían en que la aplicación se va a portar bien. Pero en ciberseguridad, eso es un suicidio. Los atacantes no usan cuchillos ni máscaras. Usan las mismas herramientas que tú, solo que las tuercen. Van a probar una y otra vez hasta que la cocina escupa un dato de más.

Un ejemplo real y muy común: imagina que una aplicación te da un número de usuario, digamos el 555. En la dirección web que ves en tu navegador (aunque no la mires) aparece algo así como “/usuario/555”. Si un atacante cambia ese número por 556, y el sistema le devuelve los datos de otra persona, eso es una falla gravísima. Y sin embargo, pasa a diario en aplicaciones de gobierno, de salud y de bancos. ¿Por qué? Porque el programador nunca le dijo a la cocina: "Oye, antes de darle los datos al cliente, verifica que el cliente sea realmente el dueño del número 556".

Otro problema, este más escurridizo, es el de los mensajes de error. Cuando intentas hacer algo que no debes, a veces el sistema te dice: "No tienes permiso para ver este documento". Otras veces, dice: "Este documento no existe". Para un atacante, esa pequeña diferencia es un tesoro. Si le dice "no existe", el atacante sabe que ese número de documento no está registrado y sigue buscando. Si le dice "no tienes permiso", el atacante celebra por dentro: acaba de descubrir que ese documento sí existe y pertenece a alguien importante. Ahora solo le falta robar la contraseña para hacerse con él.

¿Qué podemos hacer como usuarios normales? Muy poco directamente, porque la falla no está en tu celular, está en los servidores de las empresas. Pero podemos exigir, quejarnos y entender las señales de alerta. Por ejemplo, si una aplicación te pide muchos permisos ridículos (una linterna que quiere acceder a tus contactos, un juego que pide tu ubicación exacta) es probable que su conversación con el servidor (su API) sea un desorden y que tus datos terminen en manos equivocadas.

Y si eres dueño de un negocio, gerente o simplemente un ciudadano curioso, esto es lo que deberías reclamar a los técnicos: que las aplicaciones no entreguen más datos de los necesarios, que limiten la cantidad de preguntas que se le pueden hacer al sistema en poco tiempo (así el atacante no puede probar números al azar), y que nunca jamás muestren mensajes de error detallados. Un error debería decir solo "Algo salió mal", no "Fallo en la línea 45 del archivo de configuración de la base de datos".

La historia más escalofriante que puedo contarte no involucra a un hacker genial con capucha negra. Involucra a un programador cansado un viernes por la tarde. Ese programador creó un campo en la base de datos llamado "código_secreto_de_recuperación", y sin darse cuenta lo incluyó en la respuesta de la API. Es decir, cada vez que un usuario pedía su perfil, el sistema le devolvía también su propio código secreto de recuperación. Cualquier atacante que robara una sesión abierta podía cambiar la contraseña al instante. No hubo un ataque sofisticado, hubo un descuido. Y ese descuido se llama “falta de seguridad en las API”.

Ahora, el debate incómodo: REST vs GraphQL. La industria tecnológica ama los bandos. Pero la verdad es que REST es más fácil de asegurar porque es más simple y hay herramientas maduras. Sin embargo, GraphQL permite crear clientes más eficientes y felices. La balanza se decanta por el contexto. Si tu API va a ser consumida por terceros o dispositivos con recursos limitados (IoT, móviles antiguos), REST sigue siendo rey. Si es un frontend moderno que necesita consultas flexibles y tienes un equipo con disciplina de seguridad, GraphQL puede ser viable. Pero sin disciplina, es un desastre.

Para cerrar, no quiero que te vayas con miedo, sino con claridad. Cada vez que una aplicación nueva te pide registrarte, cada vez que conectas un servicio a otro (“iniciar sesión con Google”), hay una API de por medio. Esa API puede ser una puerta blindada o una cortina de ducha. Depende de si la empresa le prestó atención a la seguridad o simplemente quería lanzar su producto rápido. La próxima vez que una aplicación se comporte raro, que se ralentice sin motivo o que te muestre datos que no te corresponden, no lo ignores. Alguien, en algún lugar, está tratando de tener esa conversación silenciosa con los servidores. Y si no estamos atentos, el que contesta al otro lado de la línea no será el mesero, será el ladrón.

Para los equipos técnicos que leen esto (aunque la columna sea para público general, porque sé que muchos developers están en la audiencia): dejen de confiar en la validación del lado del cliente, dejen de exponer esquemas completos en producción y empiecen a tratarlas API como lo que son: la primera línea de defensa, no el último archivo de configuración que revisan antes del release.

La seguridad en las conversaciones entre aplicaciones (REST y GraphQL) no es un tema para ingenieros aburridos. Es el nuevo campo de batalla de tu privacidad. Ahora que sabes que existe, ya no puedes decir que no te avisaron. No subestimes el beso de la muerte silencioso. O lo domésticas tú, o lo domesticará un atacante por ti. Por hoy es todo, recuerda que nos volveremos a encontrar, aquí en #CódigoSeguro, exactamente dentro de siete días. Hasta entonces nos vemos.

Vea además:

La trilogía de la seguridad en el desarrollo: SAST (diseño), DAST (prueba), SCA (procedencia)