Pentesting web: auditoría de seguridad de aplicaciones web

Tu aplicación web es la puerta de entrada a tus datos, tus clientes y tu negocio. Evaluamos su seguridad como lo haría un atacante real, cubriendo desde el OWASP Top 10 hasta las vulnerabilidades específicas de tu stack tecnológico.

Dimensiona tu proyecto · Solicitar auditoría web

¿Prefieres hablarlo? Llámanos al +34 960 730 013

OWASP Top 10:2025 — Cobertura completa de la edición vigente, más la lógica de tu negocio
Caja gris — Dos cuentas por rol para probar la autorización entre usuarios
Mismo día — Aviso inmediato si aparece algo crítico, sin esperar al informe
Retest — Verificación de las correcciones incluida

Las aplicaciones web son el vector de ataque más explotado

Tu aplicación web es la parte de tu empresa expuesta a Internet 24/7 y accesible para cualquiera. El control de acceso roto (Broken Access Control) encabeza el OWASP Top 10 desde la edición de 2021 y sigue siendo el riesgo A01 en la de 2025. Inyecciones SQL, XSS, exposición de datos sensibles, autenticación débil, control de acceso inadecuado... La mayoría de estos fallos son silenciosos: tu app funciona perfectamente mientras hay una puerta trasera abierta. El pentesting web los encuentra y los cierra antes de que lo haga otro.

Cómo tres fallos «medios» acaban en la toma de una cuenta de administrador

Un escáner los puntuaría por separado y ninguno parecería urgente. Encadenados, dan el control de la aplicación. Es el tipo de recorrido que un pentest web manual reproduce.

Enumeración de usuarios (A07): El formulario de recuperación responde distinto si el correo existe: se confirma la cuenta del administrador. Sin alerta: parece tráfico normal
Token de recuperación débil (A07): El código es de 6 cifras y no hay límite de intentos ni caducidad corta: se adivina en minutos. Miles de intentos sin bloqueo
Panel sin control por rol (A01): Una vez dentro, las acciones de administración solo se ocultan en la interfaz; la API las acepta de cualquier sesión. Registrado, nadie lo revisa
Exportación masiva (A01): La función de exportar clientes descarga la base de datos completa en CSV. Sin alerta de volumen

Impacto: Datos de todos los clientes y control total de la aplicación, partiendo solo del correo del administrador.

Cadena ilustrativa construida con hallazgos habituales en auditorías web; no describe a un cliente concreto.

Qué cubrimos en un pentesting web

OWASP Top 10:2025 completo: control de acceso, configuración, cadena de suministro, criptografía, inyección (SQL, XSS, plantillas), diseño, autenticación, integridad, registro y gestión de errores
SSRF, subida de ficheros, deserialización insegura y redirecciones abiertas
Lógica de negocio: bypass de procesos de compra, escalada de privilegios, manipulación de datos
Autenticación y gestión de sesiones: tokens, cookies, 2FA, reset de contraseñas
Control de acceso: BOLA/IDOR, acceso horizontal y vertical a recursos
Configuración del servidor: cabeceras HTTP, TLS, CORS, CSP
Exposición de información sensible en respuestas, errores y metadatos

Metodología de pentesting web

Reconocimiento y mapeo: Identificamos la superficie de ataque: subdominios, tecnologías, endpoints expuestos, versiones de frameworks.
Análisis de autenticación: Evaluamos el flujo de login, gestión de sesiones, políticas de contraseñas y mecanismos de 2FA.
Pruebas manuales de lógica: Revisamos los flujos de negocio críticos: compras, roles de usuario, permisos, cambios de estado.
Explotación de vulnerabilidades: Confirmamos y explotamos de forma controlada cada hallazgo para medir su impacto real.
Documentación y entrega: Cada vulnerabilidad incluye descripción, evidencia (capturas, requests/responses), CVSS y pasos para reproducirla.

Los diez riesgos contra los que probamos tu aplicación

La lista de referencia de la seguridad web, en su edición de 2025. Toca un riesgo para ver en qué consiste y cómo lo comprobamos; los colores agrupan los que comparten causa.

