Por qué siguen cayendo los mismos errores

El OWASP Top 10 lleva más de veinte años documentando las vulnerabilidades más críticas de las aplicaciones web. Se actualiza, se publicita, se estudia… y sin embargo, cuando auditamos una aplicación, nos encontramos una y otra vez con las mismas familias de fallos. No porque los equipos sean malos, sino porque la seguridad se degrada por defecto: si nadie la trabaja activamente, cada sprint la erosiona un poco.

Este artículo no es la lista oficial del OWASP —esa la tienes en owasp.org—, sino lo que de verdad aparece en nuestras auditorías, cómo detectarlo a tiempo y qué hacer al respecto.

Las vulnerabilidades que encontramos en casi todas las auditorías

1. Control de acceso roto (el campeón absoluto)

Es el número uno del OWASP y también el nuestro. El patrón típico: la aplicación comprueba que estás autenticado, pero no que el recurso sea tuyo. Cambiar un /facturas/1024 por /facturas/1023 y ver la factura de otro cliente es el clásico que sigue apareciendo en aplicaciones maduras. Se llama IDOR y se corrige verificando la propiedad del recurso en el servidor, en cada petición, no solo en la interfaz.

2. Sesiones y autenticación mal gestionadas

Tokens que no caducan nunca, sesiones que sobreviven al cambio de contraseña, «cerrar sesión» que no invalida nada en el servidor, y APIs que aceptan credenciales por la URL (donde quedan registradas en logs y proxies). La autenticación suele estar bien el día que se implementa; el problema es todo lo que se construye alrededor después.

3. Inyección: viva y coleando

SQL, comandos, plantillas… En 2026 la inyección sigue apareciendo, sobre todo en código «periférico»: endpoints antiguos, informes, buscadores avanzados, integraciones internas. Los ORM protegen en el camino feliz, pero basta una consulta construida a mano en un rincón olvidado.

4. Exposición de datos sensibles

Errores que devuelven trazas completas al usuario, respuestas de API que serializan el objeto entero (con campos que la interfaz nunca muestra pero el JSON sí), logs con datos personales o credenciales, y ficheros de respaldo accesibles públicamente. La fuga de datos rara vez es un sofisticado ataque: suele ser una respuesta demasiado generosa.

5. Configuración insegura

Cabeceras de seguridad ausentes, CORS abierto a cualquier origen, paneles de administración expuestos, buckets de almacenamiento públicos por accidente, modo debug en producción. Es la categoría más fácil de detectar y de corregir, y una de las que más aparece.

6. Dependencias vulnerables

La aplicación moderna es 80 % código de terceros. Librerías con vulnerabilidades publicadas hace meses, imágenes de contenedor que nunca se reconstruyen, paquetes abandonados que nadie vigila. Sin un proceso de actualización continua, el inventario de dependencias se convierte en una bomba de relojería silenciosa.

7. Secretos en el código

Claves de API, contraseñas y certificados en el repositorio — a veces en el último commit, a veces enterrados en el historial (donde siguen estando). Cualquier persona con acceso al repo, presente o pasada, los tiene. La regla es simple: los secretos viven en un gestor de secretos o en el entorno, nunca en git.

Señales de alarma que puedes comprobar sin ser técnico

• ¿Cambiar un número en la URL te deja ver datos de otro usuario? (No lo pruebes en producción de terceros; pregúntale a tu equipo si lo verifican en el servidor.)
• ¿Los errores de la aplicación muestran detalles técnicos (trazas, SQL, rutas)?
• ¿Las contraseñas de servicios están en un documento compartido o en el código?
• ¿Cuándo se actualizaron por última vez las dependencias del proyecto? ¿Hay algún proceso para ello?
• ¿Cerrar sesión en un dispositivo la cierra de verdad en todos?

Si alguna respuesta incomoda, hay trabajo que hacer.

Lo que NO es suficiente

Conviene decirlo claro: tener un WAF delante no corrige un control de acceso roto (solo lo disimula hasta que alguien encuentra el camino), el antivirus del servidor no ve vulnerabilidades de aplicación, y «pasamos un escáner hace un año» no es un programa de seguridad, es una foto. Las herramientas automáticas encuentran una parte —la fácil—; las vulnerabilidades de lógica de negocio, que son las más dañinas, solo las encuentra una revisión experta.

Cómo es una auditoría de seguridad bien hecha

Una auditoría seria combina tres capas: análisis automático (dependencias, configuración, superficie expuesta), revisión manual del código y de la lógica de acceso (donde están los fallos que importan) y pruebas sobre la aplicación en funcionamiento. El resultado no debe ser un PDF de 200 hallazgos sin contexto, sino una lista priorizada: qué es crítico, qué es urgente, qué es mejorable — y cómo corregir cada cosa con esfuerzo estimado.

¿Hace cuánto que nadie mira tu aplicación con ojos de atacante?

Si tu aplicación maneja datos de clientes, pagos o información sensible, la pregunta no es si tiene vulnerabilidades, sino cuáles y cuántas. Nuestras auditorías de seguridad te dan la foto real —código, configuración y dependencias— con un plan de corrección priorizado que tu equipo puede ejecutar desde el primer día. Hablemos de tu aplicación.