Le hicimos un pentest a nuestro propio SaaS antes de que alguien más lo hiciera

Es fácil decir que un sistema “es seguro”. Es otra cosa distinta someterlo a un intento real de explotación antes de que un cliente — o alguien con peores intenciones — lo haga por ti. Antes de dar por terminado QRCodePeru, hicimos exactamente eso: un ejercicio de seguridad contra nuestra propia aplicación, con foco especial en un tipo de falla que es fácil pasar por alto.

Qué es un IDOR, y por qué es la falla más común en un SaaS multi-tenant

IDOR (Insecure Direct Object Reference) ocurre cuando un sistema confía en que el usuario solo va a pedir sus propios datos, sin verificar del lado del servidor que el recurso solicitado realmente le pertenece. El ejemplo clásico: cambiar un número en la URL (/qr/104 a /qr/105) y ver si el sistema te deja ver o editar un código QR de otra cuenta, solo porque adivinaste el identificador correcto.

En un SaaS multi-tenant como QRCodePeru — donde cada negocio tiene sus propios códigos QR y sus propias analíticas de escaneo — un IDOR no corregido significa que cualquier cuenta podría ver o modificar los datos de otra. Es, probablemente, la falla de seguridad más común y más dañina en este tipo de aplicaciones, precisamente porque no requiere ninguna herramienta sofisticada para explotarla — solo cambiar un número.

Qué hicimos

Probamos sistemáticamente cada endpoint que recibe un identificador de recurso (un QR, una analítica, una configuración de cuenta) intentando acceder a datos que no pertenecían a la cuenta de prueba. Encontramos 7 hallazgos menores — ninguno crítico, pero cada uno una grieta real que, sin corregir, eventualmente alguien más habría encontrado. Los corregimos y volvimos a probar cada uno en vivo antes de considerar el trabajo terminado.

Por qué esto no es un “nice to have”

Es fácil escribir “seguridad primero” en una propuesta comercial. Lo que realmente demuestra que un equipo se lo toma en serio es que pueda mostrar evidencia de haber intentado romper su propio sistema — no solo haber seguido una checklist de buenas prácticas de memoria. En un SaaS que maneja datos de negocios reales (aunque sea “solo” nombres de productos y analíticas de escaneo), la confianza de un cliente en que sus datos están aislados de los de otro cliente no es negociable.

Este mismo criterio — verificar el aislamiento entre cuentas activamente, no solo asumirlo por diseño — es el que aplicamos también en sistemas con datos mucho más sensibles, como nuestra plataforma de RRHH, donde el aislamiento entre empresas cliente además está reforzado con bases de datos físicamente separadas.