OWASP WSTG · ASVS · CVSS 4.0 · PCI DSS · ISO 27001 · ENS · NIS2 · DORA

Auditoría de seguridad de aplicaciones web

Auditoría manual y automatizada sobre tu aplicación web. Metodología OWASP WSTG, verificación ASVS, cobertura ancha y profundidad humana en lógica de negocio. Cada hallazgo con evidencia, severidad CVSS 4.0 y remediación priorizada por riesgo real, no por puntuación teórica. Evidencia válida para auditor externo.

Agendar reunión · 30 min Ver alcance técnico

OWASP Top 10 + WSTG Lógica de negocio Multi-tenant SaaS API REST · GraphQL OAuth · SSO · SAML CVSS 4.0 + riesgo real Revalidación incluida

Resumen ejecutivo

Una auditoría web hecha en serio es un proyecto que combina cuatro cosas: cobertura amplia guiada por OWASP WSTG, profundidad humana en lógica de negocio que ningún escáner detecta, evidencia técnica suficiente para que un auditor externo (PCI QSA, certificador ISO, organismo ENS) acepte el informe, y un plan de remediación priorizado por riesgo real considerando explotabilidad y exposición, no solo CVSS teórico.

En Hard2bit los proyectos típicos cierran entre 7 y 40 días laborables según complejidad, con notificación inmediata de hallazgos críticos durante la ejecución y revalidación posterior incluida en el alcance. El informe se entrega listo para sostener auditoría externa: índice por familia OWASP, matriz priorizada, evidencia firmada con timestamps, informe ejecutivo separado para dirección.

Cobertura ancha + profundidad

OWASP WSTG completo + ASVS L2/L3 + lógica de negocio + APIs. No es escaneo: es pentester con tiempo y método.

Evidencia auditor-ready

Pensado para que pase auditoría externa: PCI QSA, certificador ISO 27001, auditor ENS, requerimiento NIS2/DORA.

Remediación útil

Hallazgos priorizados por riesgo real (explotabilidad, exposición, impacto de negocio), no solo por puntuación CVSS.

Qué cubrimos en una auditoría web

El alcance se ajusta a cada aplicación, pero la base técnica es siempre la misma. Cubrimos el OWASP Web Security Testing Guide como guía de cobertura, ASVS L2 o L3 según criticidad como criterios de verificación, y elementos específicos del sector cuando aplica: PCI DSS para entornos de pago, criterios ENS Alta para sector público, requisitos DORA para entidades financieras, controles propios del cliente cuando hay normativa sectorial adicional.

Autenticación y sesión

Recuperación de contraseña, MFA, bypass de login, fijación de sesión, JWT mal firmados, OAuth client-side, SSO/SAML, expiración, regeneración tras autenticar, lockout y enumeración de usuarios.

Control de acceso

IDOR (Insecure Direct Object Reference), escalada vertical y horizontal, bypass de roles, control de acceso a recursos, multi-tenant: que el cliente A no acceda a datos del B incluso con IDs predecibles.

Inyección

SQL, NoSQL (Mongo, DynamoDB), comandos OS, LDAP, XPath, plantillas (SSTI: Jinja, Twig, Velocity), expresiones (EL, OGNL), deserialización insegura (Java, .NET, PHP, Python).

XSS y SSRF

Reflejado, almacenado, DOM-based, ciegos. SSRF clásico y blind, abuso de metadata de cloud (IMDS), pivot a infraestructura interna, redirección a servicios internos no expuestos.

Lógica de negocio

Abuso de flujos legítimos: aprobaciones sin permiso, condiciones de carrera, manipulación de precios en checkout, bypass de límites, encadenamientos imposibles según diseño.

Exposición de datos

Datos sensibles en respuestas innecesarias, mensajes de error verbosos con stack trace, headers que revelan stack, repositorios públicos con secretos, archivos de configuración accesibles.

APIs asociadas

OWASP API Top 10: BOLA (autorización a nivel de objeto), BOPLA (a nivel de propiedad), BFLA (a nivel de función), exposición masiva, falta de rate limiting, abuso de endpoints.

Gestión de ficheros

