OWASP Top 10 explicado: los riesgos de seguridad más críticos en aplicaciones web

Si trabajas en cualquier área cercana a la seguridad de aplicaciones, has oído hablar del OWASP Top 10. Se cita en presentaciones para la junta directiva, se incluye en requisitos de cumplimiento y se referencia en casi todos los cuestionarios de seguridad que una empresa de software recibirá alguna vez. Pese a toda esa visibilidad, también suele malinterpretarse: se lo trata como una certificación que hay que aprobar, en lugar de lo que realmente es: un vocabulario compartido para los riesgos de seguridad en aplicaciones web más críticos que los equipos enfrentan hoy.

Esta guía recorre el OWASP Top 10:2025 en orden, una categoría a la vez. Para cada una, explicamos qué significa, un ejemplo concreto de cómo sale mal y cómo prevenirla o detectarla. Luego vemos cómo incorporar estos riesgos en tu ciclo de vida de desarrollo de software para que se detecten temprano, y no después de un incidente. El objetivo es práctico: al final, deberías poder explicar cada riesgo a un ingeniero o a una parte interesada y saber dónde encaja en tu estrategia de pruebas.

¿Qué es OWASP?

OWASP —el Open Worldwide Application Security Project— es una fundación sin fines de lucro dedicada a mejorar la seguridad del software. Está impulsada por la comunidad y es neutral frente a proveedores, lo que explica en gran parte por qué su orientación tiene peso: los materiales son producidos por profesionales, están disponibles de forma gratuita y no están vinculados a ningún producto comercial.

OWASP publica una amplia variedad de recursos —guías de pruebas, cheat sheets, referencias de codificación segura y herramientas—, pero su resultado más conocido, con diferencia, es el OWASP Top 10. Publicado por primera vez en 2003 y actualizado de forma periódica, el Top 10 es un documento de consenso que clasifica los riesgos de seguridad en aplicaciones web más significativos con base en datos del sector, combinados con una encuesta a la comunidad para captar amenazas emergentes que los datos en bruto por sí solos podrían pasar por alto. Cuando alguien dice que un producto "cubre el OWASP Top 10", quiere decir que aborda estas diez amplias categorías de riesgo.

Un matiz importante: cada entrada es una categoría, no una única vulnerabilidad. "Injection", por ejemplo, abarca SQL injection, command injection y varias otras variantes. Esa estructura es deliberada: mantiene la lista estable y conceptual, en lugar de un blanco móvil de CVE específicos.

El OWASP Top 10:2025

A continuación están las diez categorías del OWASP Top 10:2025, en su orden oficial. La clasificación refleja una combinación de con qué frecuencia aparece cada debilidad, cuán explotable tiende a ser y el posible impacto en el negocio. Una nota antes de comenzar: el OWASP Top 10 se revisa de forma periódica a medida que cambia la manera en que construimos y atacamos el software, y las categorías siguientes reflejan la versión de 2025, la edición actual y la actualización de la antigua lista de 2021.

A01:2025 — Broken Access Control

El control de acceso impone lo que un usuario autenticado tiene permiso de hacer. Cuando esas verificaciones faltan, están incompletas o se aplican solo en la interfaz, los usuarios pueden alcanzar datos y acciones que deberían estar fuera de su alcance. Esta categoría ocupa de nuevo el primer puesto en 2025 porque la lógica de autorización es engañosamente difícil de acertar en cada endpoint.

Ejemplo: Una API devuelve un pedido por ID en /api/orders/1043. Un usuario cambia el ID a 1044 y ve el pedido de otra persona: una clásica referencia directa e insegura a objetos (IDOR). El servidor autenticó al usuario, pero nunca comprobó si este usuario es dueño de ese pedido.

Cómo prevenirlo y detectarlo: Deniega por defecto e impón las decisiones de acceso del lado del servidor en cada solicitud, en lugar de confiar en el cliente. Centraliza la lógica de autorización en vez de dispersar verificaciones improvisadas. Escribe pruebas que intenten el acceso entre cuentas y usa pruebas en tiempo de ejecución para sondear endpoints con identificadores y roles manipulados. Registra en el log las fallas de control de acceso para que los intentos repetidos sean visibles.

A02:2025 — Security Misconfiguration

La configuración incorrecta abarca ajustes predeterminados inseguros, mensajes de error detallados, funciones innecesarias dejadas habilitadas, almacenamiento en la nube abierto y falta de hardening. Subió al segundo puesto en 2025, lo que refleja cuánto del riesgo moderno reside ahora en la configuración y no en el código: a medida que los stacks se vuelven más complejos, con contenedores, orquestación y servicios gestionados, la superficie para un ajuste equivocado crece con ellos.

