Revisión de seguridad de un MVP: qué incluye y cuánto cuesta antes de lanzar

Antes de lanzar un MVP o abrir un piloto con los primeros usuarios, casi todos los equipos se hacen la misma pregunta: ¿merece la pena auditar la seguridad ahora que el producto todavía cambia cada semana? La respuesta corta es que hay una decisión técnica que se toma en las primeras semanas y luego cuesta mucho revertir: cómo se protegen los datos de cada usuario o de cada cliente. Si eso queda mal planteado, se arrastra cuando el producto crece y la corrección es mucho más cara después.

Una revisión de seguridad de un MVP no es un pentesting corporativo encogido. Es un alcance corto y cerrado, pensado para un producto joven, que se centra en lo que más se rompe a esa escala y devuelve una lista priorizada de cosas a corregir, no un catálogo exhaustivo. El objetivo no es documentar cien hallazgos teóricos, sino encontrar los pocos que hoy tienen impacto real y se pueden arreglar esta semana.

Si tu producto pasa por ese momento —lanzamiento, piloto, primera ronda de inversión o due diligence— este artículo explica qué incluye la revisión, en qué se diferencian la caja gris y la caja blanca, cuánto se tarda, qué determina el precio y qué necesitamos para cerrar el presupuesto.

El primer bloque es la autenticación y la gestión de sesiones: cómo entran los usuarios, cómo se mantiene la sesión, qué pasa al cerrarla y cómo se recuperan las credenciales. Aquí entran los sistemas sin contraseña (código por email, acceso con Google) tan habituales en productos nuevos: hay que comprobar que el código de un solo uso no se puede reutilizar ni adivinar y que la sesión se invalida donde debe.

El segundo bloque, y casi siempre el más crítico, es el control de acceso. En un MVP el fallo más común es que un usuario pueda leer o modificar datos de otro cambiando un identificador en la petición: lo que se conoce como IDOR. Lo mismo se aplica al aislamiento entre clientes en un SaaS: si dos negocios comparten backend, hay que verificar que uno no puede alcanzar los datos del otro. Es el tipo de fallo que ninguna herramienta automática detecta bien y que, si llega a producción, es una filtración.

Si el producto usa Supabase o Firebase, la revisión mira específicamente las políticas de seguridad del servicio. En Supabase son las políticas RLS, y un descuido ahí deja la base de datos entera accesible desde el navegador aunque la aplicación parezca correcta. Revisamos esas reglas, qué puede hacer un usuario autenticado frente a uno anónimo y qué endpoints de la API quedan expuestos sin comprobar permisos.

La diferencia está en cuánto acceso damos al equipo y, por tanto, en hasta dónde llega la revisión.

La caja gris trabaja sobre un entorno de pruebas con cuentas de distintos roles y la documentación de los flujos y las APIs, sin acceso al código fuente. Reproduce lo que podría hacer alguien con credenciales reales: mueve datos entre cuentas, prueba los permisos de cada rol y ataca los endpoints como lo haría un usuario malicioso. Es lo que suele encajar en un MVP, porque mide el impacto real sin depender de leer el código.

La caja blanca añade la revisión del código fuente y de la configuración, y localiza fallos de lógica que no se ven desde fuera. Aporta más cuando el código ya es estable o cuando el informe va a acompañar una ronda de inversión, porque demuestra una revisión más profunda. Las dos se pueden combinar en el mismo alcance: habitualmente empezamos por la caja gris y sumamos la blanca si el producto tiene ya una base sólida.

Un producto de este tipo suele tener tres superficies a la vez: la app para el usuario, un panel de administración y la API que comparten las dos. La revisión cubre las tres, porque el fallo casi nunca está en la app sino en la API que confía en lo que le manda el cliente.

En móvil revisamos el almacenamiento local de datos y credenciales, la comunicación con la API y los permisos que pide la aplicación. Da igual que el producto se distribuya como PWA instalable o publicado en Google Play: lo que se prueba es la lógica de la aplicación y sus permisos, no el canal de distribución, así que el alcance es el mismo en ambos escenarios.

Una revisión de MVP se resuelve en pocos días de trabajo efectivo, según el tamaño del producto y el número de servicios conectados. El precio se cierra antes de empezar con un alcance definido por escrito, de forma que no depende del número de hallazgos que aparezcan: sabes lo que pagas antes de que empiece la revisión.

Lo que determina el precio es el alcance, no el producto. Y son cuatro cosas. Cuántas superficies entran: solo la web, o web, móvil, panel y API. Si la revisión es caja gris o caja blanca, porque la segunda añade la lectura del código. Cuántos roles y tipos de usuario hay que probar, porque cada rol abre una combinación de permisos. Y si hay integraciones con terceros —pasarelas de pago, proveedores de identidad, servicios de IA, almacenamiento externo—, porque cada una suma su propio punto de entrada.

El entregable es un informe priorizado: cada hallazgo con su impacto, cómo se reproduce y la corrección concreta, más una sesión con tu equipo para resolver dudas. Y una vuelta de retest tras las correcciones, para confirmar que cada punto queda cerrado y que al arreglarlo no se ha introducido un problema nuevo. La corrección del código la hace tu equipo; nosotros indicamos la causa y la forma de cerrarla, y verificamos el resultado.

Para cerrar el presupuesto necesitamos poca cosa: entender el producto y su arquitectura, saber qué superficies entran, con qué stack está hecho, cuántos roles existen y si habrá acceso a un entorno de pruebas o al código. Con eso se define el alcance y se da un precio cerrado. Si quieres ver cómo se plantea el servicio, está en auditoría de seguridad para MVP y startups.