Subida sin validación de tipo real, path traversal, sobrescritura de ficheros del sistema, ejecución de ficheros subidos, abuso de extensiones dobles, ZIP slip, SVG con JavaScript.

Configuración del servidor

Cabeceras de seguridad (CSP, HSTS, X-Frame-Options, Referrer-Policy), CORS mal configurado, cookies sin Secure/HttpOnly/SameSite, banners que revelan versión, métodos HTTP innecesarios.

Criptografía aplicada

Algoritmos débiles (MD5, SHA-1), generación de tokens predecible, TLS mal configurado, certificados caducados, secretos en localStorage, IVs reutilizados.

Defensa anti-bot y abuso

Rate limiting, CAPTCHA, prevención de credential stuffing, prevención de account takeover, detección de comportamiento anómalo si aplica.

Cliente y JavaScript

Validaciones que viven solo en cliente, secretos embebidos en bundles, fuentes de datos sensibles en localStorage/sessionStorage, postMessage inseguro, eventos DOM mal validados.

Anatomía de un hallazgo crítico

Para que se vea qué entendemos por auditoría hecha en serio, este es el patrón técnico de un hallazgo crítico real, anonimizado. Un IDOR con bypass de tenant en una plataforma SaaS B2B mediana. El patrón se repite en variantes en muchísimos productos.

Descubrimiento

Patrón detectado

Endpoint GET /api/v2/exports/{exportId}/download servía un fichero firmado con URL temporal. La firma se generaba sobre el exportId, no sobre la combinación tenantId+exportId. Al iterar exportIds adyacentes (los IDs eran secuenciales) se descargaban exportaciones de otros tenants sin necesidad de re-firmar. El frontend filtraba por tenant pero el backend no validaba la pertenencia del exportId al tenant del usuario autenticado.

Severidad

CVSS 4.0 = 9.3 (Crítica)

AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N. Acceso de red, complejidad baja, requiere cuenta válida en cualquier tenant. Impacto: confidencialidad alta (datos de cualquier cliente del SaaS), integridad y disponibilidad no afectadas. Pero el riesgo real no se mide solo con CVSS: los exports contenían datos personales protegidos por RGPD, lo que elevaba el impacto regulatorio a notificación a AEPD en 72 horas si se confirmaba explotación.

Evidencia

Prueba sin explotación masiva

Demostración con 2 cuentas de prueba creadas en tenants distintos del propio cliente. Captura de request/response autenticado de tenant A descargando export de tenant B. Sin tocar datos de clientes reales en producción. La auditoría documenta el patrón, no extrae datos del cliente final. Ética básica.

Remediación

Doble capa

Inmediato (8 horas): añadir validación tenantId == session.tenantId en el handler del endpoint. Medio plazo (2 semanas): generar URLs firmadas que incluyan el tenantId en el payload del HMAC, de forma que la firma quede invalidada si se cambia el exportId al de otro tenant. Largo plazo: revisar todos los endpoints de recursos por ID buscando el mismo patrón. Se encontraron otros 3 con el mismo defecto.

Caso técnico anonimizado basado en patrones reales del sector SaaS B2B. Sector, magnitudes y nombres alterados; el patrón técnico y la mecánica de remediación mantienen fidelidad al original. Sin NDAs públicos, sin nombre de cliente.

Cuándo encaja y cuándo no

Encaja muy bien

Cuándo merece la pena

Aplicación que sale a producción por primera vez o lanza versión mayor
Tu cliente o auditor te exige evidencia (PCI DSS, ENS Alta, ISO 27001, NIS2, contrato enterprise)
Sospecha de fuga, incidente o anomalía sin diagnóstico claro
Cambio de proveedor de desarrollo y quieres baseline antes de heredar
SaaS multi-tenant que crece y necesita validación de aislamiento
Producto con módulo de pago, datos sensibles o flujo de aprobación crítico
Plataforma con APIs públicas o consumidas por terceros (DORA, NIS2)
Aplicación que va a manejar datos de salud, financieros o de menores

Encaja menos

Cuándo no es lo primero