Ejemplo: Un bucket de almacenamiento en la nube queda legible de forma pública, o una aplicación se despliega con una cuenta y contraseña de administrador predeterminadas aún activas, o un stack trace expone rutas internas y versiones de bibliotecas a los usuarios finales. Una configuración de fetch permisiva puede incluso abrir la puerta a un server-side request forgery (SSRF), en el que se coacciona a una aplicación para que llame a un endpoint de metadatos interno.

Cómo prevenirlo y detectarlo: Aplica hardening de forma sistemática, elimina componentes y funciones que no se usen y aplica la misma línea base segura en cada entorno, de modo que staging coincida con producción. Automatiza las verificaciones de configuración en tu pipeline y escanea los entornos en ejecución. Las pruebas dinámicas son muy adecuadas para detectar mensajes de error expuestos, páginas predeterminadas y encabezados permisivos en tiempo de ejecución.

A03:2025 — Software Supply Chain Failures

En 2025, la categoría anteriormente conocida como "Vulnerable and Outdated Components" (componentes vulnerables y desactualizados) se amplió y se renombró a Software Supply Chain Failures (fallas en la cadena de suministro de software), un reconocimiento de que el riesgo es mucho más amplio que una única biblioteca obsoleta. Las aplicaciones modernas se ensamblan a partir de dependencias de código abierto, pero también las construyen pipelines y se entregan a través de canales de distribución. Una falla en cualquier punto de esa cadena —los componentes que incorporas, los sistemas que los ensamblan o los canales que los distribuyen— se convierte en tu problema.

Ejemplo: Una aplicación depende de una biblioteca ampliamente utilizada con un CVE crítico publicado que el equipo nunca actualizó, y un atacante explota la falla conocida. O una dependencia de compilación comprometida inyecta código malicioso durante el CI, de modo que la manipulación ocurre aguas arriba de cualquier revisión de código: no se requiere investigación novedosa, solo un eslabón desprotegido en la cadena.

Cómo prevenirlo y detectarlo: Mantén un inventario de tus dependencias (un software bill of materials ayuda) y monitoréalas de forma continua frente a bases de datos de vulnerabilidades. El software composition analysis automatiza esto: señala componentes vulnerables y desactualizados, incluidas las dependencias transitivas que no agregaste directamente. Extiende ese escrutinio al propio pipeline: fija y verifica las herramientas de compilación, protege tus sistemas de CI/CD y trata la ruta de compilación y distribución como parte de tu superficie de ataque.

A04:2025 — Cryptographic Failures

A veces planteada como "Sensitive Data Exposure" (exposición de datos sensibles), esta categoría trata sobre fallas en la forma en que se protegen los datos en tránsito y en reposo: cifrado débil o ausente, mala gestión de claves o datos sensibles que sencillamente no deberían haberse almacenado. La falla es la causa raíz; la exposición es la consecuencia.

Ejemplo: Una aplicación almacena contraseñas usando un hash rápido y sin salt, o transmite tokens de sesión por HTTP en texto plano en un salto interno. Cuando un atacante obtiene una copia de la base de datos o intercepta el tráfico, los datos son trivialmente legibles.

Cómo prevenirlo y detectarlo: Clasifica qué datos posees y minimiza lo que conservas. Impón un cifrado de transporte fuerte en todas partes, usa algoritmos modernos y bien evaluados, y aplica hash a las contraseñas con una función lenta, con salt y diseñada para ese fin. Gestiona las claves adecuadamente y rótalas. Las herramientas de escaneo y las revisiones de configuración pueden señalar protocolos débiles, secretos codificados directamente en el código y cifrados obsoletos.

A05:2025 — Injection

La inyección ocurre cuando una entrada no confiable se interpreta como parte de un comando o una consulta. El SQL injection es el arquetipo, pero la categoría también abarca OS command injection, LDAP injection y cross-site scripting (XSS).

Ejemplo: Un formulario de inicio de sesión construye una consulta SQL concatenando el nombre de usuario directamente en la sentencia. Un atacante envía ' OR '1'='1 y omite la autenticación, o extrae la tabla de usuarios completa.

Cómo prevenirlo y detectarlo: Usa consultas parametrizadas y prepared statements para que los datos nunca puedan ejecutarse como código. Valida y, cuando corresponda, codifica la entrada según su contexto de destino. El análisis estático es particularmente eficaz aquí: rastrea la entrada no confiable desde el origen hasta el destino (source to sink) y señala la construcción insegura de consultas y el manejo de la salida antes de que el código se despliegue.

A06:2025 — Insecure Design

Esta categoría desplaza la atención aguas arriba, hacia fallas en la arquitectura y el diseño, en lugar de errores de implementación. Una función perfectamente codificada aún puede ser insegura si el diseño nunca contempló el abuso. No puedes parchear tu salida de un control de seguridad faltante que nunca se diseñó.

