Web y API
Pruebas de seguridad web y API: el DAST explicado
Las pruebas de seguridad web y API, a menudo llamadas pruebas dinámicas de seguridad de aplicaciones (DAST), envían peticiones manipuladas a una aplicación en ejecución y observan cómo responde, para encontrar fallos como un control de acceso roto, inyecciones o configuraciones incorrectas. Complementan el análisis de código y de dependencias, y solo deben ejecutarse contra sistemas que sean tuyos o que tengas autorización por escrito para probar.
Plan gratuito, sin tarjeta.
¿Qué son las pruebas dinámicas de seguridad de aplicaciones (DAST)?
Las pruebas dinámicas tratan la aplicación como una caja negra, o como una caja gris cuando quien prueba tiene credenciales. Una herramienta o una persona rastrea el sitio o lee la descripción de la API y, después, envía peticiones pensadas para provocar fallos: identificadores modificados, parámetros inesperados, cargas de tamaño excesivo, tokens ausentes o falsificados. Los hallazgos salen del comportamiento, no del código fuente. Esa es a la vez la fortaleza y el límite del método: ve lo que ve un atacante, incluidos los problemas de despliegue y de configuración, pero solo encuentra lo que consigue alcanzar.
En las API, la cobertura depende de conocer los endpoints. Una descripción OpenAPI, una colección de Postman o tráfico grabado permiten que una prueba llegue a operaciones que un rastreador nunca encontraría. Las pruebas autenticadas con al menos dos cuentas de roles distintos son las que revelan el fallo que encabeza el OWASP API Security Top 10: que un usuario acceda a los objetos de otro.
¿En qué se diferencia el DAST del SAST y del análisis de dependencias?
Los tres métodos responden a preguntas distintas. El análisis de dependencias te dice si los componentes que distribuyes tienen vulnerabilidades conocidas. El análisis estático te dice si tu propio código contiene patrones peligrosos. Las pruebas dinámicas te dicen si el sistema desplegado, con su configuración, su autenticación y su infraestructura, puede aprovecharse de verdad. Un programa maduro usa los tres y utiliza los resultados dinámicos para confirmar qué hallazgos estáticos y de dependencias son explotables en la práctica.
| Método | Qué examina | Hallazgos típicos | Puntos ciegos |
|---|---|---|---|
| Análisis de dependencias | Lockfiles, manifiestos, SBOM e imágenes de contenedor | Vulnerabilidades conocidas y paquetes maliciosos en componentes de terceros | Fallos en tu propio código y en cómo se despliega la aplicación |
| Análisis estático (SAST) | Tu código fuente, sin ejecutarlo | Patrones de inyección, funciones inseguras, credenciales escritas en el código | Configuración en tiempo de ejecución y lógica de autorización repartida entre servicios |
| Pruebas dinámicas (DAST) | El sitio web o la API en ejecución, a través de la red | Control de acceso roto, inyección, configuraciones incorrectas, endpoints expuestos | Rutas de código que la prueba no alcanza y la causa raíz en el código |
¿Por qué limitar las pruebas a dominios propios o con autorización?
Una prueba de seguridad y un ataque se ven igual en la red; la diferencia es el permiso. En la UE, la Directiva 2013/40/UE obliga a los Estados miembros a castigar como infracción penal, al menos en los casos que no sean de menor gravedad, el acceso ilegal a los sistemas de información y la interferencia ilegal en los sistemas cometidos intencionalmente y «sin autorización». La Directiva lo define como un comportamiento no autorizado por el propietario u otro titular del derecho sobre el sistema, o no permitido por el Derecho nacional. Las leyes nacionales difieren en los detalles, pero la regla práctica es la misma en todas partes: sin autorización por escrito, no hay prueba.
La autorización también tiene aristas técnicas. Un sitio en un alojamiento compartido, detrás de una red de distribución de contenidos o de una pasarela de API de terceros implica a otros propietarios cuyas condiciones pueden restringir las pruebas, y una prueba que sobrecarga un servicio compartido puede perjudicar a otros clientes. Demostrar el control de un dominio, por ejemplo con un registro DNS o un archivo en el servidor web, es una forma habitual de que un servicio de pruebas confirme que quien lo solicita tiene derecho a probarlo. Conserva la autorización, el alcance, la ventana de pruebas y la persona de contacto junto con los resultados.
¿Qué listas de OWASP deben cubrir las pruebas web y de API?
El OWASP Top 10 y el OWASP API Security Top 10 son las referencias habituales para definir el alcance de una prueba. Son documentos de concienciación más que estándares de prueba completos, pero nombran las clases de fallos que más importan. Las ediciones actuales son el OWASP Top 10:2025 para aplicaciones web y el OWASP API Security Top 10 2023 para API.
Varias categorías no se detectan solo con pruebas dinámicas. Los fallos de la cadena de suministro de software son sobre todo una cuestión de dependencias y compilaciones, y la gestión inadecuada del inventario empieza por saber qué versiones de API y qué hosts ejecutas. Ahí es donde el análisis del lado del código y un inventario preciso cubren el hueco.
| Posición | OWASP Top 10:2025 | OWASP API Security Top 10 2023 |
|---|---|---|
| 1 | Broken Access Control | Broken Object Level Authorization |
| 2 | Security Misconfiguration | Broken Authentication |
| 3 | Software Supply Chain Failures | Broken Object Property Level Authorization |
| 4 | Cryptographic Failures | Unrestricted Resource Consumption |
| 5 | Injection | Broken Function Level Authorization |
| 6 | Insecure Design | Unrestricted Access to Sensitive Business Flows |
| 7 | Authentication Failures | Server Side Request Forgery |
| 8 | Software or Data Integrity Failures | Security Misconfiguration |
| 9 | Security Logging and Alerting Failures | Improper Inventory Management |
| 10 | Mishandling of Exceptional Conditions | Unsafe Consumption of APIs |
¿Cómo encajan las pruebas web y de API en el CRA y en NIS2?
Según el Reglamento de Ciberresiliencia (Cyber Resilience Act, CRA), un producto con elementos digitales incluye sus soluciones de tratamiento de datos a distancia: tratamiento a distancia cuyo software ha sido diseñado y desarrollado por el fabricante o bajo su responsabilidad, y sin el cual el producto no podría realizar una de sus funciones. Los considerandos del CRA ponen el ejemplo de una aplicación móvil que necesita una API proporcionada por el fabricante; esa API está incluida, mientras que los sitios web que no dan soporte a la funcionalidad de un producto no lo están. El anexo I, parte II, exige exámenes y pruebas eficaces y periódicos de la seguridad del producto, lo que en un producto con backend en la nube puede incluir razonablemente probar su API.
El software ofrecido únicamente como servicio queda fuera del CRA; los considerandos del CRA remiten a NIS2 para los servicios de computación en nube, como el software como servicio. El artículo 21(2)(e) de la Directiva NIS2 (SRI 2) exige a las entidades esenciales e importantes seguridad en la adquisición, el desarrollo y el mantenimiento de sus sistemas, incluida la gestión y divulgación de las vulnerabilidades. Para determinados proveedores de servicios digitales, el Reglamento de Ejecución (UE) 2024/2690 añade una política documentada de pruebas de seguridad, pruebas cuya necesidad, alcance, frecuencia y tipo se derivan de la evaluación de riesgos, y registros del tipo, el alcance, la fecha y los resultados de cada prueba.
Disponible hoy en KROMSE
KROMSE todavía no prueba sitios web ni API en ejecución, pero comprueba el código, las dependencias y las imágenes de contenedor que hay detrás.
- Comprobación de dependencias con OSV.dev para los lockfiles y manifiestos que hay detrás de tu sitio o tu API, incluidos npm, Yarn, pnpm, Poetry, uv, pip, Go, Cargo, Maven, Gradle, Composer, Bundler y .NET.
- Análisis de código fuente para 11 lenguajes, entre ellos JavaScript, TypeScript, Python, Java, Go y C#, además de la importación de tus propios resultados en SARIF 2.1.0.
- Detección de secretos en el commit analizado; los valores de los secretos se enmascaran y nunca se almacenan.
- Comprobación de configuraciones incorrectas en Terraform y Dockerfiles.
- Imágenes de contenedor de un registro accesible desde internet, analizadas en busca de vulnerabilidades, configuraciones incorrectas y secretos.
- Los paquetes que figuran en la base de datos OpenSSF Malicious Packages se marcan como críticos, con la eliminación como solución.
Próximamente
En la hoja de ruta, todavía no disponible. Las fechas son objetivos, no promesas; esta página cambia el mismo día en que una funcionalidad está operativa.
- Próximamente · T4 2026 (diciembre)Pruebas de sitios web y API. KROMSE probará sitios web y API en busca de vulnerabilidades, solo en dominios cuyo control hayas verificado.
- Próximamente · T4 2026 (diciembre)Monitorización según tu calendario, con agentes de IA. Los reanálisis se ejecutarán con la periodicidad que tú fijes, con agentes de IA que vigilarán los nuevos avisos, clasificarán lo que te afecta, propondrán correcciones y redactarán el informe para tu revisión.
Preguntas frecuentes
¿KROMSE prueba sitios web y API?
Todavía no. Hoy KROMSE no ejecuta pruebas dinámicas contra sitios web ni API. Comprueba lo que hay detrás: dependencias, código fuente en 11 lenguajes, secretos subidos al repositorio, configuraciones incorrectas de Terraform y Dockerfile, e imágenes de contenedor. Las pruebas de seguridad de sitios web y API en dominios cuyo control hayas verificado están en la hoja de ruta, y esta página cambiará cuando estén disponibles.
¿Es legal analizar un sitio web que no es mío?
Por regla general, no sin permiso. La Directiva 2013/40/UE obliga a los Estados miembros de la UE a castigar como infracción penal el acceso ilegal a los sistemas de información y la interferencia ilegal en ellos cometidos intencionalmente y sin autorización, es decir, sin autorización del propietario u otro titular del derecho, al menos en los casos que no sean de menor gravedad. Las leyes nacionales añaden sus propias normas. Prueba solo sistemas que sean tuyos o que tengas autorización por escrito para probar, y respeta las condiciones de cualquier proveedor de alojamiento, CDN o API implicado.
¿Qué diferencia hay entre el DAST y una prueba de penetración?
El DAST suele ser automatizado: una herramienta envía muchas peticiones e informa de los comportamientos que encajan con patrones de fallos conocidos. Una prueba de penetración la dirige una persona que encadena hallazgos, prueba la lógica de negocio y valora el impacto, a menudo con herramientas DAST por el camino. Las pruebas automatizadas se prestan a comprobaciones frecuentes y repetibles; una prueba de penetración, a versiones importantes, cambios significativos y sistemas de alto riesgo.
¿El CRA exige probar la seguridad de la API de mi producto?
El CRA no prescribe un método de prueba. El anexo I, parte II, exige exámenes y pruebas eficaces y periódicos de la seguridad del producto, y un producto incluye sus soluciones de tratamiento de datos a distancia, como una API sin la que tu aplicación no puede funcionar. Elige los métodos que justifique tu evaluación de riesgos y guarda el alcance, el método y los resultados de las pruebas en tu documentación técnica.
¿Qué lista de OWASP debo usar para las API?
Usa el OWASP API Security Top 10, cuya edición actual es de 2023. Se centra en fallos específicos de las API, como Broken Object Level Authorization, Broken Authentication, Unrestricted Resource Consumption e Improper Inventory Management, que las listas orientadas a la web cubren de forma menos directa. Úsalo junto con el OWASP Top 10:2025 para el front end web.
Guías relacionadas
Fuentes
- OWASP Top 10:2025
- OWASP API Security Top 10
- Directiva 2013/40/UE relativa a los ataques contra los sistemas de información, EUR-Lex
- Reglamento (UE) 2024/2847 (Reglamento de Ciberresiliencia), EUR-Lex
- Directiva (UE) 2022/2555 (Directiva NIS2), EUR-Lex
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión, EUR-Lex