Pentesting web: cómo se realiza y qué te toca a ti si lo encargas

Un pentesting web es un ataque autorizado y hecho a mano contra tu aplicación web, con un usuario de prueba por cada rol, para comprobar si alguien puede llegar a datos o funciones que no le corresponden.

Casi todo lo que hay escrito sobre el tema es para aprender a hacerlo. Este artículo es para quien lo va a encargar: qué se prueba en tu aplicación, qué te vamos a pedir, cuánto tarda y qué recibes al final.

Qué es un pentesting web y qué no

Un pentesting de aplicaciones web prueba la aplicación que habéis construido vosotros: un SaaS, el área privada de clientes, un ecommerce hecho a medida o una herramienta interna con login. El auditor entra como lo haría un usuario, con una cuenta de cada rol, e intenta hacer lo que ese rol no debería poder hacer. Lo que encuentra lo explota hasta donde se haya pactado y lo documenta con la evidencia.

Hay tres cosas que se confunden con él y no lo son.

• › Un escaneo automático. Una herramienta compara tu aplicación con un catálogo de fallos conocidos y devuelve una lista sin comprobar. Sirve, pero no sabe qué es un pedido en tu negocio ni quién debería ver qué. La comparación completa está en qué es una auditoría de pentesting.
• › Una auditoría de la web corporativa. Si lo que tienes es un WordPress con la información de la empresa, lo que hay que revisar es el gestor de contenidos y sus plugins, porque no hay lógica de negocio propia que probar. Es otro encargo, y está al final de este artículo.
• › Una certificación. Del pentesting sale un informe con fecha que sirve como evidencia ante un cliente o un auditor. No sale ningún sello.

Qué se prueba en tu aplicación

Lo que se prueba sale de un guion público, la OWASP Web Security Testing Guide (WSTG), cuya versión estable a octubre de 2026 sigue siendo la 4.2. Agrupa las pruebas por áreas y no todas pesan lo mismo: en una aplicación con login, casi todo el riesgo se concentra en cuatro.

Alrededor de esas cuatro va el resto del guion: la configuración del servidor, la recuperación de contraseña, los ficheros que se suben, los mensajes de error que cuentan más de la cuenta y las cabeceras de seguridad. Antes de todo eso se mapea la aplicación rol por rol, porque el JavaScript que descarga el navegador suele delatar rutas que no aparecen en ningún menú.

Así trabajamos el pentesting de aplicaciones web: a mano, contra la WSTG y con un usuario de cada rol. Parte de 1.140 €, cada hallazgo del informe lleva la evidencia y los pasos para reproducirlo, y el retest va incluido.

La lógica de negocio: lo que ningún escáner ve

Un fallo de lógica de negocio es una petición perfectamente válida que la aplicación no debería aceptar. No hay firma que buscar ni carácter raro que filtrar, así que ni un escáner ni un WAF la distinguen de un uso normal.

Un ejemplo de los que aparecen en aplicaciones SaaS. El plan básico permite tres usuarios por cuenta, y la pantalla de invitar apaga el botón cuando llegas al tercero. Pero la petición que crea la invitación no comprueba nada: el auditor la captura con el proxy, cambia el correo y la vuelve a enviar. Veinte peticiones después, una cuenta que paga por tres usuarios tiene veinte.

Nadie ha forzado nada en el sentido clásico. No hay inyección ni contraseña robada, solo una regla de negocio que vive en la pantalla y no en el servidor, que es donde tiene que estar. Para encontrarla hay que saber que el plan tiene un límite, y eso no lo sabe ninguna herramienta: lo sabe quien ha leído la página de precios y lo prueba.

Pasa lo mismo con un cupón de un solo uso que se canjea dos veces si las dos peticiones llegan a la vez, o con un alta en cuatro pasos que deja ir directamente al cuarto sin pasar por el de pago. Son los hallazgos que más cuesta explicar en un comité y los que más afectan al negocio, porque tocan directamente el dinero o los datos de los clientes.

Cómo se realiza, paso a paso desde tu lado

Visto desde fuera, un pentesting web parece una caja cerrada: firmas, esperas y llega un PDF. Desde tu lado hay cinco momentos, y en casi todos te toca hacer algo.