Ejemplo: Un flujo de restablecimiento de contraseña usa preguntas de seguridad cuyas respuestas se encuentran fácilmente en línea, sin limitación de tasa. El código funciona exactamente como está escrito; el diseño simplemente no consideró cómo lo abusaría un atacante.

Cómo prevenirlo y detectarlo: Introduce el threat modeling temprano, cuando cambiar el diseño todavía es barato. Establece patrones de diseño seguro y arquitecturas de referencia que los equipos reutilicen. Escribe casos de abuso junto con las historias de usuario y valida los límites de la lógica de negocio (límites de tasa, topes de transacciones, restricciones de flujo de trabajo) como requisitos de primera clase y no como algo secundario.

A07:2025 — Authentication Failures

Renombrada en 2025 a partir de "Identification and Authentication Failures" (fallas de identificación y autenticación), esta categoría abarca debilidades en confirmar quién es un usuario y mantener esa identidad de forma segura: políticas de contraseñas débiles, exposición al credential stuffing, mala gestión de sesiones e implementaciones defectuosas de múltiples factores.

Ejemplo: Una aplicación permite intentos de inicio de sesión ilimitados, sin bloqueo ni throttling, lo que deja a un atacante ejecutar listas de credential stuffing contra ella. O los tokens de sesión no se rotan tras el inicio de sesión, lo que los deja vulnerables a la fijación.

Cómo prevenirlo y detectarlo: Ofrece y fomenta la autenticación multifactor, impón protección contra la adivinación automatizada (limitación de tasa, bloqueos, verificación de contraseñas filtradas) y gestiona las sesiones con cuidado: rota los identificadores al iniciar sesión, establece atributos seguros en las cookies y expira las sesiones de forma apropiada. Prefiere frameworks de autenticación bien probados antes que crear el tuyo propio.

A08:2025 — Software or Data Integrity Failures

Esta categoría aborda el código y la infraestructura que no logran protegerse contra las violaciones de integridad: confiar en plugins, bibliotecas o actualizaciones de fuentes sin verificar que no hayan sido manipulados. Surgió directamente de ataques de cadena de suministro de gran repercusión y se ubica cerca del A03, pero se enfoca específicamente en la verificación de la integridad, más que en la amplitud de la cadena de suministro.

Ejemplo: Un pipeline de compilación descarga una actualización por un canal no verificado, o una aplicación deserializa datos no confiables sin comprobaciones. Un artefacto comprometido o malicioso fluye directo a producción porque nada verificó su integridad.

Cómo prevenirlo y detectarlo: Usa paquetes firmados y verifica las firmas, fija las dependencias a versiones conocidas como buenas y protege tu pipeline de CI/CD para que las etapas de compilación y despliegue no puedan manipularse. Evita la deserialización insegura de datos no confiables. Trata tu sistema de compilación como infraestructura de producción, que merece el mismo escrutinio que tu aplicación.

A09:2025 — Security Logging and Alerting Failures

No puedes responder a lo que no puedes ver. Reformulada en 2025 como Security Logging and Alerting Failures (fallas de registro de logs y alertas de seguridad), esta categoría trata sobre un registro de logs, una generación de alertas y la respuesta que debería seguirlos, todos insuficientes: la brecha que permite que las filtraciones pasen inadvertidas durante semanas o meses. Rara vez causa el compromiso inicial, pero empeora drásticamente el resultado.

Ejemplo: Una serie de inicios de sesión fallidos seguida de uno exitoso desde una ubicación inusual no genera ninguna alerta, y los eventos de autenticación no se registran en absoluto. La intrusión solo se descubre cuando los datos aparecen en otro lugar.

Cómo prevenirlo y detectarlo: Registra en el log los eventos relevantes para la seguridad —inicios de sesión, fallas de control de acceso, transacciones de alto valor— con suficiente contexto para investigar, y asegúrate de que los logs sean resistentes a la manipulación y se recopilen de forma centralizada. Define alertas para patrones sospechosos y ensaya un plan de respuesta a incidentes para que la detección realmente conduzca a la acción. Ten cuidado de no registrar en el log los propios datos sensibles.

A10:2025 — Mishandling of Exceptional Conditions

Nueva en 2025, esta categoría aborda cómo se comportan las aplicaciones cuando algo sale mal: manejo inadecuado de errores, errores lógicos en casos límite y el hábito peligroso de fallar en modo abierto en lugar de cerrado. Cuando surge una condición inesperada y el código toma la ruta insegura por defecto, un atacante puede provocar deliberadamente esas condiciones para eludir los controles.