A01:2025 Broken Access Control (Control de acceso): Un usuario accede a datos o acciones que no le corresponden: facturas de otra empresa, funciones de administrador, objetos ajenos por su identificador. Incluye SSRF desde esta edición. Probamos cada rol contra los recursos de los demás con dos cuentas por rol, en la interfaz y directamente en la API.
A02:2025 Security Misconfiguration (Configuración y criptografía): Configuraciones por defecto, paneles expuestos, CORS permisivo, cabeceras de seguridad ausentes o errores detallados en producción. Revisamos servidor, framework, cabeceras, CORS, CSP y los entornos y rutas que no deberían estar publicados.
A03:2025 Software Supply Chain Failures (Suministro e integridad): Dependencias, librerías de JavaScript, imágenes o servicios de terceros con vulnerabilidades conocidas o comprometidos. Identificamos componentes y versiones expuestos y comprobamos si sus vulnerabilidades conocidas son explotables en tu aplicación.
A04:2025 Cryptographic Failures (Configuración y criptografía): Datos sensibles sin cifrar, TLS débil, contraseñas con algoritmos obsoletos o secretos predecibles. Analizamos TLS, cookies, tokens, almacenamiento de credenciales y qué datos viajan o se guardan en claro.
A05:2025 Injection (Inyección y diseño): SQL, NoSQL, comandos del sistema, plantillas o XSS: la aplicación interpreta como código lo que debería ser un dato. Probamos cada entrada manualmente y con herramientas, y confirmamos el impacto real de lo que se encuentra.
A06:2025 Insecure Design (Inyección y diseño): Fallos en la lógica de negocio que no se arreglan con un parche: descuentos acumulables, pasos de un pago que se pueden saltar, límites que no existen. Revisamos los flujos críticos de tu negocio —compras, altas, aprobaciones— buscando cómo abusar de ellos.
A07:2025 Authentication Failures (Identidad y sesión): Inicio de sesión sin protección contra fuerza bruta, recuperación de contraseña débil, sesiones que no caducan o 2FA que se puede saltar. Atacamos login, recuperación, 2FA y la gestión de sesiones y tokens de principio a fin.
A08:2025 Software or Data Integrity Failures (Suministro e integridad): La aplicación confía en datos o código que no verifica: deserialización insegura, actualizaciones sin firma, scripts de terceros sin integridad. Buscamos objetos serializados, datos firmados mal validados y recursos externos cargados sin control.
A09:2025 Security Logging and Alerting Failures (Configuración y criptografía): Ataques que no dejan rastro o no generan ninguna alerta, lo que alarga cualquier intrusión. Comprobamos con vuestro equipo qué quedó registrado y qué alertas saltaron durante nuestras pruebas.
A10:2025 Mishandling of Exceptional Conditions (Inyección y diseño): Errores mal gestionados que dejan la aplicación en un estado inseguro: fallos que abren en vez de cerrar, excepciones que filtran información. Forzamos entradas inesperadas, tiempos de espera y fallos parciales para ver cómo reacciona la aplicación.

Fases de un pentesting web, paso a paso

Entregables

Informe ejecutivo: exposición global, riesgo para el negocio, prioridades de acción
Informe técnico: cada vulnerabilidad con PoC, CVSS y solución recomendada
Clasificación de todos los hallazgos por OWASP Top 10:2025 y CVSS
Reunión de revisión con el equipo de desarrollo
Retest de las correcciones incluido, con informe actualizado

¿Para qué tipo de aplicaciones lo hacemos?

E-commerce con pasarelas de pago y datos de tarjetas (PCI-DSS)
SaaS B2B con acceso multiusuario y datos sensibles de clientes
Portales corporativos, intranets y extranets
Aplicaciones de gestión (ERP, CRM, HCM) expuestas a internet
WordPress, Magento, PrestaShop y otros CMS con plugins de terceros
APIs web públicas o semipúblicas

Pentest web, escáner o bug bounty: qué te da cada uno

No son excluyentes, pero no sirven para lo mismo. Lo que encuentra cada enfoque y cuándo tiene sentido.

	Escáner automático	Programa de bug bounty	Pentest web manual