Aplicación con menos de 6 meses en producción y sin tráfico real: hay que dejarla madurar antes
Aún no hay arquitectura estable: cualquier hallazgo cambia en el próximo release
El problema no es técnico sino de proceso (revisión de código inexistente, secretos en repos): empezar por auditoría de código
Necesitas vigilancia continua, no puntual: encaja mejor un programa con gestión de superficie de ataque
Has sufrido un incidente concreto y necesitas contención y análisis forense, no auditoría: respuesta a incidentes
Estás en fase de diseño y quieres anticipar amenazas: mejor un threat modeling previo

Cómo lo entregamos

Cuatro fases reales, ningún paso teórico. El cliente conoce los hallazgos críticos antes de que termine la auditoría, no en una entrega sorpresa al final. Esto cambia el coste real del proyecto para el cliente: se puede empezar a remediar mientras se sigue auditando.

1. Walkthrough técnico (1-2 días)

Sesión con responsable de la aplicación, perfilado de usuarios, alcance acordado, ventana de pruebas, IPs origen, plan de comunicación con TI. Si hay WAF, decidimos si lo dejamos activo (auditoría realista) o lo desactivamos en la ventana (cobertura máxima). Si hay SOC propio o gestionado, le pre-notificamos para evitar falsos positivos en su flujo.

2. Auditoría manual y automatizada (60-80% del tiempo)

Combinación de Burp Suite Pro, OWASP ZAP, herramientas propias y trabajo manual. Los hallazgos críticos se notifican al cliente en el momento por canal acordado (no se guardan para el informe final). La auditoría no es un escaneo: es un pentester pensando como atacante con tiempo y método. Documentamos cada test ejecutado, no solo los hallazgos, para que el auditor externo vea cobertura real.

3. Documentación y verificación

Cada hallazgo con descripción, evidencia (capturas, request/response, exploit de prueba), CVSS 4.0, criticidad de negocio, riesgo real considerado y recomendación. Verificamos cada hallazgo dos veces para evitar falsos positivos en el informe ejecutivo. El informe ejecutivo se redacta sin jerga técnica para que sirva al consejo o a dirección.

4. Cierre y revalidación

Sesión de 90 minutos con TI y desarrollo para discutir hallazgos, prioridad real y plan de remediación. Si el cliente lo necesita, revalidación a las 4-8 semanas para certificar que las correcciones funcionan. Esto suele ser lo que pide auditor externo o cliente regulado: no basta con el informe, hace falta segunda pasada que cierre el ciclo.

Qué incluye el paquete documental

Cinco piezas que viajan juntas al cierre del proyecto. Pensadas para que el cliente pueda presentar el material a auditor externo, certificador o cliente final sin trabajo adicional de adaptación.

1. Informe técnico

Cada hallazgo con descripción, evidencia (capturas + request/response + exploit), CVSS 4.0, criticidad de negocio, condiciones de explotación, recomendación de remediación y prueba de validación.

2. Informe ejecutivo

2-3 páginas para dirección sin jerga técnica. Hallazgos críticos en términos de negocio, riesgo agregado, plan de acción y plazos. Apto para consejo.

3. Matriz priorizada

Tabla con todos los hallazgos ordenados por riesgo real (CVSS + exposición + explotabilidad + impacto de negocio + esfuerzo de remediación). Lista de actuación práctica para desarrollo.

4. Repositorio de evidencias

Pack ZIP con todas las evidencias firmadas con timestamps, hash de los ficheros, logs de las pruebas realizadas. Para auditor externo o cliente regulado.

5. Sesión de cierre

90 minutos en remoto o presencial con TI y desarrollo. Discusión de hallazgos, prioridad, plan de remediación. Preguntas y respuestas con el equipo de auditoría.

Extra: revalidación

Si se contrata, segunda pasada a las 4-8 semanas para certificar que las correcciones funcionan. Carta de verificación firmada para auditor externo.

Adaptación por sector

El alcance estándar es el mismo, pero cada sector tiene un peso distinto en ciertas áreas y obligaciones regulatorias específicas. Ajustamos el foco sin reinventar la metodología.

SaaS B2B y producto tecnológico

Foco intensivo en aislamiento multi-tenant, gestión de tokens y API keys, OAuth, BOLA y autorización a nivel de objeto. Demanda alta de evidencia para responder cuestionarios de seguridad de clientes enterprise. Compatible con SOC 2 si aplica.

