Auditoría web: guía completa para empresas en 2026

Una auditoría web es un servicio profesional de evaluación técnica de seguridad sobre una aplicación HTTP/HTTPS, ejecutado por un equipo de especialistas externo, que termina con un informe documentando vulnerabilidades reproducibles, su impacto y la corrección recomendada. No es lo mismo que un escáner automático, no es lo mismo que una revisión de código y no es lo mismo que un test funcional. Una auditoría web seria identifica desde fallos de autorización (IDOR/BOLA, mass assignment) hasta lógica de negocio rota, pasando por inyecciones, problemas de criptografía, configuraciones inseguras y todo lo que el OWASP Top 10 cubre en su versión vigente.

Esta guía cubre qué incluye exactamente una auditoría web, cuándo conviene contratarla, los tres tipos de aproximación (caja blanca, negra, gris), el alcance típico, los entregables que puedes esperar, plazos realistas, los marcos de compliance que la requieren y cómo evaluar al proveedor antes de firmar.

Qué incluye una auditoría web profesional

Una auditoría web bien ejecutada combina cuatro tipos de pruebas:

1. Tests automatizados (Burp Suite Pro, OWASP ZAP, Nuclei, escáneres comerciales). Cubren vulnerabilidades conocidas, dan baseline rápido y descartan ruido.
2. Tests manuales (la parte que diferencia una auditoría seria). El auditor explora la aplicación como atacante real: encadena peticiones, manipula tokens, prueba flujos legítimos con valores no esperados.
3. Análisis de lógica de negocio. La parte donde más bugs serios aparecen y donde el escáner no llega: descuentos acumulables que dan precio negativo, transferencias entre cuentas que rompen el saldo, cupones que se canjean dos veces, secuencias de pago que saltan validaciones.
4. Auditoría de configuraciones e infraestructura asociada. Cabeceras HTTP de seguridad, TLS, cookies, CORS, almacenamiento de sesión, despliegue, dependencias.

Lo que cubre el OWASP Top 10 vigente y que cualquier auditoría web debería tocar: control de acceso roto (IDOR/BOLA), fallos criptográficos, inyección, diseño inseguro, configuración insegura, componentes vulnerables, fallos de autenticación, integridad de software y datos, fallos de logging y monitorización, SSRF. Detalle en OWASP Top 10 explicado para empresas.

Cuándo necesitas una auditoría web

Cinco escenarios donde no auditar es asumir riesgo difícil de justificar después:

1. Antes de un lanzamiento de producto público. La primera vez que la aplicación se expone a Internet, especialmente si maneja datos personales, pagos o autenticación.
2. Tras un cambio significativo. Refactor del módulo de autenticación, integración de SSO, despliegue de nueva pasarela de pago, migración de stack tecnológico.
3. Compliance recurrente. PCI DSS exige auditoría anual + tras cambios. NIS2 art. 21 exige eficacia probada de medidas técnicas. ISO 27001:2022 control 8.29 pide pruebas en el ciclo de vida.
4. Tras un incidente o intento de intrusión. Validar qué se rompió, si quedó persistencia y si los fixes aplicados realmente cierran el vector.
5. Auditoría inicial en una nueva organización (M&A, due diligence). Cuando entras en un grupo, compras una empresa o vas a fusionar plataformas.

Para muchos sectores la frecuencia mínima razonable es anual, con auditoría adicional tras cambios mayores. Sectores con compliance específico (banca con DORA, retail con PCI DSS, sector público con ENS) tienen frecuencia obligatoria que el regulador define.

Tipos de auditoría web: caja blanca, negra y gris

Los tres modelos cambian la información que el auditor recibe antes de empezar, y eso cambia la profundidad y el coste.

Caja negra

El equipo audita sin información previa. Sólo conoce la URL pública. Nadie del cliente le da credenciales, ni esquema de base de datos, ni código fuente.

Pros: simula a un atacante real que tampoco tiene esa información. Contras: tarda más en descubrir áreas que el cliente conoce desde dentro, no audita en profundidad zonas autenticadas, deja partes importantes de la aplicación fuera del alcance efectivo.

Cuándo conviene: para validar perímetro y la "primera barrera" de la aplicación.

Caja blanca

El equipo recibe credenciales de todos los roles, código fuente, esquema de base de datos, arquitectura, documentación interna.

Pros: máxima profundidad. Encuentra bugs que requieren conocer el dominio interno (race conditions sutiles, lógica de negocio compleja, deserialización en endpoints específicos). Contras: más caro y más largo. Puede saturar al auditor con información si el equipo del cliente no la organiza.

Cuándo conviene: aplicaciones críticas (banca, salud), nueva versión mayor antes de producción, software propio que vas a vender a otros.

Caja gris

El equipo recibe credenciales de los roles principales y descripción funcional, pero no el código fuente. Es el modelo intermedio.

Pros: mejor relación calidad/coste. Cubre la mayoría de bugs serios sin el coste extra de revisar código. Contras: ciega ante bugs que sólo emergen leyendo el código (deserialización en función concreta, hardcoded secrets en repositorio).

