Priorización: dónde mirar primero

01Objetivo

Con el mapa de superficie ya construido (módulos 3-4), decidir en qué orden invertir el tiempo limitado de caza. Esta es la habilidad que más separa a un hunter rentable de uno que trabaja mucho y cobra poco.

02Teoría

El error por defecto: probar por orden de descubrimiento

Sin un criterio de priorización, la tendencia natural es probar los endpoints en el orden en que se encontraron. Esto es aleatorio respecto al valor esperado. El criterio correcto combina tres variables:

Valor esperado = Probabilidad de hallazgo × Impacto × (1 / Competencia de otros hunters)

• Probabilidad de hallazgo: funcionalidades nuevas, recién desplegadas o con lógica propia compleja (no librerías estándar bien auditadas) tienen más probabilidad de fallo que código maduro y muy probado.
• Impacto: endpoints que tocan dinero, datos personales, o cambian el estado de otra cuenta (no solo la propia) valen más que endpoints de solo lectura sobre datos públicos.
• Competencia: funcionalidades obvias desde el login (ya miradas por miles de hunters en programas maduros) vs. funcionalidades escondidas 4 clics dentro de un flujo poco usado (exportar datos, cambiar plan de facturación, panel de un rol secundario).

Señales que elevan la prioridad de un endpoint

• IDs secuenciales o predecibles en la URL o en el payload (candidato directo a IDOR).
• Funcionalidad que involucra a dos usuarios o dos roles (compartir, invitar, transferir, delegar) — la lógica de "quién puede hacer qué a quién" es donde más fallos de autorización aparecen.
• Cualquier flujo de dinero o puntos/créditos (carritos, cupones, programas de fidelidad, reembolsos) — la lógica de negocio ad-hoc rara vez está tan probada como la autenticación.
• Funcionalidad añadida recientemente (visible en changelog, en el blog de producto, o en diferencias de recon pasivo respecto a snapshots antiguos de Wayback Machine).
• Integraciones con terceros (SSO, pasarelas de pago, webhooks) — la frontera entre dos sistemas es clásicamente donde se filtran asunciones de confianza equivocadas.

Pensar como el desarrollador, no solo como el atacante

Una señal de prioridad que no es visible en el propio endpoint, sino en el patrón que rodea al equipo que lo construyó:

• Anomalías de nomenclatura. Si toda la API usa userId y de repente un endpoint usa user_id, probablemente lo construyó otro desarrollador o otro equipo — y el control de acceso que existe en el resto de la API no se puede asumir ahí. Una convención de nombres distinta es, en la práctica, una frontera entre dos implementaciones con probabilidades de fallo distintas.
• La funcionalidad nueva junto a la antigua y bien protegida. Si una función madura tiene validaciones sólidas, una función similar añadida hace poco probablemente no las tiene todavía — el equipo de seguridad audita lo antiguo, no lo que se desplegó la semana pasada.
• Diferencias de error entre rutas que deberían comportarse igual. Un mismo 403 pero con estructura JSON distinta entre dos endpoints que acceden al mismo tipo de recurso delata que son dos implementaciones distintas por debajo — y una de las dos puede no tener el mismo control que la otra.

Estas señales no sustituyen al valor esperado del punto anterior, lo afinan: dos endpoints con el mismo impacto potencial no tienen la misma probabilidad de fallo si uno "huele" a código reciente o a un equipo distinto del resto de la app.

Señales que bajan la prioridad (aunque "se vean fáciles")

• Categorías explícitamente marcadas como de baja severidad en la policy (ver módulo 2).
• Funcionalidad estática o de marketing sin estado de usuario.
• Vectores "clásicos" muy cazados (XSS reflejado simple, clickjacking sin impacto demostrado) en programas con años de antigüedad — si fuera tan fácil, ya estaría encontrado.

03Caso real (anonimizado) — VDP de un regulador financiero

En el VDP de un regulador financiero (dominio protegido por Akamai como WAF/CDN de borde), el recon inicial reveló una API pública de datos corporativos con mucha superficie aparente. Antes de invertir tiempo en pruebas automatizadas contra ella, el análisis de priorización llevó a una conclusión importante: cualquier aproximación automatizada (fuzzing, escaneo masivo) iba a ser detectada y bloqueada por Akamai casi de inmediato, haciendo ese camino de bajo valor esperado pese a la superficie grande. La vía de datos vía API quedó aplazada como "Camino A" de baja prioridad, y el esfuerzo se redirigió a pruebas manuales dirigidas sobre superficie más pequeña pero con menos protección perimetral. La decisión de no perseguir el vector más grande y más visible, precisamente porque su defensa perimetral hacía el valor esperado bajo, es priorización real, no evitar trabajo.

04Resumen operativo

1. Prioriza por valor esperado (probabilidad × impacto ÷ competencia), no por orden de descubrimiento.
2. IDs predecibles y flujos entre dos usuarios son las señales de mayor prioridad.
3. Dinero, puntos y cupones casi siempre esconden lógica de negocio mal probada.
4. Una defensa perimetral fuerte (WAF conocido) puede bajar el valor esperado de un vector grande: no insistas solo porque "hay mucha superficie".