Qué encuentra	Fallos catalogados: versiones, cabeceras, patrones conocidos	Lo que encuentren los investigadores que participen	Catalogados, lógica de negocio y cadenas de fallos
Control de acceso entre usuarios	Casi nunca	Depende de las cuentas que tengan	Sistemático, con dos cuentas por rol
Cobertura	Amplia pero superficial	Irregular: se concentra en lo que más paga	Completa sobre el alcance acordado
Entregable	Listado de alertas sin validar	Reportes sueltos, cada uno con su formato	Informe ejecutivo y técnico con PoC y retest
Cuándo encaja	Vigilancia continua entre pentests	Producto maduro tras varios pentests	Antes de lanzar, tras cambios grandes o cuando un cliente lo exige

Compara con

Preguntas frecuentes

¿Hacéis pentesting en caja negra, gris o blanca?

Los tres. Caja negra simula un atacante externo sin información previa. Caja gris incluye credenciales de usuario estándar para evaluar el control de acceso. Caja blanca incluye acceso al código y la arquitectura, y permite un análisis más exhaustivo. La mayoría de los clientes optan por caja gris como equilibrio entre realismo y cobertura.

¿Evaluáis WordPress y otros CMS?

Sí. WordPress es el CMS más atacado del mundo precisamente por la proliferación de plugins vulnerables. Evaluamos el core, los plugins instalados, los temas, la configuración del servidor y las prácticas de acceso al panel de administración.

¿Podéis firmar un NDA antes de empezar?

Siempre. Antes de que compartas ningún dato sobre tu infraestructura, firmamos un acuerdo de confidencialidad.

¿Qué pasa si encontráis vulnerabilidades críticas?

Te avisamos de inmediato (mismo día) si encontramos algo que suponga un riesgo grave e inmediato para tu negocio, sin esperar a que termine el test completo.

¿Se puede hacer el pentesting sobre producción o necesitáis un entorno de pruebas?

Se puede hacer sobre producción y es lo más habitual, porque un preproducción con datos falsos y configuración distinta oculta justo lo que interesa encontrar. Lo que se acuerda antes es el perfil de intensidad, la ventana de ejecución para las pruebas que puedan generar carga y una vía de contacto directa para parar en caliente si algo se degrada. Las pruebas potencialmente destructivas se consultan antes de lanzarlas, nunca después.

¿Qué necesitáis para empezar: credenciales, código, documentación?

Depende del modelo de caja acordado. En caja negra basta con la URL y la autorización por escrito. En caja gris —el más rentable para una aplicación con usuarios— hacen falta dos cuentas por cada rol distinto, porque sin ellas no se puede probar la autorización entre usuarios, que es donde aparecen los hallazgos de mayor impacto. El código fuente solo es necesario si se contrata además revisión estática.

¿Qué diferencia hay entre esto y pasar un escáner de vulnerabilidades?

El escáner encuentra lo que ya está catalogado: versiones desactualizadas, cabeceras ausentes, patrones conocidos. No encuentra lógica de negocio rota, que es lo específico de tu aplicación: un descuento que se puede aplicar dos veces, un pedido ajeno cuyo estado se puede cambiar, un flujo de pago que se puede completar saltándose un paso. Eso exige entender a qué se dedica la empresa, y por eso no hay herramienta que lo automatice.

¿Cuánto dura un pentesting web?

La fase técnica suele llevar entre 3 y 10 días hábiles, según el número de roles, flujos y funcionalidades, y el informe llega 2-3 días después. El plazo exacto va en la propuesta, con alcance y precio cerrados.

¿Cada cuánto hay que repetirlo?

Como mínimo una vez al año y siempre después de un cambio relevante: una funcionalidad nueva que maneja datos sensibles, un cambio de autenticación o de proveedor, o una migración. Entre pentests, un análisis de vulnerabilidades recurrente vigila lo catalogado.

Antes de contratar

Entender la diferencia

Si tu web es algo más

Fuentes

¿Listo para proteger tu empresa?

Responde la ficha de alcance a tu ritmo y la usaremos para preparar tu propuesta. Si prefieres hablarlo antes, reserva una llamada gratuita de 30 minutos.

Dimensiona tu proyecto · Solicitar auditoría web