Fintech y entidades financieras

Foco en módulos de pago (PCI DSS 11.4.3), API security (DORA art. 24-27), flujos de aprobación, race conditions en transferencias, prevención de fraude. Requiere coordinación con SOC interno o gestionado.

Sanidad

Foco en exposición de datos de salud (RGPD art. 9), auditoría de logs de acceso a historia clínica, control de acceso por rol médico/administrativo, integraciones con HL7/FHIR. Si aplica ENS Alta (operadores esenciales de sanidad), incluye op.exp.5.

AAPP y sector público

Foco en cumplimiento ENS Alta o Media según categorización del sistema, accesibilidad WCAG cuando aplique, control de identidades con Cl@ve y certificados digitales, protección de información clasificada según ley.

Retail y e-commerce

Foco en módulos de pago (PCI DSS), prevención de fraude, abuso de cupones y descuentos, scraping malicioso, lógica de carrito (manipulación de precio), gestión de stock concurrente.

Industria y OT con interfaz web

Foco en aplicaciones de gestión que conectan con planta (MES, SCADA web), control de acceso, segmentación lógica entre TI y OT, auditoría de comandos que puedan afectar a proceso industrial.

Encaje regulatorio

La auditoría de seguridad de aplicaciones web es exigida directa o indirectamente por casi todos los marcos que aplican a empresa en España. El informe técnico se entrega listo para que pase auditoría externa en cualquiera de ellos.

Marco	Referencia	Qué exige y cómo lo cubrimos
PCI DSS v4.0.1	Req. 11.4.3	Pentest de aplicaciones que toquen el CDE, anual y tras cambios significativos. Informe técnico + remediación verificable. Apto para PCI QSA.
ISO 27001:2022	A.8.29 / A.8.8	Pruebas de seguridad en el ciclo de desarrollo y gestión de vulnerabilidades técnicas. Evidencia trazable para certificación.
ENS (Alta)	op.exp.5	Pruebas técnicas de seguridad periódicas con documentación de hallazgos y remediación. Apto para auditoría ENS por entidad acreditada.
NIS2	Art. 21.2.f	Políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos. Periodicidad documentada.
DORA	Art. 24-27	Programa de pruebas de resiliencia digital, incluyendo testing de aplicaciones críticas. Apto para inspección de supervisor.
RGPD	Art. 32.1.d	Procedimiento de verificación, evaluación y valoración regular de la eficacia de medidas técnicas y organizativas. Especialmente relevante si hay datos especiales (art. 9).
Esquema de Confianza CCN	Si aplica	Para soluciones que entren en ENS y requieran certificación CCN, la auditoría sostiene los requisitos de evaluación técnica.

Lo que solemos hacer y otros no

No es marketing, son prácticas que cuestan tiempo y que vemos rara vez en informes de competencia. Si tu auditoría no incluye estos puntos, mereces preguntar por qué.

Notificación inmediata de críticos

Si encontramos un hallazgo crítico en día 3 de una auditoría de 15 días, te lo notificamos ese día. No esperamos al informe final para que pierdas dos semanas más de exposición.

Revalidación incluida en la propuesta

El precio cubre segunda pasada de verificación a las 4-8 semanas tras remediación. Es lo que tu auditor externo va a pedir; te lo damos sin extra.

Ejemplos de remediación, no solo descripción

Cada hallazgo trae al menos una recomendación accionable concreta (snippet de código corregido, configuración exacta, librería recomendada). Lo opuesto al 'aplique controles adecuados'.

Pruebas con tu WAF activo (no solo sin él)

Demasiados informes desactivan WAF y reportan hallazgos que tu WAF ya bloquea. Hacemos ambos: realista con WAF + cobertura máxima sin WAF en ventana acordada.

Sesión de cierre con desarrollo, no solo con seguridad

Los hallazgos los remedia el equipo de desarrollo. Si solo hablamos con CISO, la información se pierde en traducción. Sentamos al pentester con el dev.

Repositorio de evidencias firmado

ZIP con timestamps, hashes, logs de pruebas. Para que tu auditor externo no tenga que confiar en tu palabra: hay material verificable y reproducible.

Objeciones que escuchamos y cómo las contestamos

