OWASP

Enfoques: caja negra, caja gris y caja blanca

Un marco de referencia dice qué hay que probar; el enfoque decide cuánta superficie se puede cubrir de verdad con un número de jornadas dado. Los tres conviven en el mercado español y ninguno es «el correcto» en abstracto; en la gran mayoría de los proyectos recomendamos el segundo.

Caja negra (black box)

Partimos de una dirección, sin cuentas ni documentación, como quien ataca desde fuera. El enfoque mide bien la exposición pública. Su límite es mecánico: una parte del presupuesto se va en reconocimiento y todo lo que hay detrás de la autenticación queda fuera de alcance, que es justo donde se concentra la categoría A01.

Caja gris (grey box)

Trabajamos con una cuenta por rol y una descripción funcional de la aplicación. Es el enfoque por defecto y el que proponemos salvo que haya motivo en contra: permite comparar roles entre sí, probar la lógica de negocio y verificar que un cliente no ve lo que es de otro. Con las mismas jornadas cubre más categorías del Top 10.

Caja blanca (white box)

Añadimos el código fuente, la configuración y, si hace falta, acceso al entorno. El análisis gana profundidad en las categorías que apenas se ven desde fuera: criptografía, integridad de la cadena de construcción y tratamiento de excepciones. Encaja en aplicaciones críticas y en componentes de pago, a cambio de una preparación más larga por tu parte.

Un test en caja negra no es «más realista» que uno en caja gris: solo está peor informado. Quien ataca de verdad no tiene fecha de entrega; un proyecto la tiene siempre. El trabajo del alcance consiste en colocar las jornadas donde producen más información útil.

Alcance y planificación: qué se acuerda antes de empezar

Un marco público resuelve el «qué probar». El «sobre qué» sigue siendo una decisión conjunta, y se toma antes de lanzar la primera petición. Estas seis cosas quedan por escrito, y ninguna se decide sobre la marcha.

• Objetivos. Qué aplicaciones, qué APIs, qué dominios y qué entornos entran, con su dirección, su versión y la persona responsable de cada uno.
• Exclusiones. Lo que queda fuera se escribe con el mismo detalle que lo que entra: sistemas de terceros, pasarelas de pago, integraciones que no controlas, ataques de denegación de servicio y cualquier prueba capaz de destruir información.
• Roles y cuentas. Una cuenta por rol, con datos de prueba. Sin eso, A01 —la categoría que más hallazgos críticos produce— se queda fuera por construcción, y con ella buena parte del Top 10.
• Profundidad. Recorrer el Top 10 y detenerse ahí no es lo mismo que verificar el ASVS en nivel L2 requisito a requisito. El nivel objetivo se fija aquí, porque es lo que determina las jornadas.
• Ventana de ejecución. Fechas y franjas horarias —de 9:00 a 18:00 salvo que prefieras otra cosa— y aviso previo a quien opera la plataforma, para que no confunda el test con un incidente real.
• Reglas de actuación (rules of engagement). Hasta dónde llegamos si conseguimos acceso, qué hacemos con los datos reales que veamos, cuándo paramos y a quién llamamos. Un hallazgo crítico se comunica en el momento, no al final.

En el alcance se fijan también las jornadas, porque el esfuerzo es la variable que decide la cobertura. Recorrer las diez categorías del Top 10 sobre una aplicación con dos roles y una quincena de endpoints cabe en 5 a 8 jornadas. Añadir el ASVS en nivel L2, una API GraphQL e integraciones de terceros lleva el proyecto más bien a 10 o 20. La cifra queda escrita en el presupuesto; si durante el trabajo vemos que se queda corta, te lo decimos antes de consumirla, no después.

El documento de alcance se firma junto con la autorización de pruebas. Sin esa autorización no empezamos: sin ella, el mismo trabajo sería la conducta que describen los arts. 197 bis y 264 del Código Penal.

Qué obliga realmente en España

«¿Es obligatorio OWASP?» es la pregunta equivocada, y la respuesta corta es que no: ninguna norma española lo nombra. Lo que varias sí exigen es una metodología de pruebas documentada, y ahí un marco público sale barato de defender: está publicado, está fechado y quien te audita puede leerlo sin pedirte permiso.

