OWASP Top 10 2026: qué ha cambiado y cómo protegerte

Antes de entrar en materia hay que aclarar una confusión que circula bastante: el documento que gobierna las auditorías, los cuestionarios de proveedores y los informes de pentesting durante 2026 no se llama “OWASP Top 10 2026”, se llama OWASP Top 10:2025. Se publicó en noviembre de 2025, se cerró en su forma definitiva en enero de 2026 y es la referencia vigente este año, igual que la edición de 2021 lo fue durante cuatro años. Aparte de ese documento clásico, la Fundación OWASP mantiene desde hace un par de años un ranking hermano centrado en aplicaciones que usan modelos de lenguaje —el OWASP Top 10 for LLM Applications—, que sí ha recibido una actualización propia con fecha de 2026 y que cada vez pesa más porque cada vez hay más aplicaciones con un LLM metido dentro. Este artículo cubre los dos, porque en 2026 casi ningún equipo puede permitirse ignorar el segundo.

El Top 10 clásico: qué se ha movido

La lista de riesgos de aplicaciones web de toda la vida mantiene sus diez categorías, pero el orden y el contenido de varias de ellas ha cambiado lo suficiente como para que valga la pena repasarlas una por una:

Los tres movimientos que de verdad importan:

Broken Access Control absorbe SSRF. El Server-Side Request Forgery, que era su propia categoría en 2021 (A10), ahora se trata como una manifestación más de control de acceso roto: al final, un SSRF es un servidor haciendo una petición que un atacante no debería poder provocar, lo cual es un problema de qué se le permite hacer a quién. Si ya tenías buenas prácticas contra SSRF no cambia nada en la práctica, solo dónde se clasifica.

Security Misconfiguration salta del quinto al segundo puesto. Esto no es casualidad ni ruido estadístico: refleja que la superficie de configuración de una aplicación moderna (headers de seguridad, permisos de IAM en la nube, configuración por defecto de frameworks, secretos en variables de entorno mal gestionadas, CORS demasiado permisivo) ha crecido mucho más rápido que la disciplina para revisarla. Si tu checklist de seguridad no incluye una revisión periódica de configuración —no solo de código—, este es el cambio que debería empujarte a añadirla.

Software Supply Chain Failures reemplaza y amplía “Vulnerable and Outdated Components”. La categoría de 2021 hablaba básicamente de “actualiza tus dependencias”. La de 2025 es mucho más amplia: cubre compromisos en cualquier punto de la cadena —el propio paquete, el pipeline de build que lo genera, el registro que lo distribuye, la cuenta del mantenedor que lo publica—. Es un cambio directamente motivado por incidentes reales de los últimos años, y le dedicamos un artículo entero a este tema con el caso de LiteLLM en marzo de 2026 como ejemplo concreto.

La categoría nueva, Mishandling of Exceptional Conditions, formaliza algo que llevaba tiempo pasando desapercibido en el Top 10 pero que cualquier persona que haya hecho un pentest reconoce: aplicaciones que fallan de forma insegura. Mensajes de error que filtran trazas de stack o rutas internas, lógica que asume que una excepción nunca va a ocurrir y por tanto no verifica nada después, límites de recursos ausentes que convierten un error de validación en una denegación de servicio. No es una vulnerabilidad exótica: es el resultado directo de tratar el manejo de errores como un detalle de implementación en vez de como una superficie de seguridad.

El otro Top 10: cuando la aplicación tiene un LLM dentro

Si tu producto llama a un modelo de lenguaje —para lo que sea: un asistente, un buscador semántico, un agente que ejecuta acciones— el Top 10 clásico no cubre el riesgo real de esa pieza. Para eso existe el OWASP Top 10 for LLM Applications, cuya edición 2026 reordena y amplía la de años anteriores:

1. Prompt Injection — se mantiene en el número uno.
2. Sensitive Information Disclosure
3. Excessive Agency — sube desde el sexto puesto.
4. Supply Chain Risks
5. Data and Model Poisoning
6. Unbounded Consumption — sube desde el décimo puesto.
7. Misinformation
8. Hidden Context Exposure — versión ampliada de lo que antes se llamaba “System Prompt Leakage”.
9. Vector and Embedding Weaknesses
10. Improper Output Handling