«Ya tenemos pentest interno, no necesitamos externo»

Pentest interno es bueno y necesario, pero tiene tres limitaciones: el equipo conoce demasiado bien la aplicación (no piensa como atacante externo), tiene presiones de equipo de producto que pueden suavizar hallazgos, y casi nunca produce evidencia válida para auditor externo (que no admite informe firmado por la propia empresa). Ambos enfoques se complementan; ninguno sustituye al otro.

«Es caro. ¿Compensa?»

Depende del coste de un incidente. Un IDOR explotado en SaaS multi-tenant que filtra datos personales son: notificación a AEPD (multa potencial 4% facturación), pérdida de clientes enterprise por incumplimiento contractual, coste de DFIR (15-50 mil euros), coste de remediación urgente (40-80 mil euros), coste reputacional (incalculable). Una auditoría que cuesta 15-25 mil euros y previene esto es la inversión más rentable que vais a hacer este año.

«No tenemos tiempo para parar la aplicación»

No hay que parar. La auditoría se hace en producción con plan de comunicación con TI, IPs origen acordadas y exclusión de pruebas destructivas. O se hace en preproducción con datos representativos. Lo que sí tiene que ocurrir: alguien técnico del cliente disponible para preguntas urgentes durante la ventana, no más de 4-6 horas distribuidas.

«Nuestra aplicación es muy compleja, dudo que la entendáis a fondo»

El walkthrough técnico previo (1-2 días) está pensado exactamente para eso. Si tras el walkthrough nos parece que el alcance excede lo que podemos hacer bien en el tiempo disponible, te lo decimos honestamente y proponemos partir en dos proyectos o reducir alcance. Lo que no hacemos: prometer cobertura completa de una aplicación enorme en 5 días para cerrar la venta.

«Ya nos hicieron auditoría hace 2 años, no ha cambiado tanto»

OWASP Top 10 ha cambiado (2017→2021→nueva en preparación). OWASP API Top 10 es nueva (2019, 2023). CVSS pasó de 3.1 a 4.0. La amenaza de identidades no humanas y supply chain ha explotado en 2024-2025. Si tu aplicación tiene 2 años sin auditar, el catálogo de cosas que mirar ha cambiado más que tu aplicación.

«Solo queremos cumplir, no encontrar nada»

Lo entendemos pero no es nuestro target. Si lo único que necesitas es un check-the-box para auditor sin que te encuentren hallazgos reales, hay proveedores que hacen eso. Nosotros no. Nuestro informe encuentra cosas; las que se encuentren las tendrás que remediar. Si eso es problemático para tu organización, mejor que sea explícito antes de firmar.

Cómo medimos calidad de nuestras auditorías

Internamente medimos los proyectos en cinco indicadores que comparamos contra benchmark propio histórico. No los publicamos como cifras porque varían mucho según proyecto, pero sí los compartimos en la sesión de cierre para que tu equipo vea cómo ha quedado vuestro proyecto frente al estándar interno.

Cobertura WSTG real

Porcentaje de tests del OWASP WSTG ejecutados en el proyecto. Apuntamos a 85%+ en auditorías estándar.

Ratio crítico/alto

Proporción de hallazgos críticos y altos respecto al total. Indicador de profundidad: una auditoría sin críticos en aplicación grande suele significar cobertura insuficiente.

Falsos positivos en informe

Porcentaje de hallazgos rechazados por cliente tras verificación. Objetivo: <3%. Si supera el 10%, el equipo revisa metodología.

Tiempo medio de notificación crítico

Horas desde detección de un hallazgo crítico hasta notificación al cliente. Objetivo: <8 horas laborables. Habitualmente bajo 4h.

Hallazgos por día auditor

Productividad del equipo. Sirve para detectar si una auditoría va por debajo de profundidad esperada y conviene reasignar.

Tasa de revalidación cerrada

Porcentaje de hallazgos que el cliente cierra realmente en revalidación. Indicador de calidad de la recomendación: si no se pueden aplicar, las recomendaciones eran malas.

Errores habituales al contratar una auditoría web