Cuándo conviene: la opción por defecto en la mayoría de auditorías web profesionales. Se usa en al menos 70% de los proyectos serios.

Más detalle sobre la decisión en diferencias entre auditoría caja blanca, negra y gris.

Alcance típico de una auditoría web

Lo que entra y lo que no entra suele acordarse en el scoping previo. Modelo razonable para una aplicación web mediana:

Dentro de alcance:

• Toda la URL pública del producto (frontend + endpoints API que consume).
• Todos los roles de usuario (anónimo, registrado, premium, admin si aplica).
• Flujos críticos: registro, login, recuperación de contraseña, pago, gestión de cuenta, exportación de datos.
• Lógica de negocio principal (carrito, transacciones, comunicaciones internas).
• Cabeceras HTTP, gestión de sesión, criptografía en tránsito, almacenamiento de credenciales.
• Subdominios directamente relacionados (api.dominio.com, admin.dominio.com).

Habitualmente fuera salvo que se acuerde explícitamente:

• Infraestructura cloud (AWS/Azure/GCP). Eso es una auditoría cloud distinta.
• DDoS y stress testing.
• Aplicación móvil que consume la misma API. Auditoría móvil específica, ver pentesting móvil iOS y Android.
• Ingeniería social y phishing dirigido a empleados.
• Pentesting físico de oficinas.

Cualquier ambigüedad se resuelve en el scoping antes de firmar. Un proveedor serio te pasa un documento de alcance detallado con los endpoints, roles y exclusiones explícitas.

Entregables de una auditoría web

Lo que esperas recibir al cierre:

• Informe ejecutivo (3-5 páginas). Resumen para dirección con riesgos principales, postura general y plan de acción priorizado.
• Informe técnico (40-200 páginas según volumen de hallazgos). Por cada vulnerabilidad: descripción, request HTTP exacto, captura, impacto de negocio, severidad CVSS justificada, recomendación de fix, referencia al estándar (OWASP, CWE, MITRE).
• Anexo con scripts y herramientas usados, si aplica.
• Debrief técnico con el equipo de desarrollo (1-2 horas) para resolver dudas.
• Retest tras los fixes, con informe diferencial confirmando qué hallazgos están cerrados.
• Certificado de auditoría (cuando aplica para cliente final o regulador) que documenta metodología, alcance, fechas y firmante.

Si el proveedor no entrega informe técnico con request HTTP reproducible y severidad CVSS justificada, no es auditoría sino escáner disfrazado.

Plazos realistas

Lo que tarda una auditoría web profesional, de inicio a entrega:

Total ciclo completo: 4-8 semanas desde primer contacto hasta retest cerrado, para una aplicación web mediana en caja gris.

Plazos comprimidos (auditoría en 5 días) suelen significar profundidad reducida o equipo desproporcionado. Ambas cosas penalizan la calidad.

Factores que determinan el precio

El presupuesto de una auditoría web depende de variables identificables antes de pedir oferta:

• Tipo de aproximación: caja blanca > caja gris > caja negra en orden de coste por jornada del equipo necesario.
• Tamaño del alcance: número de endpoints, módulos, roles, integraciones de terceros.
• Complejidad técnica: lógica de negocio elaborada, criptografía custom, multi-tenant, microservicios distribuidos elevan esfuerzo.
• Compliance objetivo: PCI DSS o pentest bajo DORA exigen evidencias y formato específicos que aumentan tiempo de redacción.
• Plazos: una auditoría con plazo agresivo cuesta más que una planificada con dos meses de antelación.
• Retest: incluir 1, 2 o N retests cambia la cifra final.

Lo más útil al comparar ofertas no es la cifra absoluta sino el coste por jornada-persona del equipo y la duración propuesta para el mismo alcance. Dos propuestas con la misma cifra final pueden esconder un factor de tres en horas reales dedicadas.

Compliance que requiere auditoría web

Marcos donde la auditoría web es exigible o muy recomendable:

• PCI DSS v4.0 (req. 11.4). Pentest interno y externo anual + tras cualquier cambio significativo. Obligatorio si se procesa pago directamente.
• NIS2 (artículo 21). Eficacia probada de medidas técnicas para servicios esenciales que se entreguen vía web.
• DORA (artículos 24-25). Pruebas de resiliencia operativa anual para entidades financieras.
• ENS (Real Decreto 311/2022, Marco Operacional). Auditoría técnica regular para sistemas de categoría media y alta del sector público.
• ISO 27001:2022 (control 8.29). Pruebas de seguridad documentadas en el SGSI.
• RGPD (artículo 32). Medidas técnicas apropiadas. La auditoría es la forma estándar de evidenciar diligencia técnica.

Pedir al proveedor que la propuesta indique a qué controles concretos del marco aplica el entregable simplifica la auditoría posterior.

Cómo elegir el proveedor de la auditoría web

Cinco criterios que filtran:

