OWASP-Style Web Vulnerabilities, Explained
Bug bounty hunting is mostly pattern recognition: the same fifteen or so vulnerability classes resurface across almost every web application, dressed up differently each time. This is the plain-English map — what each class is, where it tends to show up, and why it's worth your time.
🔓 IDOR / BOLA
You access another user's data just by changing an ID in the request — /api/invoices/1001 becomes /api/invoices/1002, and you're looking at someone else's invoice. It shows up anywhere a resource is addressed by an ID: orders, files, tickets, messages, projects.
Where it shows up: Test it with two accounts: create a resource with account A, capture the request, replay it as account B.
👑 Broken Access Control
Same family as IDOR, one level up: you can call an action your role shouldn't allow at all, not just read someone else's data. A normal user hitting an admin-only endpoint and having it actually work.
Where it shows up: Admin panels, team/workspace management, billing and permission settings are the classic places it hides.
🔐 Account Takeover
Any flaw that lets you seize control of someone else's account — usually through password reset, email change, OTP verification or session handling gone wrong. It's consistently one of the highest-value bug classes.
Where it shows up: Look at every 'edge path' in an auth flow: expired tokens, reused tokens, changing email without confirmation, alternate recovery routes.
🧾 JWT Vulnerabilities
JWTs used for auth carry their own class of bugs: tokens that don't expire, remain valid after logout or password change, or accept alg: none — meaning the signature check can be skipped entirely.
Where it shows up: Decode any JWT you get and check what happens if you tamper with role, expiry or algorithm.
📦 File Upload Vulnerabilities
Uploading a file that the server or a victim's browser later executes — an SVG with embedded JavaScript, an HTML file served from a trusted origin, a double extension that slips past a naive filter.
Where it shows up: Avatars, attachments, CSV imports and support tickets are the usual entry points.
🌍 SSRF
You make the server itself issue a request to a URL you control. Anywhere an app fetches a URL on your behalf — image import, webhook, link preview, PDF generator — is a candidate.
Where it shows up: A safe first test: point it at your own domain via Burp Collaborator and see if a request lands.
🧬 GraphQL Misconfiguration
GraphQL endpoints often ship with introspection wide open, exposing the entire schema, or with mutations that skip the authorization checks their REST equivalents would have.
Where it shows up: Look for /graphql, /gql; a simple { __schema { types { name } } } query tells you a lot.
🛒 Price Manipulation
Tampering with price, quantity, discount or plan fields from the client side, and having the backend simply trust them instead of recalculating server-side.
Where it shows up: Carts, checkouts, coupon codes and subscription plans are the classic targets.
📩 Email / OTP Verification Bypass
Skipping an email, SMS or OTP check entirely — an empty code that's accepted, a code for one account reused against another, no rate limit on attempts.
Where it shows up: Signup, login, 2FA, password reset and email/phone changes all rely on this kind of check.
🧑💼 Privilege Escalation
A normal user ending up with admin-level permissions — often by replaying an admin-only role-change request with their own session, or editing a hidden role field the client wasn't supposed to touch.
Where it shows up: Team/workspace management and permission settings are where this tends to live.
🗂️ Directory Traversal / LFI
Reading files the application never meant to expose, by manipulating a file=/path= parameter with relative paths like ../../../../etc/passwd.
Where it shows up: Download and document-export endpoints are the usual suspects.
🔎 Sensitive Data Exposure
The API quietly returns more than the UI shows — internal notes, roles, tokens, billing details sitting in a JSON response nobody bothered to trim.
Where it shows up: Always read the full response body, not just what renders on screen.
🧨 Race Condition
Firing a one-time action many times in parallel, before the backend has a chance to update its state — redeeming a coupon twice, claiming a reward more than once.
Where it shows up: Anything tied to a limited resource — stock, credits, votes, gift cards — is worth racing.
🧷 CORS Misconfiguration
An authenticated endpoint that reflects an arbitrary Origin header back in Access-Control-Allow-Origin while also allowing credentials — letting any external site read the victim's private data.
Where it shows up: Add Origin: https://evil.com to an authenticated request and check the response headers.
🔁 CSRF
Tricking an authenticated victim's browser into firing a sensitive request without their consent — changing an email, adding a payment method, deleting an account.
Where it shows up: Check whether the action requires a CSRF token at all, and whether cookies are SameSite-protected.
Cazar en bug bounty es, sobre todo, reconocer patrones: las mismas quince y pico familias de vulnerabilidad reaparecen en casi cualquier aplicación web, disfrazadas de forma distinta cada vez. Este es el mapa en cristiano — qué es cada familia, dónde suele aparecer, y por qué merece la pena.
🔓 IDOR / BOLA
Accedes a los datos de otro usuario cambiando un ID en la petición — /api/invoices/1001 pasa a /api/invoices/1002 y estás viendo una factura ajena. Aparece en cualquier sitio donde un recurso se referencia por ID: pedidos, archivos, tickets, mensajes, proyectos.
Dónde buscar: Se prueba con dos cuentas: creas un recurso con la cuenta A, capturas la petición, y la repites con la cuenta B.
👑 Broken Access Control
Misma familia que IDOR, un nivel más arriba: puedes ejecutar una acción que tu rol no debería permitir, no solo leer datos ajenos. Un usuario normal llamando a un endpoint de admin y que realmente funcione.
Dónde buscar: Paneles de admin, gestión de equipos/workspaces, facturación y configuración de permisos son los sitios clásicos donde se esconde.
🔐 Account Takeover
Cualquier fallo que permita tomar el control de la cuenta de otro — normalmente vía recuperación de contraseña, cambio de email, verificación OTP o gestión de sesiones mal hecha. Es, de forma constante, una de las categorías de más valor.
Dónde buscar: Revisa cada 'camino alternativo' de un flujo de autenticación: tokens caducados, tokens reutilizables, cambio de email sin confirmar, rutas de recuperación secundarias.
🧾 JWT Vulnerabilities
Los JWT usados para autenticación traen su propia familia de fallos: tokens que no caducan, que siguen siendo válidos tras logout o cambio de contraseña, o que aceptan alg: none — es decir, se puede saltar la verificación de firma entera.
Dónde buscar: Decodifica cualquier JWT que consigas y comprueba qué pasa si manipulas el rol, la caducidad o el algoritmo.
📦 File Upload Vulnerabilities
Subir un archivo que el servidor o el navegador de una víctima acaba ejecutando — un SVG con JavaScript embebido, un HTML servido desde un dominio de confianza, una doble extensión que se cuela por un filtro ingenuo.
Dónde buscar: Avatares, adjuntos, importación de CSV y tickets de soporte son los puntos de entrada habituales.
🌍 SSRF
Consigues que el propio servidor haga una petición a una URL que tú controlas. Cualquier sitio donde la app recupera una URL en tu nombre — importar imagen, webhook, vista previa de enlace, generador de PDF — es candidato.
Dónde buscar: Una primera prueba segura: apunta a tu propio dominio vía Burp Collaborator y comprueba si llega la petición.
🧬 GraphQL Misconfiguration
Los endpoints GraphQL suelen llegar a producción con introspection abierta, exponiendo el schema entero, o con mutations que se saltan las comprobaciones de autorización que sí tendría su equivalente REST.
Dónde buscar: Busca /graphql, /gql; una query simple como { __schema { types { name } } } ya dice mucho.
🛒 Price Manipulation
Manipular precio, cantidad, descuento o plan desde el cliente, y que el backend simplemente confíe en esos valores en vez de recalcularlos en servidor.
Dónde buscar: Carritos, checkouts, cupones y planes de suscripción son los objetivos clásicos.
📩 Email / OTP Verification Bypass
Saltarse por completo una verificación de email, SMS u OTP — un código vacío que se acepta, un código de una cuenta reutilizado en otra, sin límite de intentos.
Dónde buscar: Registro, login, 2FA, recuperación de contraseña y cambio de email/teléfono dependen todos de este tipo de comprobación.
🧑💼 Privilege Escalation
Un usuario normal termina con permisos de admin — a menudo repitiendo una petición de cambio de rol pensada para admins con su propia sesión, o editando un campo role oculto que el cliente no debería poder tocar.
Dónde buscar: La gestión de equipos/workspaces y la configuración de permisos son donde suele vivir.
🗂️ Directory Traversal / LFI
Leer archivos que la aplicación nunca quiso exponer, manipulando un parámetro file=/path= con rutas relativas como ../../../../etc/passwd.
Dónde buscar: Los endpoints de descarga y exportación de documentos son los sospechosos habituales.
🔎 Sensitive Data Exposure
La API devuelve calladamente más de lo que muestra la interfaz — notas internas, roles, tokens, datos de facturación en un JSON que nadie se molestó en recortar.
Dónde buscar: Lee siempre el cuerpo completo de la respuesta, no solo lo que se renderiza en pantalla.
🧨 Race Condition
Disparar en paralelo una acción de un solo uso, antes de que el backend actualice su estado — canjear un cupón dos veces, reclamar una recompensa más de una vez.
Dónde buscar: Cualquier cosa ligada a un recurso limitado — stock, créditos, votos, gift cards — merece probarse en carrera.
🧷 CORS Misconfiguration
Un endpoint autenticado que refleja cualquier cabecera Origin en Access-Control-Allow-Origin y encima permite credenciales — dejando que cualquier web externa lea los datos privados de la víctima.
Dónde buscar: Añade Origin: https://evil.com a una petición autenticada y revisa las cabeceras de la respuesta.
🔁 CSRF
Engañar al navegador de una víctima autenticada para que dispare una petición sensible sin su consentimiento — cambiar un email, añadir un método de pago, borrar una cuenta.
Dónde buscar: Comprueba si la acción exige token CSRF y si las cookies llevan protección SameSite.