Pedir el precio más bajo y aceptar una auditoría de 3 días. Lo que recibís es un escaneo automatizado disfrazado, sin lógica de negocio ni evidencia útil para auditor externo.
No dar acceso a un usuario autenticado. Sin sesión, el auditor solo prueba el 10% de la aplicación (lo público). El 90% del riesgo está detrás del login.
Contratar pentest justo antes de salir a producción y querer remediar todo en 48 horas. La auditoría revela trabajo que no estaba en el roadmap; planifica ventana de remediación realista.
Confundir auditoría con revisión de código. Son complementarias: la auditoría prueba el comportamiento desde fuera; la revisión de código encuentra fallos invisibles desde fuera (lógica defectuosa, secretos hardcoded, dependencias vulnerables).
Dejar el WAF en silencio durante toda la auditoría. Eso falsifica cobertura. Mejor: WAF activo para auditoría realista + ventana sin WAF para cobertura máxima en hallazgos serios.
No revalidar tras remediar. Si no hay segunda pasada que verifique las correcciones, el informe es papel mojado para auditor regulatorio.
Confundir CVSS alto con prioridad alta. Un CVSS 9 sin exposición real (endpoint solo accesible desde red interna gestionada) puede ser menos urgente que un CVSS 6 con explotación trivial en producción.
Pedir solo informe ejecutivo. Sin informe técnico tu equipo no puede remediar y tu auditor externo no acepta el material como evidencia.

Glosario rápido de la jerga del informe

Términos que aparecen en informes de auditoría web y que conviene tener claros antes de empezar.

OWASP WSTG

Web Security Testing Guide. Estándar de cobertura para pentest de aplicación web mantenido por OWASP.

OWASP ASVS

Application Security Verification Standard. Criterios verificables por niveles (L1, L2, L3) para auditar la seguridad de aplicación.

OWASP Top 10

Ranking de las 10 categorías de vulnerabilidades más críticas en aplicación web. Versión 2021; nueva en preparación.

OWASP API Top 10

Versión equivalente para APIs. Actualizada en 2023. Incluye BOLA, BFLA, BOPLA, etc.

IDOR

Insecure Direct Object Reference. Acceso a recursos cambiando un ID en URL/payload sin que el backend valide pertenencia.

SSRF

Server-Side Request Forgery. Forzar al servidor a hacer peticiones a recursos internos no expuestos (incluyendo metadata de cloud).

BOLA / BFLA / BOPLA

Bypass de autorización a nivel de Objeto / Función / Propiedad. Categorías OWASP API Top 10.

CVSS 4.0

Common Vulnerability Scoring System v4. Sistema estándar de puntuación de criticidad. Sustituye a CVSS 3.1.

SAST / DAST

Static / Dynamic Application Security Testing. Análisis estático (sobre código) o dinámico (sobre la app corriendo).

WAF

Web Application Firewall. Capa de filtrado entre internet y la aplicación; bloquea ataques conocidos por patrones.

CDE (PCI DSS)

Cardholder Data Environment. Conjunto de sistemas, redes y procesos que tocan datos de tarjeta. Requiere pentest periódico.

BOM / SBOM

Software Bill of Materials. Inventario de componentes y dependencias del software. Cada vez más exigido por NIS2/DORA.

Servicios relacionados en Hard2bit

La auditoría de aplicaciones web encaja en un programa más amplio. Estos son los servicios que más se combinan con ella en proyectos reales.

Pentesting

Servicio madre. Web es una de las disciplinas que cubrimos dentro del pentesting enterprise.

Ver →

Auditoría de seguridad API

Si tu API es la pieza central (SaaS, fintech, integraciones B2B), pentest dedicado a OWASP API Top 10.

Ver →

Auditoría de código fuente

Complementaria a la web: encuentra fallos invisibles desde fuera (lógica, secretos, dependencias).

Ver →

Identidades no humanas

Tokens, OAuth, cuentas de servicio, API keys: el otro 50% del riesgo moderno de aplicación.

Ver →

Hardening y bastionado

Tras la auditoría, fortalecer la base sobre la que corre la aplicación: SO, servidor, cabeceras, configuración.

Ver →

Auditoría integral

Cuando además de web hay infraestructura, identidad, cloud y procesos: un único proyecto.

Ver →

Gestión superficie de ataque