1. Equipo identificable y técnicamente activo. Nombres, certificaciones (OSCP, OSWE), referencias, charlas, advisories firmados.
2. Metodología trazable a OWASP WSTG y OWASP Top 10. Referencia explícita en la propuesta. Si dice "metodología propia" sin más, descarta.
3. Informe de muestra anonimizado. El entregable real, no la plantilla de marketing.
4. Retest incluido en el alcance original, no como extra.
5. Capacidad de adaptarse al sector. Auditar fintech, salud o sector público pide perfiles distintos.

Detalle en las guías hermanas: cómo elegir una empresa de pentesting y empresas de ciberseguridad en España.

Qué hacer después de la auditoría

El informe es el punto de partida, no el final del proceso:

1. Triage de hallazgos por riesgo real. No por severidad CVSS aislada sino por probabilidad de explotación y impacto de negocio.
2. Asignar fixes a sprint con responsable y fecha. Críticos primero, luego altos por categoría (autenticación, autorización, criptografía).
3. Validar fixes con retest. El retest convierte el informe en certificado utilizable ante auditores.
4. Integrar prevención en el SDLC. Lo que apareció una vez aparecerá otra si el proceso de desarrollo no cambia. Code review con checklist OWASP, SAST/DAST en CI/CD, formación específica para el equipo de desarrollo.
5. Planificar la siguiente auditoría. Anual mínimo o tras cambios significativos. La continuidad año tras año acelera porque el equipo aprende el contexto.

Preguntas frecuentes

¿Qué diferencia hay entre auditoría web y pentesting web?

En la práctica española los términos se usan como sinónimos. Técnicamente "auditoría" tiene matiz más amplio (incluye revisión documental, configuraciones, compliance) y "pentesting" se centra en la simulación ofensiva. Una propuesta seria cubre ambos componentes bajo cualquiera de los dos nombres.

¿Hace falta auditoría si ya tengo un escáner automatizado en CI/CD?

Sí. El escáner cubre vulnerabilidades conocidas con firma. No detecta lógica de negocio rota, autorización granular, encadenamientos de peticiones, race conditions o cualquier bug que requiera entender el dominio. La auditoría manual ataca exactamente ese gap. Combinar ambos es la práctica correcta: escáner continuo + auditoría manual periódica.

¿Tiene que parar la aplicación durante la auditoría?

No, salvo que se acuerde lo contrario. Una auditoría profesional se ejecuta sobre el entorno acordado (preproducción idealmente, producción si es la única opción) sin afectar disponibilidad. Pruebas que pueden afectar (fuzzing pesado, exploit con probabilidad de tirar el servicio) se acuerdan en alcance y se ejecutan en ventana fuera de horas críticas.

¿Cuántas vulnerabilidades suelen aparecer en la primera auditoría?

En aplicaciones nunca auditadas, lo habitual son entre 10 y 50 hallazgos clasificados (3-8 críticos o altos, el resto medios y bajos). Aplicaciones que llevan ciclos auditadas terminan con 5-15 hallazgos en cada auditoría posterior, sobre todo medios y bajos. Un informe limpio total al primer intento es muy raro y, si aparece, conviene cuestionar la profundidad del trabajo.

¿Sirve la auditoría para certificar ISO 27001 o cumplir PCI DSS?

La auditoría es uno de los elementos de evidencia que el auditor de certificación pide, pero no es certificación en sí misma. Para ISO 27001 cubre el control 8.29 y aporta material al auditor del SGSI. Para PCI DSS v4.0 cumple el requisito 11.4 si la metodología y el equipo cumplen los criterios. La certificación final la emite la entidad acreditada (en España AENOR, BSI, Bureau Veritas, AENOR Internacional, entre otros).

¿Cuánto tarda en arreglarse todo lo que aparece?

Depende mucho del volumen y la organización. Un equipo de desarrollo razonable cierra los hallazgos críticos en 2-4 semanas, los altos en 1-2 meses, los medios y bajos pueden distribuirse en sprints durante 3-6 meses. Lo importante es priorizar bien y documentar la decisión cuando un hallazgo se acepta como riesgo residual en lugar de cerrarse.

Recursos relacionados

• Pentesting de aplicaciones web: la metodología técnica detallada que aplica el equipo durante la auditoría.
• OWASP Top 10 explicado para empresas: el catálogo de referencia que cubre cualquier auditoría seria.
• Diferencias entre auditoría caja blanca, negra y gris: cómo elegir la profundidad correcta.
• Cómo elegir una empresa de pentesting: criterios concretos para evaluar al proveedor.
• Empresas de ciberseguridad en España: contexto de mercado para la decisión.

Auditoría web en Secra

En Secra ejecutamos auditorías web sobre OWASP WSTG y OWASP Top 10 vigente, en modalidad caja gris por defecto (caja blanca y negra disponibles según necesidad), con informe ejecutivo separado del técnico, prueba de concepto reproducible por hallazgo, severidad CVSS justificada, retest incluido y mapeo a NIS2, DORA, ENS, ISO 27001 o PCI DSS según aplique. El equipo publica investigación propia (advisories CVE-2025-40652 y CVE-2023-3512 firmadas en NVD e INCIBE-CERT). Si quieres una propuesta concreta para tu aplicación, escríbenos a través de contacto o consulta el detalle del servicio de auditoría web y móvil.