Pentesting de aplicaciones web y APIs

Enfoques: caja negra, caja gris y caja blanca

El nivel de información que nos das antes de empezar determina cuánta superficie podemos cubrir con un número de jornadas dado. En el mercado español conviven los tres enfoques; en la gran mayoría de los casos recomendamos el segundo.

Caja negra (black box)

Partimos de una URL, sin cuentas ni documentación, como quien ataca desde fuera. El enfoque mide bien lo visible desde internet y la resistencia de la superficie pública. Su límite es mecánico: una parte importante del presupuesto se va en reconocimiento, y todo lo que hay detrás de la autenticación queda fuera de alcance. En una aplicación con área privada de clientes, un test en caja negra deja fuera por construcción justo la zona donde se concentran los fallos de control de acceso.

Caja gris (grey box)

Trabajamos con un juego de cuentas —una por rol— y una descripción funcional de la aplicación. Es el enfoque por defecto de un pentesting web y el que proponemos salvo que haya motivo en contra: con el mismo presupuesto cubre más superficie, permite comparar roles entre sí y hace posible probar la lógica de negocio. Es además la única forma seria de verificar que un cliente no ve los datos de otro.

Caja blanca (white box)

Añadimos el código fuente, la arquitectura y, si hace falta, acceso a los entornos de preproducción. Encaja en aplicaciones críticas, en componentes de pago y en las piezas propias que se reutilizan en todas partes. Se combina de forma natural con una auditoría de código fuente y da la cobertura más completa, 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.

Qué obliga realmente en España

Buena parte del mercado español lleva dos años vendiendo pentesting con el argumento de NIS2. Conviene decirlo con claridad: 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 precisamente 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, y quien te diga lo contrario está vendiendo miedo.

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

• RDL 12/2018 y RD 43/2021. Trasponen la directiva NIS original y siguen siendo el marco aplicable a operadores de servicios esenciales y proveedores de servicios digitales, con su obligación de auditorías y de análisis de riesgos periódicos.
• 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. Es la obligación de pruebas más concreta que hay hoy sobre la mesa en España, y casi nadie la cita.
• 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». Para una aplicación que trata datos personales, el pentest es la manera habitual de documentar ese proceso, y el informe es la pieza que enseñas a quien te audita, a un cliente grande o a la autoridad de control.
• 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.

Nuestro papel es el técnico: ejecutamos las pruebas y documentamos 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. Si quieres 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.

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

Un proyecto mal acotado produce un informe que no sirve. Antes de enviar el primer paquete dejamos por escrito seis cosas, y ninguna de ellas se decide sobre la marcha.

• Objetivos. Qué dominios, qué aplicaciones, qué APIs y qué entornos entran, con su URL, 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 datos.
• Roles y cuentas. Una cuenta por rol, con datos de prueba, para poder comparar permisos entre perfiles. Es lo que hace posible verificar que un cliente no ve lo que es de otro.
• Ventana de ejecución. Fechas y franjas horarias —de 9:00 a 18:00 salvo que pidas otra cosa— y el 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.
• Entorno. Producción o preproducción. Si hay un entorno de preproducción representativo, trabajamos ahí; si solo hay producción, las pruebas capaces de degradar el servicio se excluyen o se llevan a una ventana pactada contigo.

En el alcance se fijan también las jornadas, porque el esfuerzo es la variable que decide la cobertura. Una aplicación con dos roles y una quincena de endpoints cabe en 5 a 8 jornadas. Una plataforma con varios roles, API GraphQL, área de clientes e integraciones de terceros pide más bien de 10 a 20. La cifra queda escrita en el presupuesto; si durante el proyecto 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.

Tratamiento de datos y soberanía

Un test de intrusión 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 verificar 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 tu 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.

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.

Qué no hacemos

Decir dónde está el límite es lo que hace creíble todo lo anterior. Estas seis 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, te 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. Los ejercicios de pruebas basadas en amenazas 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 investigamos a personas concretas. El reconocimiento en fuentes abiertas se limita a la superficie de exposición de la organización, dentro del alcance contratado. Las actividades que la Ley 5/2014 reserva en exclusiva a otras profesiones quedan fuera de lo que prestamos.
• 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.