Que la inyección de prompts siga en primer puesto no es un fallo de OWASP para encontrar algo nuevo que decir: es un reflejo honesto de que el problema de fondo sigue sin resolverse. Un modelo de lenguaje procesa instrucciones legítimas y contenido no confiable en el mismo espacio —el contexto—, y no hay una frontera técnica fiable entre “esto es una orden del sistema” y “esto es un dato que hay que leer”. El filtrado y el prompting defensivo reducen los ataques que funcionan, pero no eliminan la categoría de raíz. La novedad de la edición 2026 es que el alcance se amplía explícitamente a ataques multimodales: instrucciones ocultas en una imagen o en un archivo de audio que el modelo procesa junto al resto del contexto, no solo texto.

El ascenso de Excessive Agency al tercer puesto tiene una explicación igual de directa: en 2023 la mayoría de aplicaciones con LLM solo generaban texto. En 2026, buena parte ejecuta acciones reales —llamar a una API, escribir en una base de datos, enviar un correo, tocar un sistema de pagos— a menudo a través de protocolos como el que explicamos en nuestra guía de MCP. Cuantas más acciones reales puede desencadenar un modelo, más caro sale que alguien consiga manipular sus instrucciones. Si tu agente puede escribir, no solo leer, la inyección de prompts deja de ser un problema de “respuesta rara” y pasa a ser un problema de integridad de datos o de fraude.

Profundizamos en cómo defender un agente concreto frente a esto en nuestro artículo dedicado a proteger un agente de IA de prompt injection.

Qué significa cada categoría para un equipo de desarrollo normal

No hace falta ser una empresa de seguridad para actuar sobre este ranking. Traducido a tareas concretas:

• Broken Access Control (A01): cada endpoint que recibe un identificador de recurso debe comprobar que quien hace la petición tiene permiso sobre ese recurso concreto, no solo que está autenticado. Es el fallo más común en APIs REST y le dedicamos un artículo entero a cómo diseñar autenticación y autorización de APIs bien desde el principio.
• Security Misconfiguration (A02): revisa los headers de seguridad que sirve tu aplicación (empezando por una Content Security Policy bien construida), los permisos por defecto de tu proveedor cloud y que ningún panel de administración quede expuesto sin autenticación por descuido.
• Software Supply Chain Failures (A03): audita de qué depende tu build, no solo de qué depende tu código en producción. Un script de postinstall malicioso en una dependencia de desarrollo compromete la misma máquina que una vulnerabilidad en producción.
• Cryptographic Failures (A04): no implementes tu propio cifrado ni tu propia gestión de sesiones; usa librerías auditadas y, para autenticación, valora pasar a passkeys en vez de contraseñas, que elimina de raíz toda una familia de fallos criptográficos relacionados con el manejo de contraseñas.
• Mishandling of Exceptional Conditions (A10): revisa qué le devuelves al cliente cuando algo falla. Un catch genérico que expone el mensaje de una excepción de base de datos es información gratis para quien está probando tu aplicación.

Cómo priorizar si no puedes con las veinte categorías a la vez

Con diez categorías clásicas y diez de LLM, ningún equipo pequeño va a auditar las veinte a fondo el mismo trimestre. El criterio realista es: si tu aplicación no tiene un LLM tomando decisiones o ejecutando acciones, ignora por ahora el ranking de LLM y concéntrate en el clásico, empezando por control de acceso y configuración, que son con diferencia los dos que más incidentes reales explican. Si sí tienes un LLM con capacidad de actuar —no solo de responder—, la inyección de prompts y el exceso de agencia dejan de ser un riesgo teórico y merecen revisión antes que cualquier otra cosa de la lista, incluida la parte clásica.

Ninguno de los dos rankings es una checklist de cumplimiento que se marca una vez al año. Son un mapa de dónde han estado fallando aplicaciones reales recientemente, y ese mapa cambia porque el software cambia. La utilidad real está en revisarlo cuando cambia de versión y preguntarte, categoría por categoría, si tu aplicación de hoy —no la de hace dos años— tiene ese problema resuelto.