El hacking web es la práctica de atacar aplicaciones y sitios que funcionan sobre HTTP (una tienda online, un banco, una API, un panel de administración) para encontrar sus fallos antes de que lo haga alguien con intenciones distintas, siempre con permiso explícito del dueño del sistema. El pentesting web es la misma actividad con nombre profesional: un test de penetración centrado en la capa de aplicación, con alcance pactado por escrito, un cliente que paga por el servicio y un informe final con hallazgos priorizados. «Web hacking» es la traducción inglesa del mismo oficio, y las tres etiquetas se usan indistintamente en ofertas de trabajo, foros técnicos y programas de certificación.
Esta guía no enseña a explotar cada vulnerabilidad paso a paso. Explica qué es esta rama del hacking ético, en qué se diferencia de otras (pentesting de red, red team, forense, GRC), qué vulnerabilidades busca de verdad un pentest de aplicaciones web y con qué impacto, qué herramientas usa un profesional del sector, cómo es el trabajo día a día y cómo se empieza a practicar de forma legal, con laboratorios gratuitos y programas de bug bounty reales. Si el objetivo es aprender a explotar cada fallo, módulo a módulo y con laboratorio guiado, para eso está nuestro curso de hacking web; esta guía es el paso anterior, pensado para decidir si es la rama que quieres seguir antes de invertir tiempo o dinero en formación.
El marco de referencia que agrupa buena parte de este trabajo es el OWASP Top 10, en su edición 2025, la primera actualización de fondo desde 2021. Se explica más abajo con la lista completa y el impacto de cada categoría, y se desarrolla en profundidad, ejemplo por ejemplo, en nuestro artículo dedicado al OWASP Top 10 2025.
¿Qué es el hacking web?
El hacking web consiste en analizar una aplicación o un sitio construido para funcionar sobre HTTP buscando formas de romper su lógica, saltarse sus controles de acceso o extraer datos que no deberían estar disponibles. Se hace siempre con autorización expresa: fuera de un laboratorio, un programa de bug bounty o un contrato firmado, las mismas técnicas dejan de ser hacking ético y pasan a ser delito en España, con pena de prisión (se detalla en el apartado legal, más abajo).
La palabra «hacking» describe la actividad técnica en sí: romper algo para entender cómo funciona y dónde falla. Aplicada al terreno web cubre desde manipular un parámetro en una URL hasta encadenar varios fallos menores para tomar el control completo de una cuenta ajena. «Web hacking» es exactamente lo mismo dicho en inglés, y aparece con frecuencia en foros, writeups de CTF y ofertas de empleo internacionales.
¿Qué es el pentesting web y en qué se diferencia del hacking web?
El pentesting web, o pentest de aplicaciones web, es un hacking web con marco profesional: alcance acordado por escrito, reglas de compromiso, un cliente que paga por el servicio y un informe final con cada hallazgo clasificado por severidad. En el día a día del sector, «hacking web» y «pentesting web» funcionan como sinónimos, y quien se dedica a esto puede llamarse pentester web, consultor de seguridad ofensiva o auditor de aplicaciones según la empresa para la que trabaje.
Cuando existe una diferencia real es de contexto, no de técnica. «Hacking» es el término más amplio: incluye bug bounty, CTF e investigación personal sin cliente de por medio. «Pentesting» implica siempre un encargo formal, con alcance definido y un entregable al final. Nadie hace «un pentesting» fuera de un contrato, pero sí se puede hacer hacking web un sábado por la tarde en una plataforma de laboratorio sin que nadie lo haya pedido.
¿En qué se diferencia el hacking web de otras ramas del hacking ético?
El hacking web ataca la capa de aplicación: el código que procesa las peticiones HTTP, la lógica de negocio, las APIs y la sesión del usuario. Otras ramas del hacking ético atacan capas distintas del mismo sistema, y confundirlas es el error de orientación más habitual de quien empieza. La siguiente tabla resume las diferencias principales.
| Rama | Qué ataca | Herramienta o habilidad distintiva | Certificación de referencia |
|---|---|---|---|
| Hacking web / pentesting web | Aplicaciones, APIs, lógica de negocio | Proxy interceptor, análisis manual de peticiones HTTP | eWPT, BSCP, OSWE |
| Pentesting de red e infraestructura | Servidores, servicios de red, Active Directory | Escaneo de puertos, explotación de servicios, movimiento lateral | OSCP, PNPT |
| Red team | La organización completa, incluida la gente | Sigilo, evasión de EDR, ingeniería social | OSEP, CRTO |
| Forense digital / DFIR | Lo que queda después de un incidente | Análisis de disco, memoria y logs | GCFE, GCFA |
| Seguridad de IA | Modelos, RAG y sistemas agénticos | Prompt injection, extracción de datos de entrenamiento | GAIPS, OSAI |
| GRC | Procesos, políticas y cumplimiento normativo | Auditoría documental, no explotación | CISA, CISM |
La barrera de entrada al hacking web es más baja que la de la mayoría de estas ramas: no hace falta montar un dominio de Active Directory completo para empezar, con un navegador y un proxy interceptor ya se puede practicar contra una aplicación vulnerable. Es también la rama con más superficie de práctica gratuita, porque cualquier aplicación web insegura sirve de campo de pruebas sin necesidad de licencias ni hardware especial.
Quien busca la parte defensiva de estas mismas capas tiene rutas propias: defender Active Directory en vez de atacarlo, reconstruir lo ocurrido tras un incidente con nuestro curso de DFIR, o gobernar el riesgo desde arriba con el curso de GRC. Ninguna de las dos rutas sustituye a la otra: una empresa necesita gente que ataque su propia web antes de que lo haga un tercero, y gente que defienda y audite el resto de la infraestructura.
¿Qué vulnerabilidades busca el pentesting de aplicaciones web?
El catálogo de referencia es el OWASP Top 10, un documento que la fundación OWASP actualiza analizando cientos de miles de vulnerabilidades reales reportadas y encuestas a profesionales del sector. La edición vigente es la de 2025, publicada como candidata a versión final en noviembre de ese año durante la conferencia Global AppSec, y es la primera revisión de fondo desde 2021: incorpora dos categorías nuevas, cambia el orden de otras cuatro y fusiona el SSRF dentro del control de acceso roto. La tabla siguiente resume las diez categorías, qué implica cada una en la práctica y, cuando existe, el dato de prevalencia publicado.
| Código | Categoría | Qué implica en la práctica |
|---|---|---|
| A01:2025 | Control de acceso roto | Un usuario accede a datos o funciones que no le corresponden, incluidos IDOR y SSRF. Sigue en el primer puesto, como en 2021. |
| A02:2025 | Mala configuración de seguridad | Cabeceras ausentes, servicios cloud con permisos excesivos, páginas de error que filtran información. Sube del quinto al segundo puesto. |
| A03:2025 | Fallos en la cadena de suministro de software | Dependencias y paquetes comprometidos que llegan a la aplicación sin pasar por un escáner de vulnerabilidades tradicional. Categoría nueva en 2025. |
| A04:2025 | Fallos criptográficos | Datos sensibles sin cifrar o con algoritmos débiles, tanto en tránsito como en reposo. Baja del segundo al cuarto puesto. |
| A05:2025 | Inyección | SQL injection, XSS y command injection: código o consultas ajenas ejecutadas dentro de la aplicación. Baja del tercer al quinto puesto. |
| A06:2025 | Diseño inseguro | Fallos de arquitectura y de lógica de negocio que ningún parche corrige, porque el problema está en el diseño, no en el código. |
| A07:2025 | Fallos de autenticación | Contraseñas débiles, ausencia de doble factor, sesiones mal gestionadas. Mantiene el séptimo puesto. |
| A08:2025 | Fallos de integridad de software y datos | Actualizaciones sin verificar la firma, deserialización insegura de datos que no son de confianza. |
| A09:2025 | Fallos de registro y alertas de seguridad | Ausencia de logs útiles o de alertas que disparen una respuesta real ante un evento sospechoso. |
| A10:2025 | Manejo incorrecto de condiciones excepcionales | Errores y estados anómalos que exponen información o conceden acceso por defecto. Categoría nueva en 2025. |
Dos datos de prevalencia, tomados de un análisis publicado por Qualys sobre la edición 2025: la mala configuración de seguridad (A02) aparece en el 100 % de las aplicaciones auditadas al menos una vez, con una tasa media de incidencia del 3 %, y la cadena de suministro de software (A03) tiene la tasa de incidencia media más alta de las diez categorías, un 5,19 %, aunque solo once CWE de la base de datos de vulnerabilidades mapean directamente a ella, lo que explica por qué muchos escáneres automáticos todavía no la detectan bien.
¿Qué impacto real tienen estas vulnerabilidades?
El impacto de una vulnerabilidad web, en la mayoría de los casos, se mide en tres planos a la vez: los datos que se pueden extraer o modificar, el dinero que cuesta el incidente y la obligación legal de notificarlo. Un control de acceso roto en una API de facturación permite ver o modificar pedidos ajenos con solo cambiar un número en la URL, sin necesitar ninguna herramienta sofisticada. Una inyección SQL en un formulario de login puede exponer la base de datos completa de usuarios, incluidas contraseñas si están mal protegidas. Un fallo de autenticación sin límite de intentos permite probar miles de contraseñas por minuto contra cuentas reales.
La magnitud del dinero que mueve este campo, tanto en defensa como en el lado de quien encuentra los fallos de forma legal, da una idea del peso real del problema. HackerOne, la mayor plataforma de bug bounty del mundo, pagó 81 millones de dólares en recompensas a lo largo de los doce meses anteriores a octubre de 2025, repartidos en más de 1.950 programas activos, según su noveno informe anual publicado ese mismo mes. Esa cifra es dinero que empresas reales pagan a hackers externos por encontrar, en sus propias aplicaciones web, exactamente el tipo de fallos que recoge el OWASP Top 10.
El otro plano es regulatorio: en la Unión Europea, un fallo web que exponga datos personales activa las obligaciones de notificación del RGPD, con plazos y sanciones que dependen de la gravedad y de si la empresa tenía medidas razonables en marcha. Un pentest web documentado, con fecha e informe, es precisamente la prueba de diligencia que muchas empresas necesitan mostrar si algo falla más adelante.
¿Qué herramientas usa un pentester web?
El centro de casi cualquier flujo de trabajo de hacking web es un proxy interceptor, un programa que se coloca entre el navegador y la aplicación para ver, modificar y repetir cada petición HTTP. Burp Suite, de PortSwigger, es el más extendido en el sector: su edición Community es gratuita y suficiente para empezar, y la edición Professional cuesta alrededor de 449 dólares al año e incluye un escáner automático y funciones de repetición y automatización avanzadas. OWASP ZAP es la alternativa de código abierto y gratuita, con un escáner propio integrado, muy usada en equipos que no pueden pagar una licencia o que la necesitan dentro de un pipeline de integración continua.
Alrededor del proxy hay un grupo de herramientas especializadas por tipo de tarea. sqlmap automatiza la detección y explotación de inyección SQL contra varios motores de base de datos a la vez. ffuf y gobuster sirven para descubrir rutas, parámetros y subdominios que no aparecen en ningún menú visible, mediante fuerza bruta contra listas de palabras. Nmap, aunque nació para redes, se usa también en la fase de reconocimiento para identificar qué servicios y tecnologías corren detrás de una aplicación web. Nikto hace un barrido rápido de configuraciones peligrosas y ficheros que no deberían ser accesibles.
Ninguna de estas herramientas sustituye el criterio de quien las usa. Un escáner automático encuentra patrones conocidos; encadenar dos fallos menores para conseguir un impacto grave, o entender por qué una validación de la aplicación se puede rodear, sigue siendo trabajo manual. Esa combinación entre automatización y análisis propio es justo lo que separa a un profesional de alguien que solo sabe lanzar un escáner y copiar el resultado.
¿Cómo es el trabajo real de un pentester de aplicaciones web?
Un encargo real empieza mucho antes de tocar la aplicación, con la definición del alcance: qué dominios, qué entornos, qué está prohibido tocar (por ejemplo, el sistema de pagos en producción) y en qué ventana de tiempo se puede trabajar, todo firmado por el cliente. Sin ese documento no hay pentest legal, solo un ataque.
Después viene el reconocimiento, casi siempre la fase que más tiempo real consume: mapear qué tecnologías usa la aplicación, qué endpoints existen, cómo se comporta con distintos tipos de usuario. La explotación en sí, la parte que suele imaginarse cuando se piensa en hacking, ocupa menos tiempo del que parece; gran parte del trabajo es probar hipótesis que no llevan a ningún sitio antes de dar con la que sí funciona. El entregable final, el informe, es también trabajo real y no un trámite: tiene que explicar cada hallazgo con su severidad, su evidencia y una recomendación técnica que el equipo de desarrollo del cliente pueda aplicar sin ambigüedad, porque de ese informe depende que el cliente entienda el riesgo y lo corrija.
El sueldo medio de un pentester en España es de 28.500 € brutos anuales según Glassdoor España, consultado en agosto de 2026, con la mitad central de los sueldos entre 23.000 € y 37.600 € y el percentil 90 en torno a 49.700 €; un puesto senior sube a una media de 58.464 €, con la mitad central entre 47.671 € y 84.506 €. Son cifras de una muestra de portal de empleo, no un censo oficial, y conviene tratarlas como orientación de rango más que como una cifra exacta.
La forma de trabajar varía según dónde se está: en una consultora de ciberseguridad, el trabajo llega por encargos de clientes distintos cada pocas semanas; dentro del equipo de seguridad de una sola empresa, el foco se mantiene en la misma aplicación durante meses, con ciclos de retest tras cada corrección; como autónomo o en bug bounty, el propio profesional elige el programa y compite con el resto de la comunidad por encontrar el fallo antes que nadie.
¿Cómo se aprende y se practica hacking web de forma legal?
Practicar hacking web sin permiso, incluso contra una web que «parece» fácil de romper, entra dentro del artículo 197 bis del Código Penal español, que castiga con prisión de seis meses a dos años a quien acceda sin autorización a un sistema de información vulnerando sus medidas de seguridad. La forma de practicar sin ese riesgo es usar aplicaciones creadas expresamente para ser atacadas, o programas de bug bounty que autorizan explícitamente el ataque dentro de un alcance definido.
El punto de partida más recomendado por la propia comunidad es PortSwigger Web Security Academy, una plataforma cien por cien gratuita con laboratorios guiados organizados por vulnerabilidad (por ejemplo, dieciséis laboratorios distintos solo de inyección SQL y treinta de XSS), con la teoría explicada antes de cada ejercicio. En paralelo, DVWA (Damn Vulnerable Web Application), una aplicación en PHP y MariaDB de código abierto bajo licencia GPL-3.0 que se instala en local o con Docker, permite practicar con niveles de dificultad crecientes y sin depender de conexión a internet. OWASP Juice Shop ofrece un enfoque más de reto: una tienda online ficticia hecha en Node.js, Express y Angular, con alrededor de 113 desafíos de dificultad variable, publicada bajo licencia MIT.
Para quien prefiere una ruta guiada con progreso visible, TryHackMe y Hack The Box añaden salas y máquinas con niveles crecientes de dificultad, la primera con un enfoque más didáctico y la segunda más exigente; ambas combinan una capa gratuita con planes de pago para el contenido más avanzado. El último escalón, ya con base sólida, es un programa de bug bounty real en HackerOne o Bugcrowd, donde el alcance autorizado lo define cada empresa y cobrar depende de encontrar un fallo válido antes que el resto de participantes.
| Plataforma | Tipo | Coste | Para quién |
|---|---|---|---|
| PortSwigger Web Security Academy | Laboratorios guiados por vulnerabilidad, con teoría | Gratis | Quien quiere entender cada fallo en profundidad antes de tocarlo |
| DVWA | Aplicación vulnerable autoalojada | Gratis, código abierto | Quien quiere control total del entorno, sin depender de internet |
| OWASP Juice Shop | Aplicación vulnerable tipo reto, con puntuación | Gratis, código abierto | Quien prefiere el formato CTF a la teoría guiada |
| TryHackMe | Salas guiadas y rutas de aprendizaje | Capa gratuita + suscripción de pago | Quien empieza sin experiencia y quiere una mano que le guíe |
| Hack The Box | Laboratorios y máquinas más exigentes | Capa gratuita limitada + planes de pago | Quien ya tiene base y quiere ponerse a prueba con menos guía |
| HackerOne / Bugcrowd | Programas de bug bounty sobre aplicaciones reales | Gratis participar, se cobra por hallazgo válido | Quien domina lo anterior y quiere encontrar fallos reales, con autorización explícita |
Quien parte de cero en ciberseguridad y todavía no sabe si el hacking web es la rama que le interesa tiene una ruta previa de fundamentos, antes de entrar en cualquiera de estas plataformas, en nuestra guía sobre cómo empezar en ciberseguridad desde cero. Quien ya tiene claro que esta es su rama y quiere acreditarlo puede consultar las certificaciones específicas de seguridad de aplicaciones en nuestro mapa de certificaciones, filtrable por carrera y nivel.
Metodología y fuentes
Esta guía se ha escrito el 1 de agosto de 2026 y cada dato factual procede de una fuente abierta esa misma sesión. La lista y el orden de las diez categorías del OWASP Top 10:2025, junto con el dato de que es la primera revisión de fondo desde 2021 y que se anunció como candidata en noviembre de 2025 en la conferencia Global AppSec, se ha verificado en owasp.org (owasp.org/Top10/2025/ y su introducción oficial) y contrastado con un análisis independiente de Qualys que aporta los datos de prevalencia de las categorías A02 y A03. Los precios de Burp Suite Professional se han consultado en fuentes de comparación de precios de software, no directamente en la tienda de PortSwigger, así que se dan como cifra orientativa en dólares y pueden variar con el tipo de cambio o promociones puntuales.
Los datos de HackerOne (81 millones de dólares pagados, más de 1.950 programas activos) proceden de la cobertura del noveno informe anual de la propia plataforma, publicada el 2 de octubre de 2025. Los sueldos de pentester en España son de Glassdoor España, consultado en agosto de 2026, con las muestras y percentiles que la propia plataforma publica; al tratarse de un portal de empleo y no de un organismo oficial, se presentan como rango orientativo. El texto del artículo 197 bis del Código Penal se ha verificado contra el texto consolidado de la Ley Orgánica 10/1995 en la web del BOE. Los datos de DVWA (licencia GPL-3.0, PHP y MariaDB) y de OWASP Juice Shop (licencia MIT, Node.js, Express y Angular, alrededor de 113 desafíos) proceden de sus respectivos repositorios y páginas oficiales del proyecto OWASP.
Preguntas frecuentes sobre hacking web y pentesting web
¿Hace falta saber programar para dedicarse al hacking web?
No es imprescindible para empezar, pero sí para progresar. Los primeros laboratorios de PortSwigger o DVWA se resuelven entendiendo peticiones HTTP y manipulando parámetros, sin escribir una línea de código propio. Para automatizar pruebas, leer código fuente en un pentest de caja blanca o escribir el exploit de una vulnerabilidad compleja, hace falta programar, y JavaScript y Python son los lenguajes más útiles en esta rama concreta.
¿Cuánto se tarda en empezar a encontrar vulnerabilidades reales?
Con dedicación constante, entender los fundamentos de HTTP y resolver los laboratorios básicos de inyección y XSS suele llevar entre uno y tres meses. Encontrar un primer fallo válido en un programa de bug bounty real, contra una aplicación que ya ha sido revisada por miles de personas antes, suele tardar más y depende tanto de la constancia como de elegir programas con menos competencia.
¿Qué diferencia hay entre un pentest de caja negra, gris y blanca en el contexto web?
La diferencia es cuánta información recibe el pentester antes de empezar. En caja negra no se entrega nada, ni siquiera las credenciales, y hay que descubrirlo todo como lo haría un atacante externo. En caja gris se entrega una cuenta de usuario normal, para probar qué se puede hacer una vez dentro. En caja blanca se entrega también el código fuente, lo que permite encontrar fallos de lógica que ningún escaneo externo detectaría.
¿Se puede vivir solo del bug bounty?
Un grupo reducido de investigadores sí lo consigue: según el informe de HackerOne, los cien mayores ganadores históricos de la plataforma acumulan en conjunto 31,8 millones de dólares, con varios superando de forma consistente cifras de seis dígitos al año. Para la inmensa mayoría de participantes, el bug bounty es un ingreso complementario o una forma de construir reputación y currículum, no un sueldo estable desde el primer día.
¿El OWASP Top 10 cambia todos los años?
No. La edición 2025 es la primera actualización de fondo desde 2021, cuatro años después. OWASP no publica una revisión completa cada año porque el proceso implica analizar cientos de miles de vulnerabilidades reales y encuestar a la comunidad, un trabajo que no tiene sentido repetir de forma anual.
¿Qué certificación conviene para demostrar nivel en hacking web?
Depende de cuánto se quiera invertir y del nivel de partida. Existen certificaciones específicas de seguridad de aplicaciones con examen tanto teórico como cien por cien práctico, desde puntos de entrada accesibles hasta certificaciones de nivel experto centradas en auditoría de código. El mapa de certificaciones propio permite filtrar por carrera de aplicaciones y por nivel para comparar de un vistazo cuál encaja con cada situación.
¿Es legal practicar hacking web contra una empresa real sin avisarle antes?
No, salvo que esa empresa tenga un programa de bug bounty público con un alcance definido que cubra exactamente lo que se va a probar. Fuera de ese alcance, o sin programa alguno, acceder a un sistema vulnerando sus medidas de seguridad está tipificado como delito en el artículo 197 bis del Código Penal español, con pena de prisión de seis meses a dos años.