Conviene además decir con claridad lo que el mercado lleva dos años contando mal: NIS2 no está transpuesta en España. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad solo ha pasado una primera lectura en Consejo de Ministros, el 14 de enero de 2025, y no ha llegado a las Cortes. La Comisión Europea llevó a España ante el Tribunal de Justicia de la Unión Europea el 9 de julio de 2026 por esa falta de transposición, en el procedimiento INFR(2024)0270. Nadie puede sancionarte hoy al amparo de una ley de transposición que todavía no existe.

Lo que sí está en vigor, y sí obliga, es esto:

• Reglamento de Ejecución (UE) 2024/2690. Es de aplicación directa: no necesita transposición y ya rige para las categorías de entidades que cubre. Su Anexo, en el punto 6.5 «Pruebas de seguridad», exige una política de pruebas documentada, un alcance y una periodicidad determinados por riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. Ese requisito de «metodología documentada» es justo el hueco que rellenan el WSTG y el ASVS: no hace falta inventarse una metodología propia ni sostenerla delante de nadie.
• RDL 12/2018 y RD 43/2021. Trasponen la directiva NIS original y siguen siendo el marco aplicable a operadores de servicios esenciales y a proveedores de servicios digitales, con su obligación de auditorías y de análisis de riesgos periódicos.
• ENS, RD 311/2022. El art. 31 impone una auditoría regular ordinaria al menos cada dos años, y el art. 38 separa la autoevaluación de la categoría BÁSICA de la certificación exigida en MEDIA y ALTA. En el Anexo II, el refuerzo [op.mon.3] R6 incluye el subrequisito [op.mon.3.r6.3], titulado literalmente «Pruebas de penetración», exigible en categoría ALTA. Y ya desde BÁSICA, op.nub.1.2 a) pide la «Auditoría de pruebas de penetración (pentesting)» de los servicios cloud de terceros que no sean conformes con el ENS.
• RGPD, art. 32.1.d). Exige «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». Un test anual sobre un marco público, seguido del retest posterior a la corrección, es la manera habitual de documentar ese proceso.
• DORA, Reglamento (UE) 2022/2554. Se aplica en el sector financiero desde el 17 de enero de 2025. El art. 24 obliga a mantener un programa de pruebas de resiliencia operativa digital y el art. 26 añade, para las entidades designadas, ejercicios TLPT al menos cada tres años; ese ejercicio tiene su propio circuito de proveedores y no es lo que hacemos.

Nuestro papel es el técnico: ejecutar las pruebas sobre un marco que cualquiera puede consultar y documentar los resultados de forma que sirvan como evidencia ante quien tenga que valorarlos. Lo que no hacemos está escrito más abajo, con el mismo detalle. El desarrollo completo está en qué exige realmente el ENS sobre pentesting y en NIS2 en España: qué obliga hoy y qué no.

Última verificación: 12 de septiembre de 2026.

Lo que OWASP no es

No existe la «certificación OWASP»

La fundación publica documentos; no expide certificados, ni a una empresa ni a una aplicación. Nadie puede declararte «conforme con OWASP», y nosotros tampoco somos entidad de certificación. Lo que producimos es un informe técnico fechado que dice qué se probó y qué se encontró: justo el documento que reclama quien te audita.

No es una norma, pero alimenta a las normas

Un test alineado con OWASP no sustituye a ISO/IEC 27001 ni a PCI DSS: aporta la evidencia técnica que esos marcos esperan. En un proyecto de ISO 27001, el informe alimenta los controles de gestión de vulnerabilidades técnicas y de seguridad en el desarrollo; la certificación la firma un organismo de certificación acreditado, nunca nosotros. En el ámbito de NIS2 ocurre lo mismo: la directiva pide gestión del riesgo, no un marco concreto, y OWASP es la forma más barata de documentar cuál has usado.

No es un análisis automatizado

