Pentesting web: qué revisar y cómo definir el alcance

Las pruebas de seguridad de aplicaciones web evalúan si los controles de seguridad funcionan como se espera. Pueden incluir comprobaciones automáticas, revisión de código y pruebas de penetración. Este artículo trata de un pentesting web, o pentest de aplicaciones web: una prueba autorizada y realizada por especialistas sobre una aplicación en funcionamiento —un sitio, un portal de clientes o una tienda en línea—, en la que se revisa cómo autentica usuarios, mantiene sesiones, aplica permisos y maneja datos.

Los especialistas suelen combinar escáneres con comprobaciones manuales. Según la herramienta y su configuración, un escaneo puede detectar vulnerabilidades conocidas en los componentes que identifica, cabeceras de seguridad ausentes y un cifrado de conexiones (TLS) débil. Lo que un escáner no puede juzgar por sí solo es si una respuesta es correcta para quien la pide. Ve que la página de un pedido carga; si nadie le indicó de quién es cada pedido, no sabe que es de otra persona. La guía del NIST de 2008 señala que los escáneres de aplicaciones suelen tener tasas altas de falsas alarmas (falsos positivos) y además pasan por alto problemas reales, por eso sus resultados necesitan interpretación (NIST SP 800-115, sección 4.3).

Qué revisa un pentest web

Las áreas están bien establecidas. La guía pública de pruebas de seguridad web de OWASP las agrupa en categorías; su versión estable actual, la 4.2, se publicó en diciembre de 2020 (OWASP WSTG, en inglés). Según el alcance acordado, una prueba suele cubrir:

Autenticación: inicio de sesión, recuperación de contraseña, pasos de doble factor y bloqueo de cuentas.
Sesiones: cómo la aplicación mantiene la sesión abierta y si la cierra cuando corresponde.
Control de acceso: si cada usuario llega solo a los datos y funciones que su rol le permite.
Manejo de entradas: si la aplicación maneja de forma segura datos inesperados, incluidos los intentos de que los interprete como instrucciones o código (inyección).
Lógica de negocio: si las reglas propias de la aplicación se sostienen cuando se saltan, repiten o reordenan pasos.
Configuración y componentes: ajustes del servidor, mensajes de error, archivos expuestos y bibliotecas desactualizadas.
Manejo de datos: qué datos sensibles se guardan, se envían o se muestran, y a quién.

Control de acceso entre usuarios y roles

Los fallos de control de acceso (Broken Access Control) ocupan el primer lugar del OWASP Top 10:2025, la lista de referencia del proyecto sobre riesgos de seguridad en aplicaciones web (OWASP Top 10:2025, en inglés).

El caso típico es fácil de explicar. Un cliente entra al portal de su aseguradora y abre una factura en una dirección que termina en /facturas/1042. Cambia el número por 1041 y ve la factura de otro cliente. Nada parece roto: la página carga con normalidad, y un escáner al que nadie le dijo de quién es cada factura pasa de largo. Dos cuentas de prueba con facturas distintas, y alguien que sepa de quién es cada una, facilitan la comprobación. Las comprobaciones automatizadas pueden comparar accesos entre cuentas si se configuran con los permisos esperados; el especialista define esas expectativas e investiga las excepciones.

Los especialistas repiten esto entre roles. ¿Un usuario común puede llegar a una función de administrador? ¿Una empresa cliente puede ver los datos de otra en una plataforma compartida? ¿Un usuario al que le quitaron el acceso todavía puede actuar con un enlace viejo?

Lógica de negocio: poner a prueba sus propias reglas

Una lista de vulnerabilidades no explica cómo deben funcionar las reglas de su aplicación; su equipo describe los límites previstos y el orden de los pasos. Un cupón de descuento que debería usarse una sola vez. Un pago que debe ir antes del envío. Una cantidad que nunca debería ser negativa. Un límite diario de transferencias.

El especialista revisa qué pasa cuando esas reglas se enfrentan a una secuencia inesperada: la misma solicitud enviada dos veces, un paso omitido, un precio o un número de cuenta modificado en el camino al servidor. Para una tienda en línea en plena temporada de ofertas, una falla así es tanto un problema de precios como de seguridad.

