Leer un scope y una policy como un cazador

01Objetivo

Aprender a leer la letra pequeña de un programa antes de tocar un solo endpoint, y a elegir programa con criterio en vez de por popularidad.

02Teoría

Anatomía de un scope

Dando por hecho que ya confirmaste el tipo de encargo (módulo 1) — aquí se asume bug bounty puro, donde solo cuenta el impacto demostrado —, un scope real no es solo "dominios incluidos". Tiene capas:

1. In-scope explícito — dominios/apps listados. Ojo a subdominios: *.ejemplo.com no siempre incluye admin.ejemplo.com si está explícitamente excluido más abajo.
2. Out-of-scope explícito — la parte que casi nadie lee entera. Suele excluir: infraestructura de terceros (CDN, pagos, mensajería), endpoints de marketing/landing sin lógica de negocio, y — la trampa más común — categorías enteras de vulnerabilidad (ej. "rate limiting issues", "self-XSS", "clickjacking sin impacto demostrado").
3. Severidad mínima aceptada — algunos programas no pagan/triagean nada por debajo de cierto CVSS o impacto. Perder tiempo en un hallazgo de severidad baja en un programa así es tiempo cero.
4. Categorías "known issues" — algunos programas publican una lista de hallazgos ya conocidos. Reportarlos es duplicado garantizado.

La trampa del out-of-scope "implícito"

La policy nunca lista todo lo que está fuera. Si el scope dice "aplicación web en app.ejemplo.com", un panel interno encontrado en internal.ejemplo.com por accidente de recon no está autorizado aunque pertenezca a la misma empresa. El criterio correcto no es "parece de la misma empresa", es "está en la lista publicada". Si hay duda razonable de que un hallazgo cae en zona gris, se pregunta al programa vía su canal oficial antes de explotar nada, y se reporta igualmente si el impacto es grave (muchos programas agradecen esto aunque técnicamente esté fuera de scope, aunque no paguen por ello).

Elegir programa: criterios reales, no "el que más paga por top"

Mirar la tabla de recompensas máximas de un programa es la forma menos útil de elegir dónde cazar. Criterios que sí predicen resultado:

• Antigüedad del programa. Programas muy maduros (años en plataforma, miles de hunters ya han pasado) tienen la fruta baja ya cazada. Mejor retorno en programas recientes o que han ampliado scope hace poco.
• Complejidad de la superficie, no tamaño. Una app con mucha lógica de negocio propia (checkout, puntos de fidelidad, roles de usuario) rinde más que una app grande pero mayormente estática.
• Ratio de resolución/respuesta del triage (visible en la mayoría de plataformas). Un programa que tarda meses en responder o cierra todo como N/A no es buen uso del tiempo, por bueno que sea el hallazgo.
• Multi-producto bajo un mismo scope. Si el programa cubre varias apps/subdominios con funcionalidades distintas (ej. ecommerce principal + programa de fidelidad + API móvil), hay más superficie con menos ojos por metro cuadrado que en un único dominio muy mirado.

03Caso real (anonimizado) — pivote entre programas de e-commerce

Durante la caza en el programa de una cadena europea de electrónica de consumo, los tres vectores principales trabajados (autenticación, API de pedidos, panel de cliente) resultaron estar ya bien protegidos tras varias rondas de recon y pruebas dirigidas — ninguno de los tres mostró una brecha explotable pese a esfuerzo considerable. En vez de seguir insistiendo sobre el mismo scope con rendimientos decrecientes, la decisión fue pivotar a otro programa de la misma plataforma: un marketplace de moda online con una arquitectura de backend distinta (OXID eShop) y endpoints de API menos auditados, en particular uno de metadatos de usuario con indicios de control de acceso débil, y la gestión de cupones/puntos de fidelidad. El criterio de pivote no fue "este programa es malo", fue: cuando los vectores de más impacto obvio de un scope están todos cerrados, el tiempo marginal rinde más en scope nuevo que insistiendo en el mismo.

Esto se desarrolla con más detalle en el módulo 12.

04Resumen operativo

1. Lee la policy completa, no solo el dominio. El out-of-scope paga tanto como el in-scope.
2. Elige programa por complejidad de lógica de negocio y madurez de triage, no por la tabla de premios.
3. Zona gris de scope → se pregunta, no se asume.
4. Un programa "agotado" en sus vectores obvios es señal de pivotar, no de insistir.