El OWASP Top 10 es un estándar de concienciación ampliamente utilizado sobre los riesgos de seguridad más importantes en aplicaciones web. Proporciona a los equipos de desarrollo, seguridad y riesgo un lenguaje común para mejorar el diseño, las pruebas y la remediación.
Esta guía refleja la versión actual del OWASP Top 10. Debe utilizarse como punto de partida, no como un programa completo de seguridad de aplicaciones, junto con el modelado de amenazas, las prácticas de desarrollo seguro, la revisión de código, las pruebas y la monitorización continua.
Los diez principales riesgos de seguridad para aplicaciones web según OWASP
A01 — Control de acceso roto
Las debilidades de control de acceso permiten que los usuarios actúen fuera de los permisos previstos, por ejemplo, consultando datos de otra persona, modificando registros protegidos o invocando funciones administrativas. La autorización debe aplicarse en el servidor, denegar por defecto y probarse para cada rol y objeto relevantes.
A02 — Configuración de seguridad incorrecta
Los valores predeterminados inseguros, los servicios innecesarios, los errores demasiado detallados, la falta de endurecimiento y las configuraciones incoherentes pueden exponer una aplicación que, de otro modo, sería sólida. Las organizaciones necesitan líneas base de configuración repetibles, comprobaciones automatizadas y cambios controlados en todos los entornos.
A03 — Fallos en la cadena de suministro de software
Las aplicaciones dependen de paquetes, sistemas de compilación, repositorios y canales de entrega que pueden introducir riesgos. Los equipos deben conocer sus dependencias, proteger los procesos de compilación y publicación, verificar procedencia y firmas, supervisar las dependencias y responder rápidamente ante componentes comprometidos.
A04 — Fallos criptográficos
Los datos sensibles pueden quedar expuestos cuando el cifrado falta, está obsoleto o se implementa incorrectamente. Los algoritmos robustos son solo una parte de la solución: la gestión de claves, la protección del transporte, la minimización de datos y su tratamiento seguro durante todo el ciclo de vida son igual de importantes.
A05 — Inyección
La inyección se produce cuando una entrada no fiable se interpreta como un comando o una consulta. Las interfaces parametrizadas, la codificación contextual de salida, la validación de entradas y la separación entre datos e instrucciones reducen el riesgo en SQL, comandos del sistema operativo, plantillas y otros intérpretes.
A06 — Diseño inseguro
Algunas debilidades se originan en el diseño, no en un fallo de implementación. El modelado de amenazas, el análisis de casos de abuso, los patrones de diseño seguro y los requisitos de seguridad explícitos son necesarios antes de que los controles a nivel de código puedan resultar eficaces.
A07 — Fallos de autenticación
Una verificación de identidad, gestión de credenciales o gestión de sesiones débiles pueden facilitar el secuestro de cuentas. La autenticación multifactor, la recuperación segura, la protección frente a ataques automatizados y unos controles de sesión robustos deben aplicarse según el riesgo.
A08 — Fallos de integridad del software o de los datos
Los sistemas fallan cuando confían en software, actualizaciones, plugins o datos críticos sin verificar su integridad. Deben utilizarse fuentes fiables, artefactos firmados, mecanismos de actualización protegidos y un tratamiento cuidadoso de los datos serializados o procedentes del exterior.
A09 — Fallos de registro y alertas de seguridad
Sin registros significativos, monitorización y alertas accionables, los ataques pueden permanecer sin detectar y las investigaciones pierden fiabilidad. Hay que registrar los eventos relevantes para la seguridad, proteger la integridad de los logs, definir umbrales de respuesta y comprobar periódicamente que las alertas llegan a las personas adecuadas.
A10 — Gestión incorrecta de condiciones excepcionales
Las entradas inesperadas, los tiempos de espera, el agotamiento de recursos y los fallos parciales pueden llevar a las aplicaciones a estados inseguros. Los sistemas deben fallar de forma segura, gestionar los errores de manera coherente, limitar el consumo de recursos y evitar exponer detalles internos sensibles.
Cómo deben utilizar las organizaciones el OWASP Top 10
Utiliza la lista para definir requisitos de seguridad, revisar la arquitectura, formar a desarrolladores, revisar código y realizar pruebas de penetración. Después, amplíala con modelado de amenazas específico de la aplicación, análisis del impacto empresarial y controles para API, servicios cloud, identidad, cadenas de suministro y resiliencia operativa.
Referencia oficial: OWASP Top 10. Para las pruebas dinámicas de aplicaciones, OWASP ZAP está disponible en zaproxy.org.
¿Tu aplicación web es segura?
Sobre el autor
Oscar Calvo Moldes es un profesional de la ciberseguridad con más de 25 años de experiencia práctica. Es cofundador y CTO de Axyom, fundador de MicroHackers y actualmente se centra en la seguridad AI/LLM.
