My Real Bug Bounty Workflow (Day by Day)
This is the exact sequence I follow on a target, from picking it to writing the report — not a generic methodology copied from a blog post.
Phase 0 — Picking the right target (this matters more than people think)
Typical mistake: picking whatever program looks interesting and diving in.
What actually works: mid-sized apps — not huge, not tiny — with a login (more attack surface), an API (even better), and complex functionality (payments, teams, sharing). Early on, avoid the giants and the ultra-saturated programs; you'll mostly find what a hundred people already reported.
Phase 1 — Recon (30–60 min)
You're not hacking yet, you're understanding the app: create an account, create a second account (this matters a lot later), and walk through every feature — profile, file uploads, payments, teams, API, messaging. The mental question the whole time is just: how does this application actually work?
Phase 2 — Mapping endpoints
Open Burp and click through login, profile, create/edit/delete/share for every resource type. Save the map: /api/users, /api/projects, /api/orders, /api/files, /api/messages. That list is your attack surface.
Phase 3 — The main attack (this is where the money is)
1. IDOR (always first)
Create a resource with account A, capture the request, switch to account B, replay it with B's session. The question that matters: can I see or modify something that isn't mine?
2. Data exposure
Read the full JSON response, not just what the UI renders — emails, phone numbers, roles, internal IDs. The UI often hides things the API doesn't.
3. XSS (quick pass)
Name, description and comment fields, with a fast payload:
<img src=x onerror=alert(1)>4. API keys / config
Ctrl+U, search for CONFIG, TOKEN, API_KEY.
Phase 4 — Business logic (the pro level)
Very few hunters get here. The question to ask constantly: can I do something I shouldn't be able to? Real examples: changing an email without confirming it, deleting resources without the right permissions, adding yourself to a team without an invite, reusing a coupon multiple times, duplicating a balance.
Phase 5 — Secondary attacks (only if the above turned up nothing)
CSRF, CORS, Open Redirect, file upload.
A worked mini-simulation
Imagine a typical SaaS app. You see GET /api/projects/123 and think: what if I try 124? — that's an IDOR. The JSON response back includes email, role: admin, internal_notes: VIP client — that's a data leak, on top of the IDOR. The project's name field takes
<img src=x onerror=alert(1)>The daily routine
- Pick a target
- Recon (30 min)
- Map the API
- Test IDOR
- Test data leaks
- Test XSS
- Document findings
Don't test everything at random. Fewer targets, more depth.
The mindset that actually wins
Don't hunt for vulnerabilities. Hunt for behavior that feels off.
A realistic ramp-up plan
| Timeframe | Focus |
|---|---|
| Weeks 1–2 | IDOR and data exposure only |
| Week 3 | Add XSS and API leaks |
| Week 4+ | Business logic, SSRF, race conditions |
Esta es la secuencia exacta que sigo con un target, desde elegirlo hasta escribir el reporte — no una metodología genérica copiada de un blog.
Fase 0 — Elegir bien el target (importa más de lo que parece)
Error típico: elegir cualquier programa que parezca interesante y lanzarse.
Lo que funciona de verdad: apps medianas — ni gigantes ni pequeñas — con login (más superficie de ataque), con API (mejor aún), y con funcionalidades complejas (pagos, equipos, compartir). Al principio evita a los gigantes y los programas ultra saturados; sobre todo vas a encontrar lo que ya reportaron cien personas antes.
Fase 1 — Recon (30-60 min)
Aquí todavía no hackeas, entiendes la app: crea una cuenta, crea una segunda cuenta (muy importante más adelante), y recorre toda la app — perfil, subida de archivos, pagos, equipos, API, mensajes. La pregunta mental todo el rato es solo: ¿cómo funciona esta aplicación?
Fase 2 — Mapear endpoints
Abre Burp y navega login, perfil, crear/editar/borrar/compartir para cada tipo de recurso. Guarda el mapa: /api/users, /api/projects, /api/orders, /api/files, /api/messages. Ese listado es tu superficie de ataque.
Fase 3 — Ataque principal (aquí sale el dinero)
1. IDOR (siempre primero)
Crea un recurso con la cuenta A, captura la petición, cambia a la cuenta B, reenvíala con la sesión de B. La pregunta que importa: ¿puedo ver o modificar algo que no es mío?
2. Data exposure
Lee el JSON completo de la respuesta, no solo lo que muestra la interfaz — emails, teléfonos, roles, IDs internos. Muchas veces la UI oculta cosas que la API no.
3. XSS (pasada rápida)
Campos de nombre, descripción y comentarios, con un payload rápido:
<img src=x onerror=alert(1)>4. API keys / config
Ctrl+U, buscar CONFIG, TOKEN, API_KEY.
Fase 4 — Lógica de negocio (el nivel pro)
A este nivel llegan muy pocos hunters. La pregunta a hacerse constantemente: ¿puedo hacer algo que no debería? Ejemplos reales: cambiar un email sin confirmarlo, borrar recursos sin permisos suficientes, añadirme a un equipo sin invitación, reutilizar un cupón varias veces, duplicar un saldo.
Fase 5 — Ataques secundarios (solo si lo anterior no dio nada)
CSRF, CORS, Open Redirect, subida de archivos.
Una mini-simulación resuelta
Imagina una SaaS típica. Ves GET /api/projects/123 y piensas: ¿y si pruebo 124? — eso es un IDOR. La respuesta JSON incluye email, role: admin, internal_notes: VIP client — eso es una fuga de datos, encima del IDOR. El campo nombre del proyecto acepta
<img src=x onerror=alert(1)>La rutina diaria
- Elegir target
- Recon (30 min)
- Mapear la API
- Probar IDOR
- Probar fugas de datos
- Probar XSS
- Documentar hallazgos
No pruebes todo a lo loco. Menos targets, más profundidad.
La mentalidad que de verdad gana
No busques vulnerabilidades. Busca comportamientos raros.
Un plan de progresión realista
| Cuándo | En qué te centras |
|---|---|
| Semanas 1-2 | Solo IDOR y data exposure |
| Semana 3 | Añade XSS y fugas de API |
| Semana 4+ | Lógica de negocio, SSRF, race conditions |