Pruebas de seguridad de API: la misma aplicación, otra puerta

Las aplicaciones web y móviles actuales hablan con sus servidores a través de API —las interfaces con las que los programas intercambian datos—, y una API se puede llamar directamente, sin las pantallas que normalmente limitan lo que hace un usuario. Por eso una prueba que solo recorre las pantallas puede omitir solicitudes que la API acepta directamente; el servidor debe comprobar los permisos aunque la solicitud no pase por esas pantallas. El OWASP API Security Top 10 2023 pone en primer lugar los fallos de autorización a nivel de objeto, es decir, en el acceso a registros concretos: la versión API del ejemplo de la factura (OWASP API Security Top 10 2023, en inglés).

Probar una API funciona mejor con insumos propios: la documentación de la API o una descripción OpenAPI si existe, credenciales de prueba para cada tipo de cliente y la lista de endpoints (direcciones de la API) incluidos. IntruForce ofrece pruebas de seguridad de API como un servicio aparte, centrado en cómo la API autentica a usuarios y sistemas, aplica los permisos, procesa las solicitudes y expone datos.

Pentesting web vs. escáner

Los dos tienen su lugar, y responden preguntas distintas. Para sistemas en general, vea análisis de vulnerabilidades o pentest.

Lo que un escáner hace bien

Vulnerabilidades conocidas en los componentes y versiones que logra identificar.
Cabeceras de seguridad ausentes, configuraciones TLS débiles y archivos por defecto expuestos.
Repetir los mismos controles después de cada nueva versión.

Lo que debe revisar un especialista

El control de acceso entre usuarios, roles y empresas cliente: decidir qué debe ver cada uno y comprobarlo.
La lógica de negocio y el orden de los pasos de un proceso.
Cadenas de problemas pequeños que juntos suman uno grave.
Juzgar si un hallazgo —un posible problema de seguridad— importa para esta aplicación en particular.

Cómo acordar el alcance de la prueba

Defina los objetivos y obtenga autorización por escrito antes de empezar. Acuerde el horario, las acciones permitidas, los límites de solicitudes y un contacto que pueda detener la prueba; acuerde también cómo se tratarán los datos de prueba y las evidencias. Después, concrete:

La aplicación y sus partes: las URL, las API que hay detrás y las áreas de administración.
Roles y datos de prueba: qué roles y empresas cliente estarán representados. Cuando los usuarios deban tener accesos separados, facilite cuentas con registros propios para comparar los permisos.
Entorno: una copia de pruebas que refleje producción, o producción con límites acordados.
Flujos clave: alta, pago, aprobación, exportación; los pasos por los que pasan dinero o datos.
Terceros: las pasarelas de pago y otros servicios que no son suyos quedan fuera, salvo que su dueño autorice la prueba.
Capas de protección: si el firewall de aplicaciones web sigue activo, de modo que la prueba pase por los controles que encontraría un atacante, o se relaja para las direcciones del equipo de prueba, con una autorización aparte, para examinar el comportamiento de la aplicación. Deje registrado qué configuración se aplicó a cada comprobación y qué límites tenía.

Si su equipo quiere una lista de requisitos contra la cual probar, el estándar de verificación de seguridad de aplicaciones de OWASP (ASVS) está escrito para eso; la versión 5.0.0 se publicó el 30 de mayo de 2025 (OWASP ASVS, en inglés).

Qué recibe

Una prueba de seguridad de aplicaciones web de IntruForce evalúa los sitios web, portales de clientes, tiendas en línea, interfaces de CRM y otras aplicaciones web incluidas en el alcance acordado. Usted recibe hallazgos confirmados con evidencia de respaldo, una explicación de la funcionalidad afectada y recomendaciones prácticas para los equipos de desarrollo y de TI. Qué debe traer un buen informe, hallazgo por hallazgo, lo explicamos en qué es un pentest y qué debe incluir su informe.

Para hablar de una prueba, describa la aplicación y lo que le preocupa en el formulario de la página de servicios. Enviar la solicitud no le obliga a contratar un servicio, y las pruebas que interactúan con sus sistemas se acuerdan por separado.