OWASP Top 10 2025: qué cambia y qué riesgos puede detectar un escáner

¿Qué es el OWASP Top 10 2025?

El OWASP Top 10 2025 es una clasificación de diez categorías de riesgo para aplicaciones web, cada una con un grupo de debilidades CWE relacionadas. Para esta edición, OWASP analizó 589 CWE y se quedó con 248 repartidas en las diez categorías, con un máximo de 40 por categoría. Ocho categorías salen de datos de pruebas aportados por empresas como Semgrep, Sonar, Veracode, Contrast Security o Bugcrowd. Las otras dos salen de una encuesta a la comunidad, porque OWASP considera que los datos por sí solos están incompletos.

Los equipos de seguridad la usan como vocabulario común. Formaciones, listas de revisión de código, informes de escáneres y evidencias de auditoría suelen ordenarse según sus categorías, y por eso cada edición nueva repercute en herramientas, políticas y auditorías.

¿Cuáles son las diez categorías?

Las diez categorías del OWASP Top 10 2025 son Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures y Mishandling of Exceptional Conditions. OWASP las publica en inglés y así las cita la mayoría de equipos de habla hispana.

¿Qué cambia respecto a la lista de 2021?

Para un equipo de desarrollo importan cuatro cambios: la cadena de suministro tiene categoría propia, la SSRF pasa al control de acceso, la gestión de errores se convierte en categoría y la configuración insegura sube al segundo puesto.

• Software Supply Chain Failures (A03). La categoría de 2021, Vulnerable and Outdated Components, cubría las CVE conocidas de tus dependencias. La de 2025 cubre los fallos o compromisos en el proceso de construir, distribuir o actualizar software, y OWASP nombra expresamente el servidor de build y la CI/CD entre lo que hay que proteger. Escanear el lockfile ya no basta: el pipeline que construye tu código también entra. Según las notas de OWASP, es la categoría con la tasa de incidencia media más alta de las diez.
• La SSRF entra en Broken Access Control (A01). La falsificación de peticiones del lado del servidor era la A10 en 2021. Ahora cuenta como una de las 40 debilidades del control de acceso roto.
• Mishandling of Exceptional Conditions (A10). La nueva categoría trata de programas que no logran prevenir, detectar ni responder a situaciones inusuales e imprevisibles. Entre sus 24 debilidades: mensajes de error que filtran datos sensibles (CWE-209), desreferencias de puntero NULL (CWE-476) y código que falla en abierto en vez de fallar de forma segura (CWE-636).
• Security Misconfiguration (A02) pasa del quinto al segundo puesto. La definición de OWASP menciona ahora los servicios cloud junto a los sistemas y aplicaciones mal configurados.

Dos nombres cambian: Identification and Authentication Failures pasa a ser Authentication Failures, y Security Logging and Monitoring Failures pasa a ser Security Logging and Alerting Failures. La denegación de servicio, renombrada Lack of Application Resilience, queda en la sección de «próximos pasos» de OWASP, fuera de las diez.

¿Qué escáner open source detecta cada riesgo?

Los escáneres estáticos open source cubren con amplitud Injection y Cryptographic Failures, otras seis categorías en parte, y poco de Insecure Design y de Security Logging and Alerting Failures. La tabla es nuestra lectura del alcance documentado de cada herramienta frente a las páginas de categoría de OWASP, a 13 de noviembre de 2026.

Opengrep, el fork de Semgrep con licencia LGPL-2.1, cubre más de 30 lenguajes y ejecuta las reglas de Semgrep sin cambios. Su README describe un análisis de taint dentro de un fichero, por eso la fila de Injection dice «flujos que cruzan varios ficheros». Trivy lee dependencias, infraestructura como código, secretos y licencias, y nuestra prueba de herramientas SCA open source muestra lo que encuentran él y OSV-Scanner en un lockfile real. Gitleaks localiza contraseñas, claves de API y tokens en ficheros y en el historial de git; las credenciales escritas en el código (CWE-798) pertenecen a A07 en la lista de 2025, y nuestra comparativa de escáneres de secretos open source lo trata a fondo. zizmor es un analizador estático para GitHub Actions, con auditorías como template-injection, unpinned-uses, dangerous-triggers, excessive-permissions y cache-poisoning, que alcanzan A03 y A08.

