OWASP Top 10 2025: la lista actualizada explicada (A01-A10)

Qué es el OWASP Top 10 2025 y qué ha cambiado

El OWASP Top 10 es un documento de concienciación impulsado por la comunidad que clasifica los riesgos de seguridad más críticos para las aplicaciones web. Mantenido por el Open Worldwide Application Security Project, se actualiza aproximadamente cada tres o cuatro años a partir de datos aportados de pruebas de aplicaciones y de una encuesta a profesionales, de modo que cada edición refleja cómo se comportan realmente los atacantes y no una teoría abstracta.

La edición de 2025 mantiene el control de acceso deficiente en primer lugar y sigue tratando categorías completas de debilidades, no fallos aislados. Los cambios destacados son un mayor énfasis en la configuración insegura en cloud y CI/CD, la elevación del riesgo de la cadena de suministro de software más allá de los componentes vulnerables, y una atención explícita a los errores y excepciones mal gestionados que filtran datos en silencio o fallan en modo abierto.

Como tantos marcos y reguladores lo citan, el Top 10 se ha convertido en una base de facto. Las expectativas de auditoría de CERT-In en India, los requisitos de seguridad del RBI y el SEBI, las normativas europeas NIS2 y DORA y los cuestionarios de seguridad de las grandes empresas estadounidenses dan por hecho que sus aplicaciones se han probado frente a estas categorías. Trate la lista como el alcance mínimo, no como la meta final.

A01: Control de acceso deficiente

El control de acceso determina qué puede hacer un usuario autenticado. Es deficiente cuando un usuario puede actuar fuera de los permisos previstos: ver registros de otros clientes cambiando un identificador en la URL, escalar a un rol de administrador o alcanzar API que deberían estar vetadas. Sigue siendo la categoría más frecuente y dañina de las ediciones recientes.

Mitigación: denegar por defecto y aplicar la autorización en el servidor en cada solicitud, comprobando la propiedad del objeto concreto al que se accede en lugar de confiar en identificadores enviados por el cliente o en campos ocultos.

A02: Configuración de seguridad incorrecta

Esta categoría abarca ajustes por defecto inseguros, funcionalidades innecesarias activadas, páginas de error demasiado detalladas, cabeceras de seguridad ausentes, almacenamiento cloud abierto y servicios sin parchear o con permisos excesivos. La edición de 2025 le da más protagonismo porque la expansión de cloud, contenedores y CI/CD multiplica los lugares donde un solo ajuste débil puede exponer datos.

Mitigación: construir bases de configuración endurecidas y reproducibles como código, eliminar componentes sin uso y cuentas por defecto, y analizar de forma continua los entornos en ejecución para detectar desviaciones antes de que las descubra un atacante.

A03: Fallos en la cadena de suministro de software

Esta categoría amplía el antiguo riesgo de «componentes vulnerables y obsoletos» a toda la cadena de suministro de software: bibliotecas de terceros, imágenes base, herramientas de compilación, registros de paquetes y las canalizaciones que los ensamblan. Una dependencia o un paso de compilación comprometido puede introducir código malicioso en su aplicación antes de que llegue a producción.

Mitigación: mantener una lista de materiales de software (SBOM), fijar y verificar las dependencias y asegurar la propia canalización de compilación, de modo que solo puedan promocionarse a producción artefactos revisados y con integridad comprobada.

A04: Fallos criptográficos

Los fallos criptográficos se producen cuando datos sensibles —contraseñas, datos de pago, historiales de salud, datos personales sujetos al RGPD o a la Ley DPDP de India— no se protegen adecuadamente en tránsito o en reposo. Las causas habituales son la falta de cifrado, algoritmos débiles u obsoletos, claves incrustadas en el código y una mala gestión de claves.

Mitigación: clasificar sus datos, exigir cifrado de transporte robusto en todas partes, cifrar los datos sensibles en reposo con algoritmos actuales y gestionar las claves en un servicio dedicado de secretos o de gestión de claves, no en el código ni en ficheros de configuración.

A05: Inyección

La inyección ocurre cuando una entrada no confiable se interpreta como un comando o una consulta, lo que permite a un atacante alterar la lógica del programa. La inyección SQL, la inyección NoSQL, la inyección de comandos del sistema operativo y el cross-site scripting pertenecen a esta categoría: la aplicación mezcla datos e instrucciones en lugar de mantenerlos separados.

Mitigación: usar consultas parametrizadas y API seguras que vinculen la entrada como datos, validar la entrada con listas de permitidos estrictas y codificar la salida según su contexto, de modo que el contenido aportado por el usuario nunca pueda ejecutarse.