1. 01Alcance. Nos dices qué aplicación entra, en qué dirección, cuántos roles tiene y si hay un entorno de preproducción con el mismo código. Con eso sale el presupuesto.
2. 02Plan y autorización. Se firman el alcance, la ventana de pruebas y la autorización para atacar la aplicación. Si está alojada en un proveedor cloud o la mantiene un tercero, avísale antes de fijar fechas.
3. 03Accesos. Un usuario de prueba por cada rol, con datos de prueba dentro, y aviso a quien gestione el WAF con las IP desde las que trabajamos. Sin ese aviso, el bloqueo llega antes que la primera prueba útil.
4. 04Pruebas. El trabajo de campo. Tu parte es tener a alguien localizable. Si aparece algo crítico, como un acceso a datos de clientes, te llamamos ese mismo día y no esperamos al informe.
5. 05Informe, presentación y retest. Recibes el informe técnico y el ejecutivo, los presentamos en una reunión y, cuando hayáis corregido, volvemos a probar lo arreglado. El retest va incluido y se puede pedir hasta seis meses después de la entrega.

La pregunta que más se repite es si se prueba en producción o en preproducción. Preproducción vale si corre el mismo código y la misma configuración; una copia de hace tres meses da resultados de hace tres meses. Si solo existe producción, se trabaja ahí, en la ventana pactada y sin pruebas que puedan tumbar el servicio.

Qué trae el informe y cómo se lee cada apartado está en qué debe incluir un informe de pentesting.

Cuánto dura

La fase de pruebas de un pentesting web dura entre una y tres semanas según el tamaño de la aplicación, y el informe técnico lleva de uno a tres días más. En una aplicación acotada, con pocos roles, la referencia es tener el informe en unos diez días. Es una estimación: la fecha real se cierra en el plan de auditoría, antes de empezar.

Lo que alarga o acorta ese plazo no es el número de pantallas.

• › Los roles. Cada par de roles se prueba en las dos direcciones. Con tres roles hay seis combinaciones que comprobar; con seis roles, treinta.
• › Los flujos que mueven dinero o datos. El pago, el alta, el cambio de plan y la exportación se prueban a mano, uno por uno.
• › Las peticiones al servidor. Lo que se prueba es cada petición y sus parámetros, y una sola pantalla de configuración puede esconder decenas.
• › El entorno. Con una preproducción fiel se prueba más deprisa que en producción con el freno puesto.

El calendario completo, fase por fase y con lo que se entrega en cada una, está en auditoría de pentesting: qué pasa desde la firma hasta el informe.

Herramientas: el banco de trabajo, no el servicio

Las herramientas para pentesting web son públicas, y casi todas gratuitas o baratas. Lo que las hace útiles es quién las maneja, porque ninguna sabe qué es un pedido, un plan o un rol dentro de tu aplicación. Estas son las que más se usan.

Muchas guías siguen llamando OWASP ZAP a la segunda. Dejó de ser un proyecto de OWASP en 2023 y hoy se publica como ZAP by Checkmarx, con el mismo equipo y como código abierto.

El trabajo de verdad se hace casi entero en el proxy y a mano: capturar una petición, cambiar un identificador, un importe o un rol, y ver qué contesta el servidor. Los escáneres corren el primer día para inventariar y quitar de en medio lo evidente. Por eso, si un presupuesto solo habla de herramientas, la pregunta que lo aclara es cuántos días de auditor incluye.

Web, web corporativa o API: cuál pedir

Los tres encargos se parecen en el nombre y no en lo que prueban. Lo que decide cuál pedir es qué tienes: una aplicación con usuarios y lógica propia, una web de empresa sobre un gestor de contenidos o una API que llaman otros.

Si tu aplicación tiene un frontal que llama a su propia API, esa API entra en el pentesting web, porque un atacante no distingue entre las dos capas. El pentesting de APIs es un encargo aparte cuando la API se publica para terceros, con su propia autenticación y sus propios clientes. Y si lo que te preocupa es la web de la empresa, la auditoría de web corporativa es más corta y más barata, porque no hay lógica propia que probar.

Si lo que tienes es una aplicación con usuarios, el siguiente paso es contar sus roles, apuntar qué flujos mueven dinero o datos y saber si hay preproducción. Con esos tres datos preparamos el presupuesto de un pentesting de aplicaciones web, que suele salir en 24 horas. Qué hace subir o bajar la cifra está en cuánto cuesta un pentesting.