Ninguna de estas herramientas ve un paquete malicioso que aún no tiene aviso de seguridad, el hueco por el que se cuela el slopsquatting, el ataque a los nombres de paquetes que inventa un modelo de IA.

¿Por qué los escáneres no ven el riesgo número uno?

Los escáneres estáticos no ven el núcleo de Broken Access Control porque el fallo es un control que falta, y un control que falta no tiene patrón. Un escáner puede seguir la entrada del usuario hasta una función peligrosa. No tiene ninguna fuente para la regla de que una factura pertenece a un cliente.

Los conjuntos de reglas lo confirman. El 13 de noviembre de 2026 contamos las reglas del conjunto comunitario de Opengrep, una copia de las reglas de Semgrep de enero de 2025: 2007 reglas, de las que 1354 llevan una categoría OWASP de 2021. Injection tiene 384. Broken Access Control tiene 228, pero 114 de ellas revisan permisos de recursos cloud, sobre todo en Terraform, y otras cubren path traversal, CSRF y redirecciones abiertas. Las tres debilidades que describen la autorización en sí, CWE-639 (saltarse la autorización con una clave que controla el usuario), CWE-862 (autorización ausente) y CWE-863 (autorización incorrecta), aparecen en cuatro reglas. Tres leen código de aplicación, cada una para un solo framework: un find sin acotar en Ruby on Rails, un controlador de ASP.NET Core sin atributo de autorización y operaciones nativas de datos en Salesforce Apex. Detectan un control que falta; ninguna sabe decir si un control presente es el correcto.

OWASP ya lo escribió en 2017: las herramientas SAST y DAST pueden detectar la ausencia de control de acceso, pero no pueden verificar que funciona cuando está presente. Así se ve en una ruta de Express:

// GET /api/invoices/:id
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

La ruta exige login, la consulta está parametrizada y la entrada nunca llega a una función peligrosa. El escáner no tiene nada que marcar. Y aun así, cualquier cliente con sesión puede leer cualquier factura cambiando el número en la URL: una referencia directa insegura a objetos, o IDOR. La corrección es una condición, where: { id: req.params.id, customerId: req.user.customerId }, y solo puede escribirla quien sabe que las facturas pertenecen a los clientes.

Insecure Design queda todavía más lejos. La página de OWASP lo dice claro: un diseño inseguro no se arregla con una implementación perfecta, porque los controles necesarios nunca se crearon. Un carrito que acepta una cantidad negativa pasa todos los escáneres, como muestra nuestro repaso del carrito a 0 €. Tratamos toda la familia en los fallos de lógica de negocio en el código generado por IA.

¿Cómo se prueba el control de acceso?

El control de acceso se prueba con un test que intenta la acción prohibida y espera un rechazo, uno por rol y por cada objeto que tiene dueño. La página de 2025 de OWASP lo pide tal cual: desarrolladores y QA deberían incluir pruebas funcionales del control de acceso en sus tests unitarios y de integración.

test("a customer cannot read another customer's invoice", async () => {
  const res = await request(app)
    .get(`/api/invoices/${aliceInvoice.id}`)
    .set("Authorization", tokenFor(bob));
  expect(res.status).toBe(404);
});

Ese test es a la vez la prueba y la protección. Antes de la corrección falla, lo que demuestra que el fallo existe en tu código y no en teoría. Después pasa, y se queda en la suite para que el próximo cambio no vuelva a abrir el agujero. Lo que cuesta es saber qué objetos pertenecen a quién, justo lo que el escáner no sabe.

Tres hábitos cubren buena parte del terreno:

1. Denegar por defecto. Cada ruta nueva nace cerrada, y el acceso se concede con un control explícito que nombra al dueño o al rol.
2. Acotar cada consulta al usuario. Busca los registros a través del usuario o del tenant actual, nunca con un identificador suelto que llega en la petición.
3. Un test de rechazo por objeto sensible. Facturas, documentos, cuentas: todo lo que tiene dueño recibe un test donde el usuario equivocado se queda fuera.