A06: Diseño inseguro

El diseño inseguro es un fallo de la arquitectura en sí, no de la implementación. Ni siquiera un código perfecto puede suplir un control de seguridad que nunca se diseñó, como la ausencia de limitación de velocidad en un flujo de transferencia de dinero o un proceso de restablecimiento de contraseña que puede abusarse para tomar cuentas.

Mitigación: aplicar modelado de amenazas desde el principio, definir requisitos de seguridad y casos de abuso junto a los funcionales, y usar patrones de diseño seguros para que los controles adecuados estén presentes por diseño y no añadidos después.

A07: Fallos de autenticación

Los fallos de autenticación permiten a los atacantes comprometer identidades mediante una gestión deficiente de credenciales: permitir contraseñas débiles o filtradas, no proteger frente a fuerza bruta, tokens de sesión predecibles o mal invalidados y ausencia de autenticación multifactor. El resultado es la toma de cuentas y el credential stuffing a gran escala.

Mitigación: exigir autenticación multifactor, contrastar las contraseñas con listas de filtraciones conocidas, limitar la tasa y supervisar los puntos de autenticación, y generar, rotar e invalidar los tokens de sesión de forma segura en el servidor.

A08: Fallos de integridad del software y los datos

Los fallos de integridad surgen cuando se confía en código o datos críticos sin verificar que no han sido manipulados: actualizaciones automáticas sin firmar, deserialización insegura de objetos no confiables o pasos de CI/CD que descargan artefactos sin comprobar la integridad. Un atacante capaz de suplantar una fuente de confianza toma el control de la aplicación.

Mitigación: verificar la integridad y la procedencia del código, las actualizaciones y los datos mediante firmas digitales, y no deserializar nunca entradas no confiables sin controles de tipo estrictos y validación.

A09: Fallos de registro y alerta

Esta categoría cubre el registro, la supervisión y la alerta insuficientes, el motivo por el que tantas brechas pasan inadvertidas durante meses. Si no se registran los fallos de autenticación, las violaciones de control de acceso y las transacciones de alto valor, y no se generan alertas, un ataque en curso resulta invisible para los defensores.

Mitigación: registrar los eventos relevantes para la seguridad con contexto suficiente para investigar, centralizar y proteger esos registros y conectarlos a alertas en tiempo real y a un proceso de respuesta a incidentes, una obligación reforzada por el requisito de CERT-In de conservar los registros en India durante 180 días.

A10: Gestión inadecuada de condiciones excepcionales

La edición de 2025 llama explícitamente la atención sobre cómo tratan las aplicaciones los errores y las condiciones excepcionales. Una gestión deficiente de errores puede filtrar trazas de pila, rutas internas y detalles de configuración a los atacantes, o hacer que la lógica falle en modo abierto y conceda acceso cuando una comprobación falla en lugar de denegarlo. En ambos casos, un caso límite se convierte en un incidente de seguridad.

Mitigación: fallar de forma segura y cerrada, devolver mensajes de error genéricos a los usuarios registrando el detalle completo en el servidor, y probar deliberadamente entradas excepcionales e inesperadas, no solo el camino feliz.

Cómo ayuda IntelligenceX

El OWASP Top 10 2025 es un mapa de dónde mirar, pero la cobertura solo cuenta si sus aplicaciones se prueban realmente frente a él. IntelligenceX evalúa cada categoría mediante servicios de base manual alineados con OWASP y aporta remediación lista para desarrolladores, un enfoque adecuado para compradores del Reino Unido, EE. UU., la UE e India.

Nuestras pruebas de penetración de aplicaciones web ejercitan cada categoría del Top 10 sobre su aplicación en producción, desde el control de acceso deficiente y la inyección hasta los fallos de registro y de gestión de excepciones, con evidencias de prueba de concepto y una nueva prueba de remediación gratuita. Nuestra revisión de código seguro examina el propio código fuente para detectar fallos criptográficos, de inyección y de integridad que las pruebas de caja negra pueden pasar por alto. Nuestro modelado de amenazas aborda de frente A06 Diseño inseguro, revelando controles ausentes antes de que lleguen a escribirse en el código.

Para las organizaciones reguladas en India, estas pruebas encajan directamente con los deberes de salvaguarda de seguridad de la Ley DPDP y con las expectativas de CERT-In, RBI, SEBI e IRDAI. Para ser claros sobre el alcance: IntelligenceX asesora, evalúa y prepara, y actualmente no está habilitada por CERT-In; no emitimos certificados ni firmamos auditorías regulatorias. Hable con nuestro equipo para definir el alcance de una evaluación de sus aplicaciones.