Cambia un número en la URL de tu panel de cliente. Si al hacerlo ves los datos de otra empresa distinta a la tuya, tienes un IDOR — Insecure Direct Object Reference — y es uno de los fallos más comunes y más graves en aplicaciones con zona de cliente. Un pentest de caja negra nunca lo va a encontrar, porque nunca tiene una cuenta con la que llegar hasta ahí.
Qué es realmente un pentest de caja negra
En un pentest de caja negra (black-box), el auditor empieza sin credenciales, sin documentación interna y sin acceso al código — exactamente como lo vería un atacante externo anónimo que solo conoce tu dominio. Es el enfoque correcto para evaluar el perímetro público de tu web: formularios expuestos, cabeceras de seguridad, configuración TLS, vulnerabilidades conocidas en el CMS o en las librerías que usas, superficie de ataque visible desde fuera.
El problema aparece cuando tu web no es solo un escaparate público. Si tienes una zona de cliente, un panel de administración, o cualquier área que requiera login, el caja negra solo puede probar el formulario de login en sí mismo — fuerza bruta, inyección, gestión de sesión en el intento de acceso. Todo lo que hay detrás del login queda, por definición, fuera de su alcance.
Qué añade un pentest de caja gris
En un pentest de caja gris (grey-box), el auditor recibe una cuenta de usuario normal — la misma que tendría cualquier cliente tuyo dado de alta legítimamente. Con esa cuenta, no busca "entrar" al sistema: busca qué puede hacer una vez dentro que no debería poder hacer. Es la diferencia entre probar la cerradura de la puerta principal y comprobar si, una vez dentro de tu propio piso, puedes abrir también el piso del vecino.
El ejemplo que más se repite: IDOR en el panel de cliente
Imagina un panel donde cada cliente ve sus propias facturas en una URL del tipo panel.tuweb.com/factura.php?id=1042. Si la aplicación solo comprueba que el usuario ha iniciado sesión, pero no comprueba que la factura con id=1042 pertenece realmente a ese usuario, cualquier cliente autenticado puede cambiar el número a id=1043 y ver la factura de otra empresa — con sus importes, sus datos fiscales, y potencialmente el detalle de qué servicios contrata.
// Vista simplificada del fallo típico en factura.php $id = $_GET['id']; $factura = db_query("SELECT * FROM facturas WHERE id = $id"); // falta comprobar: $factura['cliente_id'] == $_SESSION['user_id'] echo render($factura); // se muestra sin verificar propietario
Este fallo no aparece en un análisis de caja negra porque el auditor sin credenciales nunca llega a ver una factura en primer lugar — no tiene sesión iniciada. Solo alguien con una cuenta real de cliente puede detectarlo, precisamente porque necesita comparar "lo que veo con mi cuenta A" contra "lo que consigo ver cambiando el ID hacia la cuenta B".
Control de acceso horizontal y vertical
El IDOR de facturas es un ejemplo de fallo de control de acceso horizontal: un usuario accede a datos de otro usuario del mismo nivel de privilegio. El fallo de control de acceso vertical es distinto y no menos grave: un cliente normal consigue realizar acciones reservadas al administrador — por ejemplo, porque un endpoint de gestión de usuarios comprueba el token de sesión pero no el rol asociado a ese token. Ambos son fallos de lógica de negocio, no vulnerabilidades técnicas de librería, y solo se detectan navegando la aplicación con una cuenta legítima y comparando sistemáticamente qué debería estar permitido frente a qué está realmente permitido.
Qué cubre cada tipo de auditoría
Superficie pública: formularios expuestos, cabeceras de seguridad, configuración TLS/SSL, vulnerabilidades conocidas del CMS y sus plugins, fuerza bruta y gestión de sesión en el propio login. Simula a un atacante anónimo desde fuera.
Todo lo anterior más: IDOR y referencias directas inseguras, control de acceso horizontal entre clientes, control de acceso vertical (escalada de privilegios), fallos de lógica de negocio, exposición de endpoints de API internos que el frontend no muestra pero que siguen siendo accesibles.
Un pentest de caja blanca (white-box), con acceso al código fuente, encuentra fallos que ni siquiera un usuario autenticado puede provocar navegando — pero para la mayoría de pymes con zona de cliente, el salto crítico real es de caja negra a caja gris, no de gris a blanca.
Por qué esto importa más de lo que parece para una pyme
Si tu negocio tiene varios clientes compartiendo la misma plataforma — un SaaS, un portal de gestión, una intranet de proveedores — el escenario de IDOR entre clientes no es una hipótesis académica: es el fallo que, si se explota, expone datos de todos tus clientes a la vez, no solo los tuyos. Es también el tipo de incidente que dispara notificación obligatoria a la AEPD si hay datos personales de por medio, porque afecta a terceros identificables, no solo a tu propia infraestructura.
La pregunta que conviene hacerse antes de contratar un pentest no es solo "¿cuánto cuesta?", sino "¿con qué nivel de acceso va a trabajar el auditor?". Si tu web tiene login y la respuesta es "sin credenciales", estás pagando por una foto parcial de tu superficie de riesgo.
¿Tu zona de cliente ha sido probada con una cuenta real?
En nuestros pentest web trabajamos en modo caja gris cuando la aplicación lo requiere: probamos control de acceso horizontal y vertical entre cuentas, no solo el perímetro público.
Solicitar pentest web →