¿Qué significa el OWASP Top 10 cuando agentes de IA escriben el código?

Las categorías no cambian cuando agentes de código como Claude Code, Cursor, GitHub Copilot u OpenAI Codex escriben el código, pero el volumen y la velocidad sí. Un equipo que sube más cambios por semana necesita los escáneres en cada cambio, y una revisión de los controles de acceso en cada endpoint nuevo, porque un agente escribe una ruta que funciona con la misma facilidad con la que se salta un control de propietario que nadie le describió nunca.

Los mismos agentes pueden hacer también el trabajo defensivo. Un agente que lee el código puede mapear cada endpoint, ver qué roles llegan a cada uno, escribir el test de rechazo, ejecutarlo y enseñar si falla. Esa es la parte del OWASP Top 10 que los escáneres dejan sobre la mesa, y un agente de código puede hacerla al ritmo al que escribe código. Nuestra guía de seguridad de los agentes de código con IA cubre la otra cara: qué puede ejecutar el propio agente.

¿Dónde encaja CybeDefend?

CybeDefend Open Source llega pronto y cubre las dos mitades de este artículo. Un comando en tu agente de código, /cybedefend, lanza una auditoría completa en dos capas. Primero los escáneres AppSec, open source, entre ellos Opengrep, Trivy, Gitleaks y zizmor, para código, dependencias, secretos, infraestructura como código, CI/CD y contenedores: los riesgos con patrón de la tabla de arriba. Quédate con los que quieras y añade los tuyos.

Después, el escáner de IA, ejecutado por tu agente de código. Los escáneres buscan patrones. El escáner de IA lee lo que tu código debería hacer y encuentra dónde se rompe, en la lógica de negocio, en los permisos de acceso y en los fallos que solo aparecen cuando el código se ejecuta: las filas A01, A06 y A07. Demuestra cada fallo con un exploit escrito como test en tu propia suite, como el de arriba. Sin modelo extra y sin clave de API: la IA es el agente de código que ya usas.

Bajo las dos capas está toda nuestra plataforma, un ASPM agéntico. Guarda cada hallazgo en una sola cola, y sus informes de seguridad relacionan los hallazgos con el OWASP Top 10 y el CWE Top 25. Para lanzar la auditoría sobre tu propio código en cuanto abra, apúntate a la lista de espera de CybeDefend Open Source.

Preguntas frecuentes

¿Qué hay de nuevo en el OWASP Top 10 2025?

Dos categorías nuevas: Software Supply Chain Failures en A03, que extiende la antigua Vulnerable and Outdated Components a los sistemas de build y a la CI/CD, y Mishandling of Exceptional Conditions en A10. La SSRF pasa a Broken Access Control y Security Misconfiguration sube del quinto al segundo puesto.

¿Cuál es el riesgo número uno del OWASP Top 10 2025?

Broken Access Control, el control de acceso roto, igual que en 2021. Agrupa 40 debilidades, del path traversal y el CSRF a la autorización ausente y los IDOR, y desde 2025 incluye también la SSRF.

¿Sigue la SSRF en el OWASP Top 10?

Sí, dentro de A01 Broken Access Control. En 2021 la SSRF tenía categoría propia, la A10; la edición de 2025 la integró en el control de acceso.

¿Basta una herramienta SAST para cubrir el OWASP Top 10?

No. Una herramienta SAST cubre bien Injection y Cryptographic Failures, y parte de varias categorías más. Los riesgos de dependencias y del pipeline necesitan una herramienta SCA y un escáner de CI/CD, y el control de acceso y el diseño necesitan tests y la revisión de alguien que conozca las reglas de la aplicación.

¿Cada cuánto se actualiza el OWASP Top 10?

No tiene un calendario fijo. La edición de 2025 es la octava, cuatro años después de la de 2021.

¿CybeDefend es open source?

Su edición open source, CybeDefend Open Source, llega pronto: toda nuestra plataforma, un ASPM agéntico, gratis para ejecutarla en tus propios servidores. El comando /cybedefend encadena los escáneres AppSec open source y un escáner de IA ejecutado por tu agente de código, y guarda cada hallazgo en una sola cola. Apúntate a la lista de espera de CybeDefend Open Source.