Un pentest (prueba de penetración) es una prueba de seguridad en la que un especialista, con tu permiso por escrito, imita los ataques reales contra tu web para encontrar los fallos antes que un atacante y demostrar hasta dónde llegaría. Una auditoría de seguridad web es más amplia: suma al pentest la revisión de la configuración, la documentación y los procesos. Las dos terminan en un informe con cada fallo, su gravedad y cómo corregirlo, y conviene cerrarlas con una nueva prueba que confirme la corrección.
¿Qué es exactamente un pentest?
Una referencia clásica es la guía NIST SP 800-115 del Instituto Nacional de Estándares y Tecnología de Estados Unidos, publicada en septiembre de 2008 y todavía vigente: en su página no hay aviso de retirada ni de revisión. La define como una prueba de seguridad en la que los evaluadores imitan ataques reales para encontrar la forma de burlar las defensas de una aplicación, un sistema o una red. Suele usar las mismas herramientas y técnicas que los atacantes, contra sistemas y datos reales.
Lo que la distingue es que no se queda en la lista de posibles fallos. Busca combinaciones: un fallo pequeño que da un usuario, otro que lo convierte en administrador, un tercero que abre la base de datos. Según NIST, también sirve para saber cuánto aguanta el sistema un ataque realista, qué nivel necesitaría un atacante para entrar y si tu equipo detecta el ataque y reacciona.
La guía de pruebas de OWASP, la fundación que publica las guías abiertas de seguridad web más conocidas, recuerda que al pentest también se le llama hacking ético. Y le pone dos límites: un pentest solo encuentra una muestra representativa de todos los riesgos, y llega tarde si es lo único que haces, porque un fallo detectado durante el desarrollo se corrige antes y más barato.
¿En qué se diferencia de un escaneo de vulnerabilidades y de una auditoría?
Se confunden mucho, y no cuestan ni prueban lo mismo. De un vistazo:
| Escaneo de vulnerabilidades | Pentest | Auditoría de seguridad | |
|---|---|---|---|
| Qué hace | Una herramienta compara tus servicios con bases de datos de fallos conocidos | Una persona intenta explotar los fallos para confirmar que existen y ver hasta dónde llega | Revisa configuración, documentación y procesos, y suele incluir pruebas como el pentest |
| Qué demuestra | Que un fallo puede existir | Que el fallo existe y qué daño permite | Si tus medidas de seguridad cumplen lo que deben |
| Lógica de negocio | No la ve | Sí | Sí, si incluye pruebas manuales |
| Frecuencia habitual | Periódica y automática | Periódica, más espaciada | Según el plan o la norma que apliques |
NIST lo resume así: el escáner solo comprueba si un fallo puede existir; la fase de ataque del pentest lo explota para confirmarlo. En su vocabulario, una evaluación de seguridad combina tres métodos: probar (testing), examinar documentos y configuraciones (examination) y entrevistar a las personas (interviewing). Una auditoría web completa usa los tres; un pentest es sobre todo lo primero.
OWASP es igual de claro con las herramientas automáticas: tienen su sitio, pero no piensan de forma creativa y no sustituyen una revisión a fondo. Sobre los fallos de lógica de negocio, su guía dice que un escáner de vulnerabilidades no los puede detectar y que hay que probarlos a mano. Un escáner no sabe que tu tienda no debería aplicar dos veces el mismo cupón.
¿Qué fases tiene un pentest?
NIST describe cuatro fases y aclara que es una forma de agruparlas entre varias posibles. La metodología PTES, que OWASP también recoge, las divide en siete. En la práctica, con una web, el trabajo va así:
- Planificación y autorización. Se fija el alcance, las reglas y los objetivos, y la dirección aprueba la prueba por escrito. En esta fase no se prueba nada.
- Descubrimiento. Recogida de información (dominios, servidores, versiones, puntos de entrada de la aplicación) y análisis de vulnerabilidades, con escáneres y con conocimiento propio del evaluador.
- Ataque. Se intenta explotar cada posible fallo: conseguir acceso, escalar privilegios, explorar el sistema y, si hace falta, volver a la fase anterior con lo aprendido. Se puede pactar parar antes de que una acción cause daño.
- Informe. Según NIST, ocurre en paralelo a las demás fases: se lleva un registro y se avisa durante la prueba, y al final se entrega un informe con los fallos, su nivel de riesgo y cómo corregirlos.
- Corrección y nueva prueba (retest). Corriges tú o tu proveedor, y el evaluador vuelve a probar. NIST advierte de que la corrección solo se puede dar por verificada si se repite la misma prueba original.
¿Caja negra, gris o blanca? ¿Externo o interno?
El nombre depende de cuánta información le das al evaluador antes de empezar:
| Tipo | Qué sabe el evaluador | Para qué sirve |
|---|---|---|
| Caja negra | Nada, salvo la dirección de la web | Ver lo que ve un atacante de fuera |
| Caja gris | Parte: por ejemplo, usuarios de prueba con distintos roles | Comprobar si un usuario puede ver o cambiar datos de otro |
| Caja blanca | Además, el código fuente | Encontrar fallos que desde fuera no se ven |
OWASP describe el pentest clásico como caja negra, la caja gris como la prueba en la que el evaluador conoce parte de la aplicación, y la caja blanca como la que incluye análisis del código. Si tu web tiene zona de clientes, la caja negra pura se queda corta: sin cuentas de prueba no se puede comprobar lo que un cliente ve de otro.
NIST añade otras dos distinciones:
- Externa o interna. La externa ataca desde internet, como un desconocido. La interna parte de dentro de tu red, como un empleado o un atacante que ya ha entrado. Si haces las dos, la externa suele ir primero, para que el evaluador no use información que un atacante de fuera no tendría.
- Avisada u oculta. En la prueba avisada, tu equipo técnico lo sabe y colabora. En la oculta solo lo sabe la dirección, y sirve para medir si tu equipo detecta el ataque. NIST dice que la oculta es más lenta y cara y que deja muchos fallos sin encontrar; la avisada es más barata, tiene menos riesgo y es la más habitual.
¿Qué se revisa en una web? Lo que pide la guía de OWASP
La OWASP Web Security Testing Guide (WSTG) es la lista de pruebas de referencia. Su versión estable es la 4.2, publicada en diciembre de 2020, y la 5.0 está en desarrollo. Organiza las pruebas en doce categorías:
| Categoría de la WSTG 4.2 | Qué se comprueba (ejemplos de la propia guía) |
|---|---|
| Recogida de información | Qué cuenta de ti un buscador, qué servidor y qué framework usas, ficheros como robots.txt, puntos de entrada |
| Configuración y despliegue | Copias de seguridad y ficheros olvidados, paneles de administración expuestos, métodos HTTP, HSTS, permisos, subdominios que se pueden secuestrar, almacenamiento en la nube |
| Gestión de identidades | Roles, registro y alta de usuarios, si se puede averiguar qué cuentas existen |
| Autenticación | Contraseñas por canal cifrado, credenciales por defecto, bloqueo tras intentos fallidos, saltarse el inicio de sesión, recuperación de contraseña |
| Autorización | Escalada de privilegios, referencias directas inseguras (ver lo de otro cliente cambiando un número en la URL), recorrido de directorios |
| Gestión de sesiones | Atributos de las cookies, fijación y secuestro de sesión, CSRF, cierre de sesión y caducidad |
| Validación de entradas | Inyección SQL, XSS reflejado y almacenado, inyección de comandos, SSRF, inyección de plantillas |
| Gestión de errores | Mensajes de error que enseñan trazas o detalles internos |
| Criptografía | TLS débil, datos sensibles sin cifrar, cifrado débil |
| Lógica de negocio | Peticiones falsificadas, saltarse pasos de un proceso, límites de uso, subida de ficheros inesperados o maliciosos |
| Lado del cliente | XSS en el navegador (DOM), CORS, clickjacking, almacenamiento del navegador, WebSockets |
| API | Pruebas de GraphQL (lo que trae la versión 4.2) |
Si tu web tiene un chatbot con IA, pide que se pruebe también la inyección de instrucciones: no está en esta lista de 2020.
¿Y el OWASP Top 10?
El OWASP Top 10 es otra cosa: la lista de los diez riesgos más críticos de las aplicaciones web. La edición vigente es la de 2025, que sustituye a la de 2021. Los tres primeros puestos son el control de acceso roto (A01), la configuración insegura (A02) y los fallos en la cadena de suministro del software (A03). Esta última, según la introducción de la edición 2025, amplía la antigua categoría de componentes vulnerables y desactualizados (A06 de 2021) a cualquier fallo en la cadena de suministro, no solo a las vulnerabilidades conocidas.
El propio OWASP avisa de que el Top 10 es ante todo un documento de concienciación: usado como estándar de pruebas, es el mínimo y solo un punto de partida. Para un estándar comprobable recomienda el ASVS (Application Security Verification Standard), cuya versión 5.0.0 se publicó en mayo de 2025. Y desaconseja que nadie diga que cubre todo el Top 10. Si un presupuesto promete "cobertura total del OWASP Top 10", pregunta qué pruebas hay detrás.
¿Qué debe decir la autorización por escrito?
Es lo primero, y no es un trámite. El Código Penal castiga con prisión de seis meses a dos años a quien, vulnerando las medidas de seguridad y "sin estar debidamente autorizado", acceda a un sistema de información o se mantenga en él contra la voluntad de quien tenga derecho a excluirlo (art. 197 bis.1). Y con prisión de seis meses a tres años a quien, sin autorización y de forma grave, obstaculice o interrumpa el funcionamiento de un sistema informático ajeno (art. 264 bis.1). La diferencia entre un pentest y un delito es el permiso de quien puede darlo.
NIST pide que el plan de la prueba responda a cinco preguntas: cuál es el alcance, quién está autorizado a hacerla, cómo se organiza, cómo se tratan los datos sensibles y qué se hace si hay un incidente. Convertido en lista para una pyme:
- Alcance exacto. Dominios, URL, IP y entornos que entran, y los que quedan fuera. NIST recomienda listar también lo excluido.
- Sistemas de terceros. Si la web está en un alojamiento o un servicio que no controlas, según NIST el dueño de esa red suele tener que dar también su consentimiento por escrito. En la nube, mira las reglas de tu proveedor (tabla de abajo).
- Fechas, horario e IP de origen del evaluador, para distinguir la prueba de un ataque real.
- Lo prohibido, dicho sin ambigüedad. NIST sugiere excluir las pruebas que se sabe que provocan una denegación de servicio u otras interrupciones. Y avisa de que un pentest puede dañar o dejar inoperativo un sistema y de que ese riesgo nunca se elimina del todo.
- Contactos de emergencia de las dos partes y qué hacer si aparece un intruso real: ¿se para la prueba?, ¿quién decide reanudarla?
- Datos. Cómo se guardan, se envían y se destruyen al acabar. Si el evaluador puede ver datos personales de clientes o empleados, los trata por tu cuenta: el RGPD exige un contrato con el encargado del tratamiento (art. 28.3).
- Confidencialidad. NIST menciona los acuerdos de confidencialidad y que los asesores legales intervengan en las pruebas intrusivas como el pentest.
Si la prueba descubre que alguien ya entró y accedió a datos personales, eso es una violación de seguridad: el RGPD obliga a notificarla a la autoridad de control sin dilación indebida y, si es posible, en 72 horas desde que tienes constancia, salvo que sea improbable que suponga un riesgo para las personas (art. 33.1).
¿Y si tu web está en la nube?
AWS y Google Cloud dicen expresamente que no hace falta pedir permiso para probar lo tuyo, y las reglas de Microsoft no piden aviso previo. Todos ponen condiciones:
| Proveedor | ¿Hay que avisar? | Lo que no se permite (entre otras cosas) |
|---|---|---|
| AWS | No, para su lista de servicios permitidos (EC2, RDS, CloudFront, Lambda, Lightsail, Elastic Beanstalk y otros). Las pruebas con mando y control (C2) sí necesitan aprobación previa | Denegación de servicio, también simulada (tiene su propia política); inundar puertos, protocolos o peticiones; recorrer zonas DNS de Route 53; tomar buckets de S3 o subdominios |
| Google Cloud | No, siempre que cumplas su política de uso aceptable y sus condiciones y solo afectes a tus proyectos | Probar aplicaciones de otros clientes |
| Microsoft | Sus reglas no piden aviso previo. Las pruebas deben hacerse dentro de tu propio tenant o de activos para los que tengas autorización expresa | Denegación de servicio; probar tenants ajenos; phishing a empleados de Microsoft |
¿Qué debe traer el informe?
La WSTG dedica un capítulo al informe y aclara que son sugerencias, no reglas. Lo que propone:
- Introducción: equipo, alcance acordado, limitaciones (por ejemplo, falta de accesos o credenciales) y calendario.
- Resumen ejecutivo, para dirección, con recomendaciones estratégicas para que los problemas no se repitan.
- Tabla de hallazgos con el nivel de riesgo de cada uno.
- Detalle de cada hallazgo: referencia, título, facilidad para explotarlo, impacto, riesgo, descripción y pasos para corregirlo.
- Anexos: la metodología usada y cómo se ha calculado la gravedad.
Para la gravedad, OWASP sugiere cinco niveles (informativo, bajo, medio, alto y crítico) y dice que algunos encargos exigen la puntuación CVSS. La CVSS v4.0 de FIRST, publicada el 1 de noviembre de 2023, traduce la nota así: 0,0 ninguna; de 0,1 a 3,9 baja; de 4,0 a 6,9 media; de 7,0 a 8,9 alta, y de 9,0 a 10,0 crítica.
NIST insiste en algo que se olvida: una prueba vale mucho más si acaba en un plan de corrección. Cada hallazgo debería llevar su causa de fondo y recomendaciones técnicas (aplicar un parche) y no técnicas (cambiar el proceso de actualizaciones). Y si es una segunda prueba, OWASP propone resumir los hallazgos de la anterior para ver qué se ha cerrado.
¿Cada cuánto hay que hacer un pentest? ¿Es obligatorio?
El RGPD, que se aplica a casi cualquier web con datos personales, no habla de pentest. Pero su artículo 32.1.d pide, según el riesgo, "un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento". No dice "pentest" ni fija una frecuencia, pero una prueba de seguridad documentada es una forma de demostrar que verificas.
Sobre la frecuencia, NIST dice que, por su coste y su impacto, un pentest al año puede ser suficiente, combinado con escaneos de vulnerabilidades periódicos, que dan menos trabajo. Tiene sentido adelantarlo cuando cambias algo importante, como el sistema de usuarios o los pagos. Y como el pentest llega al final, OWASP recomienda revisar la seguridad desde el diseño y el código, no solo antes de publicar.
¿Cómo eliges a quien lo haga?
Seis preguntas que separan una prueba seria de un escaneo con logotipo:
- ¿Qué metodología sigue? Debería nombrar la WSTG de OWASP, NIST SP 800-115 o PTES.
- ¿Te enseña un informe de ejemplo, anonimizado, con resumen para dirección y detalle técnico?
- ¿Te pasa un documento de autorización con alcance, exclusiones, horario y contactos antes de empezar?
- ¿Cómo trata y borra tus datos, y firma el contrato de encargado si los va a ver?
- ¿Incluye la nueva prueba de lo corregido?
- ¿Hace pruebas manuales, también de la lógica de tu negocio, o solo pasa herramientas?
Desconfía de quien garantice que tu web queda "100 % segura". OWASP recuerda que un pentest solo encuentra una muestra de los riesgos, y NIST, que las pruebas no dan una evaluación completa de la seguridad.
Si quieres que revisemos tu web, en Quantum Nova lo hacemos nosotros, sin subcontratar, y con precio cerrado tras un diagnóstico gratuito. Lo tienes en auditoría de seguridad y pentesting.
Preguntas frecuentes
¿Es legal hacer un pentest?
Sí, si lo autoriza por escrito quien tiene derecho sobre el sistema. Sin esa autorización, entrar en un sistema vulnerando sus medidas de seguridad es delito (art. 197 bis del Código Penal, prisión de seis meses a dos años). Por eso la autorización debe fijar el alcance, las fechas y lo prohibido, y cubrir también los sistemas de terceros.
¿Qué diferencia hay entre un pentest y el hacking ético?
Ninguna en la práctica: OWASP usa los dos nombres para lo mismo, probar un sistema como lo haría un atacante para encontrar sus fallos. Lo que lo hace ético es el permiso por escrito, el alcance pactado y el informe para corregir.
¿Un pentest puede tirar mi web?
Puede pasar. NIST advierte de que un pentest puede dañar o dejar inoperativo un sistema y de que el riesgo nunca desaparece del todo. Se reduce excluyendo las pruebas de denegación de servicio, fijando un horario y teniendo un contacto de emergencia a mano.
¿Cada cuánto conviene hacerlo?
NIST considera que un pentest al año puede ser suficiente, combinado con escaneos de vulnerabilidades periódicos. Conviene repetirlo cuando cambias algo importante de la web, como el acceso de usuarios o los pagos.
¿Qué diferencia hay entre un pentest y una auditoría de seguridad?
El pentest intenta explotar los fallos para demostrar hasta dónde llegaría un atacante. La auditoría es más amplia: revisa también la configuración, la documentación y los procesos, y suele incluir un pentest entre sus pruebas.
Fuentes
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (septiembre de 2008), ficha en el CSRC
- NIST SP 800-115, texto completo en PDF, secciones 2.4, 5.2, 6.5, 6.6, 8.1 y 8.3
- OWASP Web Security Testing Guide, página del proyecto
- OWASP WSTG 4.2, índice y categorías de pruebas
- OWASP WSTG 4.2, introducción
- OWASP WSTG 4.2, metodologías de pentest
- OWASP WSTG 4.2, informe
- OWASP WSTG 4.2, introducción a las pruebas de lógica de negocio
- OWASP WSTG, publicación de la versión 4.2 (diciembre de 2020)
- OWASP Top 10:2025
- OWASP Top 10:2025, introducción (cambios respecto a 2021)
- OWASP Top 10:2025, Establishing a Modern Application Security Program
- OWASP ASVS 5.0.0 (mayo de 2025)
- FIRST, CVSS v4.0 Specification Document
- Código Penal, texto consolidado (BOE), arts. 197 bis y 264 bis
- Reglamento (UE) 2016/679, RGPD (BOE), arts. 28, 32 y 33
- AWS, Penetration Testing policy
- Google Cloud, aviso de pruebas de penetración
- Microsoft Security Response Center, Security Testing Rules of Engagement