Vigilancia continua tras la auditoría puntual. Para que el siguiente release no introduzca regresiones.

Ver →

Red team

Cuando además de auditoría técnica quieres validar capacidad de detección y respuesta del equipo defensivo.

Ver →

Respuesta a incidentes

Si la auditoría revela hallazgos que apuntan a compromiso activo, escalado inmediato a equipo de respuesta.

Ver →

Preguntas frecuentes

¿Qué diferencia hay entre una auditoría manual y pasar un escáner DAST?

Un escáner DAST detecta patrones conocidos en minutos y a bajo coste: librerías obsoletas, configuraciones débiles, vulnerabilidades catalogadas tipo XSS reflejado o SQL injection clásico. Lo que un escáner nunca encontrará es lo que aporta valor real: fallos de lógica de negocio (un usuario que aprueba sus propias facturas, condiciones de carrera en transferencias, manipulación de precios en checkout), encadenamientos de baja severidad que producen impacto crítico, bypass de roles específicos a tu modelo de datos, abuso de flujos legítimos. En auditorías reales el 30-60% de los hallazgos críticos requieren análisis humano y no aparecen en ningún escáner. Por eso combinamos ambos: el escáner cubre la superficie ancha, el auditor humano va a profundidad donde hay riesgo de negocio real.

¿Qué metodología seguís exactamente?

Tenemos cuatro referencias normativas que estructuran el trabajo: OWASP Web Security Testing Guide (WSTG) como base de cobertura, OWASP ASVS L2 o L3 según criticidad como criterios de verificación, OWASP Top 10 como check de mínimos, y elementos de PTES y NIST SP 800-115 para reporting y ética. El alcance estándar incluye autenticación, gestión de sesión, control de acceso vertical y horizontal, inyección SQL/NoSQL/comandos/LDAP/SSTI, XSS, SSRF, deserialización insegura, exposición de datos, lógica de negocio, gestión de ficheros, configuración del servidor y APIs asociadas. Para SaaS B2B añadimos pruebas de aislamiento entre tenants (que el cliente A no acceda a datos del cliente B). Para entornos PCI DSS, los requisitos del estándar mandan checklist específico.

¿Cuánto dura una auditoría web típica y cuánto cuesta?

Una aplicación web mediana (5-15 endpoints relevantes, 2-3 perfiles de usuario, autenticación estándar, sin lógica de negocio especialmente compleja) se audita en 7-15 días laborables con 1-2 auditores. Coste orientativo en España: 8.000-20.000 euros. Aplicaciones complejas con multitenant, integraciones críticas, lógica de negocio densa, módulos de pago o flujos regulados se mueven en 20-40 días y 25-50 mil euros. Para evitar sustos pedimos siempre acceso a la aplicación antes de presupuestar firme; un walkthrough de 30 minutos cambia la estimación más que cualquier brief escrito. Lo que no hacemos: cotizar a ciegas en un email.

¿Hace falta entorno de preproducción o auditáis en producción?

Lo preferimos en preproducción con datos representativos (anonimizados si proceden de producción real). En producción es viable pero exige acordar ventana, IPs origen, cobertura de WAF/CDN, plan de comunicación con TI y exclusión de pruebas destructivas (DoS, modificaciones masivas, reset de cuentas reales). En entornos PCI DSS, ENS Alta o NIS2 la auditoría en producción se documenta como prueba controlada con timestamps, para evitar que un equipo de seguridad propio responda como si fuera un incidente real. Y si tienes SOC interno o gestionado, le avisamos previamente para no generar falsos positivos en su flujo.

¿Qué entregables damos al final del proyecto?

Cinco piezas: (1) Informe técnico con cada hallazgo descrito, evidencia con capturas y request/response, criticidad CVSS 4.0 + criticidad de negocio, recomendación de remediación; (2) Informe ejecutivo de 2-3 páginas para dirección sin jerga; (3) Matriz priorizada por riesgo real, no solo CVSS, considerando exposición y explotabilidad; (4) Repositorio de evidencias firmado con timestamps para auditoría regulatoria; (5) Sesión de cierre con TI y desarrollo para discutir hallazgos y plan de remediación. Si el cliente lo necesita, revalidación posterior incluida en el alcance para certificar que las correcciones son efectivas. Los entregables están pensados para que sirvan tanto al equipo técnico como al auditor externo (PCI QSA, certificador ISO, auditor ENS).