Ejemplo: Una verificación de autorización lanza una excepción cuando un servicio aguas abajo es inalcanzable, y el bloque catch registra el error en el log pero deja que la solicitud continúe, de modo que un usuario alcanza un recurso protegido precisamente porque algo se rompió. Las respuestas de error detalladas también pueden filtrar stack traces y detalles internos que ayudan a un atacante a mapear el sistema.

Cómo prevenirlo y detectarlo: Diseña pensando en la falla: decide de forma explícita qué debe ocurrir cuando una verificación no puede completarse y haz que el resultado por defecto sea el seguro. Maneja las excepciones de forma deliberada en lugar de tragártelas, devuelve mensajes de error genéricos a los usuarios mientras registras los detalles internamente, y prueba los caminos infelices —entrada malformada, timeouts, caídas de dependencias— y no solo los caminos felices.

Cómo abordar el OWASP Top 10 en tu SDLC

Leer la lista es la parte fácil. El verdadero trabajo es construir defensas que detecten estos riesgos de forma continua, sin frenar la ingeniería a paso de tortuga. Ninguna técnica por sí sola cubre las diez categorías, así que la respuesta práctica es combinar capas de controles complementarios a lo largo del ciclo de vida de desarrollo, desplazando la seguridad hacia la izquierda (shift left) para que los problemas se encuentren mientras aún son baratos de corregir.

El diseño seguro va primero. El Insecure Design (A06) existe precisamente porque las herramientas no pueden adaptar retroactivamente un control que nunca se concibió, y lo mismo vale para el Mishandling of Exceptional Conditions (A10), donde fallar de forma segura es una decisión de diseño. El threat modeling, los casos de abuso y los patrones seguros reutilizables detectan clases enteras de riesgo antes de que se escriba una línea de código. Esta es la inversión de mayor apalancamiento que puedes hacer.

El análisis estático (SAST) cubre las fallas a nivel de código. La Injection (A05), muchos errores de control de acceso (A01), las debilidades criptográficas (A04) y el manejo inseguro de errores (A10) aparecen como patrones identificables en el código fuente. El SAST rastrea la entrada no confiable desde el origen hasta el destino (source to sink) y señala la construcción insegura de consultas, el uso débil de criptografía y los secretos codificados directamente en el código, idealmente de forma inline en el pull request del desarrollador, donde el contexto está más fresco.

El software composition y el análisis de la cadena de suministro (SCA) cubren tus dependencias, y ahora más que nunca. Con las Software Supply Chain Failures (A03) ampliadas para 2025 y las Software or Data Integrity Failures (A08) a su lado, la cadena de suministro es una de las partes de más rápido crecimiento en la lista. El SCA inventaría tus dependencias de código abierto, incluidas las transitivas, y las coteja de forma continua con vulnerabilidades conocidas para que un componente riesgoso se detecte antes del merge. Extender esa visibilidad a las herramientas de compilación y a la integridad del pipeline es lo que marca la diferencia frente a los ataques modernos de cadena de suministro.

El análisis dinámico (DAST) cubre el comportamiento en tiempo de ejecución. La Security Misconfiguration (A02), las brechas de autenticación (A07), las fallas de control de acceso (A01) y el manejo de condiciones excepcionales (A10) —incluidos problemas como el SSRF, que emergen a través de una configuración permisiva— a menudo solo se revelan en una aplicación en ejecución. El DAST ejercita la aplicación desplegada de la forma en que lo haría un atacante, revelando mensajes de error expuestos, configuraciones permisivas y autorización rota que las vistas estáticas no captan.

El registro de logs y las alertas cierran el ciclo. Las Security Logging and Alerting Failures (A09) son un recordatorio de que la prevención nunca es perfecta. Instrumenta los eventos relevantes para la seguridad, centraliza y protege tus logs, y genera alertas ante patrones sospechosos, de modo que, cuando algo se escape, lo veas en horas y no en meses.

Hilvanar todo esto a mano —herramientas separadas, dashboards separados, colas de triaje separadas— es donde muchos programas se estancan. Aquí es donde una capa de seguridad consolidada se gana su lugar. Rainforest reúne SAST, SCA y DAST en tu flujo de trabajo existente, asignando los hallazgos de vuelta a categorías como el OWASP Top 10 y encontrando a los desarrolladores en el pull request en lugar de en un informe trimestral. El resultado es cobertura de toda la lista sin pedir a los ingenieros que se conviertan en especialistas de seguridad a tiempo completo.

Si estás construyendo o madurando un programa de seguridad de aplicaciones, comienza por mapear tu cobertura actual frente a estas diez categorías y luego cierra las brechas con pruebas automatizadas en tu pipeline. Para ver cómo un enfoque unificado encaja en tu SDLC, explora la plataforma de pruebas de seguridad de aplicaciones de Rainforest, o lee nuestra guía complementaria, Qué es la seguridad de aplicaciones, para el panorama más amplio.