OWASP Top 10: los errores de seguridad web que siguen rompiendo aplicaciones

La seguridad web no suele fallar por falta de términos sofisticados. Falla porque una aplicación permite hacer algo que no debería: ver datos de otro usuario, ejecutar una consulta mal filtrada, reutilizar una contraseña débil o desplegar una dependencia comprometida. El OWASP Top 10 sigue siendo una de las mejores puertas de entrada para entender esos riesgos. No es una lista para memorizar, sino un mapa de errores habituales que aparecen una y otra vez en aplicaciones reales, desde pequeños paneles internos hasta plataformas críticas expuestas a Internet.

OWASP Top 10 no es una moda, es una lista de fallos recurrentes

OWASP, la Open Worldwide Application Security Project, mantiene desde hace años una clasificación de los riesgos más relevantes en aplicaciones web. La versión actual, OWASP Top 10:2025, sitúa de nuevo el control de acceso roto como el riesgo número uno. Es significativo: seguimos fallando en algo tan básico como comprobar si un usuario puede acceder a una acción o a un dato concreto.

Conviene leer esta lista con una idea clara. OWASP Top 10 no dice que solo existan diez problemas de seguridad. Agrupa familias de errores para facilitar formación, auditorías, revisión de código y priorización: control de acceso, malas configuraciones, cadena de suministro, errores criptográficos, inyecciones, diseño inseguro, autenticación, integridad del software, logging y tratamiento de excepciones.

El control de acceso roto sigue siendo el agujero más peligroso

El control de acceso roto es el fallo que permite a un usuario hacer algo para lo que no está autorizado. No hablamos solo de entrar en un panel de administración. Hablamos de cambiar un identificador en una URL y ver la factura de otro cliente, modificar un recurso ajeno mediante una API o saltarse una restricción porque el frontend oculta un botón, pero el backend no valida nada.

Este tipo de vulnerabilidad es frecuente en APIs REST y aplicaciones con mucha lógica distribuida. El error mental suele ser el mismo: comprobar que el usuario está autenticado, pero no que tenga permiso sobre ese objeto concreto. “Está logado” no significa “puede acceder a todo”. La defensa real pasa por validar autorización en el servidor, aplicar mínimo privilegio y probar escenarios de usuario horizontal y vertical.

La inyección ya no lidera, pero sigue haciendo mucho daño

Durante años, la inyección fue casi sinónimo de seguridad web. SQL injection, command injection, LDAP injection o XSS han llenado manuales, cursos y pruebas técnicas. En el OWASP Top 10:2025 baja posiciones, pero no desaparece. Y no debería relajarnos. Una sola consulta SQL mal construida puede exponer una base de datos completa; un XSS persistente puede secuestrar sesiones o alterar la experiencia de otros usuarios.

La buena noticia es que muchas defensas están maduras. Consultas parametrizadas, ORMs bien usados, validación de entrada, codificación de salida y Content Security Policy reducen muchísimo el riesgo. El problema aparece cuando se mezclan prisas, código heredado, plantillas mal escapadas y confianza excesiva en los datos que llegan del cliente. Todo dato externo debe tratarse como hostil hasta que se demuestre lo contrario.

Las malas configuraciones son el enemigo silencioso del cloud

Uno de los cambios más interesantes de la lista de 2025 es el ascenso de las malas configuraciones de seguridad. Tiene sentido. Hoy una aplicación no es solo código. Es contenedor, variables de entorno, bucket, CDN, API Gateway, secretos, permisos IAM, despliegues CI/CD, reglas de red, cabeceras HTTP y servicios gestionados.

En ese ecosistema, un panel de administración expuesto, un bucket público, un modo debug activo o una política IAM demasiado permisiva pueden ser tan graves como una vulnerabilidad en el código. La seguridad ya no vive únicamente en el repositorio. Vive también en Terraform, Kubernetes, Docker, pipelines y consolas cloud. Por eso el enfoque moderno debe combinar revisión de código con revisión de configuración, inventario, hardening, gestión de secretos y despliegues reproducibles.

La cadena de suministro ya forma parte de la seguridad web

La entrada de los fallos de cadena de suministro de software como categoría destacada refleja una realidad incómoda: muchas aplicaciones dependen de piezas que no controla directamente el equipo que las despliega. Librerías npm, paquetes Python, imágenes Docker, acciones de CI, SDKs externos y dependencias transitivas forman parte del producto final.

El riesgo no está solo en usar una librería vulnerable. También está en consumir un paquete malicioso, no verificar la procedencia de un artefacto, permitir actualizaciones automáticas sin control o desplegar imágenes base obsoletas. Una aplicación puede estar bien programada y aun así quedar comprometida por una dependencia. Aquí entran piezas como SBOM, firma de artefactos, bloqueo de versiones, análisis de vulnerabilidades y políticas claras de actualización.

OWASP sirve para desarrollar mejor, no solo para auditar

El error habitual es usar OWASP Top 10 como una lista que se consulta al final, cuando la aplicación ya está hecha. Ese enfoque llega tarde. La seguridad útil empieza antes: en el diseño de permisos, en el modelo de datos, en la gestión de sesiones, en la elección de dependencias y en la observabilidad del sistema.

En Tecnoic ya hemos tratado la seguridad a nivel de aplicación y su relación con el ENS, pero OWASP permite bajar un escalón más: pasar de la política general al fallo concreto que rompe un sistema. La pregunta no debería ser “¿cumplimos OWASP?”, sino “¿qué controles hemos incorporado para que estos errores no lleguen a producción?”. Autorización fuerte, configuración segura, criptografía correcta y logging útil no son extras; son diseño básico.

Conclusión

OWASP Top 10 funciona porque pone nombre a problemas que se repiten con demasiada frecuencia. No sustituye una estrategia de seguridad completa, pero ayuda a enfocar esfuerzos donde más daño puede haber. Si desarrollas, administras o contratas aplicaciones web, conviene tener esta lista cerca. ¿Cuál de estos fallos te parece más infravalorado en proyectos reales?