¿Sirve como evidencia para PCI DSS, ISO 27001, ENS o NIS2?

Sí, cuando se documenta correctamente. PCI DSS v4 (requisito 11.4.3) exige pentest de aplicaciones que toquen el CDE con periodicidad anual y tras cambios significativos. ENS categoría Alta (op.exp.5) exige pruebas técnicas de seguridad periódicas. ISO 27001:2022 (A.8.29) requiere testing de seguridad en el ciclo de desarrollo. NIS2 (artículo 21.2.f) exige políticas y procedimientos para evaluar eficacia de medidas. DORA (artículos 24-27) regula pruebas de resiliencia digital. El informe técnico + ejecutivo + matriz de remediación con timestamps cumple los requisitos documentales de los cinco marcos. Si tu QSA o auditor pide algo adicional, lo añadimos sin cobrar extra: el documento se entrega para que pase auditoría externa.

¿Auditáis solo la aplicación o también la API que la sustenta?

Si en el alcance hay una API, la auditamos como parte del mismo proyecto: la mayoría de los fallos críticos modernos están en la API, no en la UI. La aplicación es la fachada; la API es donde vive la lógica de negocio y donde un atacante encuentra IDOR, bypass de autorización a nivel de objeto/función (BOLA/BOPLA), exposición masiva de propiedades, etc. Para clientes que necesiten foco específico en API (por volumen, complejidad o porque la API se consume desde varias aplicaciones cliente o desde móvil), tenemos servicio dedicado de auditoría de seguridad API que cubre OWASP API Top 10 completo. Lo habitual es contratar ambos servicios o uno con alcance combinado.

Tenemos múltiples microservicios y APIs. ¿Cómo lo auditáis?

Empezamos con sesión de arquitectura para entender el grafo: qué microservicios hay, cómo se autentican entre ellos, qué APIs son públicas vs internas, qué cuentas de servicio existen. Auditamos por capas: frontend público, gateway/BFF, microservicios internos, autenticación entre servicios (mTLS, JWT, OAuth client credentials), cuentas de servicio y secretos. Para microservicios añadimos siempre revisión de seguridad de identidades no humanas, que es donde más se ha visto compromisos de cadena lateral en 2024-2025. Si la arquitectura es muy distribuida, sugerimos partir en dos proyectos para que cada uno se haga con profundidad real.

¿Qué hacéis si encontráis algo crítico durante la auditoría?

Notificación inmediata por canal acordado previamente (mail cifrado, Signal, llamada). No esperamos al informe final. El cliente recibe el hallazgo con descripción, evidencia, impacto estimado y recomendación de contención temporal. Si el cliente lo solicita, ayudamos a coordinar la remediación urgente con su equipo de desarrollo. La diferencia entre 'reportamos en informe final' y 'reportamos al detectar' son semanas de exposición que se evitan. Cuando un hallazgo es severidad crítica con explotación trivial, no tiene sentido guardárselo dos semanas.

¿Cómo arrancamos un proyecto en Hard2bit?

Empezamos con una llamada de 30 minutos para entender la aplicación, el alcance, los perfiles de usuario, el momento del ciclo (release, post-incidente, exigencia regulatoria) y el objetivo del cliente. Si tiene sentido, agendamos walkthrough técnico de 1 hora con el responsable de la aplicación. Con eso emitimos propuesta firme en 48-72 horas: alcance, ventana, equipo asignado, entregables y precio cerrado. Sin compromisos hasta la firma. Si después del walkthrough creemos que lo que necesitas no es una auditoría web sino código fuente, API o un programa de gestión continua de superficie de ataque, te lo decimos honestamente y derivamos al servicio correcto.

¿Tienes una aplicación que necesita auditoría?

Llamada de 30 minutos para entender el alcance, los perfiles de usuario y el momento del ciclo. Si tiene sentido, propuesta firme en 48-72 horas: alcance cerrado, equipo asignado, entregables y precio. Sin compromisos hasta la firma.

Agendar reunión · 30 min Contactar