Una herramienta reconoce patrones conocidos: versiones obsoletas, cabeceras ausentes, inyecciones triviales. No entiende tus roles, ni tu lógica de negocio, ni por qué alguien de contabilidad no debería llegar a la exportación de nóminas. Y las dos categorías en las que levantamos más hallazgos críticos, A01 y A06, son precisamente las que ninguna herramienta detecta sola. La comparación está desarrollada en análisis de vulnerabilidades o pentest.

No hay traducción oficial al español del Top 10:2025

Las ediciones anteriores tienen traducciones hechas por la comunidad; la de 2025 todavía no. Por eso la tabla de arriba da el título en inglés, la traducción entre paréntesis y la explicación en español. En los informes conservamos el título en inglés: es el que va a circular por tus tickets y por los cuestionarios de seguridad de tus clientes.

Qué no hacemos

Decir dónde está el límite es lo que hace creíble todo lo anterior. Estas cinco cosas quedan fuera, y preferimos que lo sepas antes de pedirnos un presupuesto.

• No certificamos. Haxoris no es entidad de certificación ni cuenta con acreditación de ENAC, así que no emitimos certificados de conformidad con el ENS, ni el distintivo que los acompaña, ni certificados ISO 27001. Eso lo firma un organismo de certificación acreditado. Lo nuestro es la parte técnica: el informe de pruebas que ese organismo, o quien te audite, va a pedir como evidencia.
• No somos auditores del ENS. La auditoría del art. 31 y la certificación del art. 38 del RD 311/2022 tienen su propio circuito de entidades habilitadas. Nuestro trabajo alimenta esa auditoría con evidencia técnica; no la sustituye. En quién puede auditar el ENS explicamos quién firma qué.
• No hacemos TLPT. Las pruebas del art. 26 de DORA exigen proveedores que cumplan el art. 27 del Reglamento (UE) 2022/2554 y un proceso dirigido por la autoridad competente. Un ejercicio de Red Team nuestro puede servir de preparación previa, pero no lo sustituye y no nos presentamos a ese encargo.
• No trabajamos con información clasificada. El acceso a materia clasificada requiere habilitación de la Oficina Nacional de Seguridad, que no tenemos.
• No tenemos establecimiento en España. Somos un proveedor europeo: firmamos, facturamos y respondemos desde la Unión Europea, y trabajamos en español. Si tu pliego exige un proveedor establecido en España, dínoslo en la primera llamada y te lo diremos claro en lugar de hacerte perder el proceso.

Tratamiento de datos y soberanía

Un proyecto de este tipo genera material sensible: capturas, credenciales de prueba, extractos de datos reales y un informe que describe paso a paso cómo entrar en tu aplicación. Dónde vive ese material y bajo qué jurisdicción es una pregunta legítima del departamento de compras, y merece una respuesta concreta en lugar de una frase de marketing.

Haxoris es una empresa establecida en la Unión Europea, con oficinas en Bratislava y en Praga. Eso tiene tres consecuencias prácticas, y las tres se pueden comprobar en el contrato antes de firmarlo:

• El RGPD se aplica de forma directa, con el mismo texto y bajo autoridades de control europeas. No hace falta una capa contractual que replique garantías: el reglamento ya rige el tratamiento.
• No hay transferencia internacional de datos en el sentido del capítulo V del RGPD, porque el tratamiento no sale del Espacio Económico Europeo. No hacen falta cláusulas contractuales tipo, ni evaluación de impacto de la transferencia, ni el análisis de derecho extranjero que sí exige contratar a un proveedor de fuera de la Unión.
• Ninguna autoridad de un tercer país puede reclamar el material por la vía de su propio derecho interno. La discusión sobre acceso extraterritorial —la CLOUD Act estadounidense es el caso conocido— sencillamente no se plantea.

En el plano operativo: el material del proyecto se cifra en reposo y en tránsito, se conserva el tiempo pactado y se destruye a petición tuya con constancia escrita. Las personas que van a tocar la aplicación están nombradas en el contrato, con sus certificaciones, y firman confidencialidad a título individual. El informe se entrega cifrado y en español, con los títulos de las categorías de OWASP en inglés, que es como circulan.

Si tu comité de compras nunca ha contratado seguridad ofensiva fuera de España, lo tratamos punto por punto en contratar una empresa de pentesting no española.