Cerramos el módulo 1 con el primer mapa de riesgos de BazarNube: una tabla de activos (datos de clientes, pagos, precios y pedidos, disponibilidad, módulo legacy en Java) clasificados con la tríada CIA. Ese mapa nos dice qué nos preocupa, pero todavía en un lenguaje casero. Ahora el equipo necesita un vocabulario compartido y reconocido por toda la industria para nombrar esas amenazas. Ese vocabulario existe, y es probablemente el documento de seguridad más famoso del mundo: el OWASP Top Ten. En esta lección lo presentamos —qué es, cómo se elabora, para qué sirve y para qué no— y recorremos su edición vigente (2021) nombrando sus diez categorías. No agotaremos ninguna: cada una tiene su desarrollo en el módulo 3.

Esta es la primera parada de nuestra "caja de herramientas OWASP". Aquí solo abrimos la caja y describimos la herramienta; el manual de uso detallado llega después.

1. Qué es el OWASP Top Ten (y qué no es)
2. Cómo se elabora: datos + encuesta
3. Para qué sirve y para qué NO sirve
4. La edición vigente: Top Ten 2021
5. Las diez categorías A01–A10
6. Qué cambió de 2017 a 2021
7. El Top Ten aplicado al mapa de riesgos de BazarNube

El OWASP Top Ten es un documento de concienciación que recoge los diez riesgos de seguridad más críticos para las aplicaciones web, según el consenso de la comunidad y los datos disponibles. Se publica de forma periódica (cada 3–4 años aproximadamente) y es, con diferencia, el proyecto flagship más conocido de OWASP.

La palabra clave es concienciación (awareness). El Top Ten existe para responder a una pregunta muy concreta: "Si solo puedo prestar atención a un puñado de cosas, ¿por dónde empiezo?". Es un punto de partida, una brújula, un mínimo común denominador que cualquier persona que desarrolle software web debería conocer.

Es igual de importante entender qué NO es:

• NO es un estándar exhaustivo. No lista todas las vulnerabilidades posibles; lista las diez categorías más relevantes. Cumplir el Top Ten no significa "estar seguro", significa "haber cubierto lo más básico y frecuente".
• NO es una checklist de certificación. No existe un sello de "cumplo el Top Ten". Para verificación formal, requisito a requisito, OWASP tiene otro proyecto: ASVS (lección 02-02).
• NO es un manual de remediación paso a paso. Describe los riesgos y orienta, pero el detalle de cómo mitigarlos se apoya en otros recursos (como las Cheat Sheets, lección 02-05).

Regla mental: el Top Ten te dice dónde mirar primero; no te dice que hayas terminado de mirar.

El Top Ten no se inventa en una reunión: se construye con una metodología mixta que combina evidencia y criterio experto. Entender cómo se hace ayuda a leerlo con sentido crítico.

Las dos fuentes son:

1. Datos aportados por la comunidad. Empresas, consultoras y proveedores de herramientas donan datos anonimizados sobre qué vulnerabilidades encuentran en aplicaciones reales. De ahí salen métricas como la incidencia (con qué frecuencia aparece una debilidad) y la cobertura.
2. Encuesta a la comunidad (industry survey). Como los datos históricos solo reflejan lo que ya se sabía buscar, se pregunta además a profesionales del sector qué riesgos consideran más importantes mirando hacia adelante. Esto permite incluir amenazas emergentes que aún no aparecen masivamente en los datos.

Además, el Top Ten se organiza en categorías de riesgo, no en vulnerabilidades concretas. Por ejemplo, "Inyección" es una categoría que agrupa SQL injection, inyección de comandos, LDAP, etc. Esta agrupación es deliberada: hace la lista estable y comprensible en lugar de una lista interminable de CVEs.

Para que el equipo de BazarNube use el Top Ten con criterio, conviene tener clarísimos sus usos legítimos y sus abusos habituales.

La idea de fondo: el Top Ten es un excelente comienzo y un pésimo final. Un error clásico de gestión es declarar "hemos revisado el Top Ten, ya estamos seguros" y cerrar el tema. Lo correcto es usarlo como rampa de entrada hacia herramientas más completas (ASVS para verificar, SAMM para madurar el programa, ZAP para probar).

La edición vigente en el momento de este curso es el OWASP Top Ten 2021. Introdujo varios cambios de fondo respecto a la anterior (2017):

• Reordenación por datos más rigurosos y por la encuesta.
• Reagrupación de categorías (algunas se fusionaron, otras se ampliaron).
• Foco creciente en causas de diseño y no solo en síntomas concretos.

Trabajaremos sobre esta edición 2021 durante todo el curso. Es la referencia que el módulo 3 desarrolla categoría por categoría.

Aquí está la lista completa. Solo las nombramos, con una frase que dé la idea; el desarrollo real (ejemplos, código vulnerable de BazarNube, mitigaciones) es el contenido del módulo 3.

Dos matices que a veces confunden y que conviene fijar ya:

• XSS (Cross-Site Scripting) dejó de ser una categoría propia y quedó integrada en A03: Injection. Aun así, por su importancia, el módulo 3 le dedica una lección específica.
• XXE (XML External Entities) también dejó de ser categoría propia y quedó absorbida en A05: Security Misconfiguration. El módulo 3 igualmente lo trata en detalle.

Comparar ediciones ayuda a entender la evolución del riesgo. Este es el resumen de los cambios más significativos entre 2017 y 2021:

La lectura estratégica de estos cambios: la seguridad web maduró de perseguir bugs concretos a atacar causas de raíz. Las dos novedades —Insecure Design y SSRF— lo ilustran: una nos obliga a pensar antes de programar; la otra refleja arquitecturas modernas (microservicios, nube, metadatos internos) donde el propio servidor puede ser engañado.

Volvamos al mapa de riesgos que cerró el módulo 1. Aquel mapa hablaba en términos de activos y CIA. Ahora podemos traducirlo al vocabulario del Top Ten, y así empezar a poblar el backlog de hallazgos con etiquetas reconocibles:

Lucía (backend lead) propone algo sensato: usar los códigos A01–A10 como etiquetas en el backlog. Así, cuando aparezca un hallazgo, no se apunta como "problema raro del buscador", sino como "A03 – Injection en /api/buscar". Ese pequeño gesto conecta el trabajo diario de BazarNube con un estándar mundial y prepara el terreno para el módulo 3.

Fíjate en que no todos los riesgos encajan aún: por ejemplo, no hemos etiquetado nada como A08 o A10 todavía. Eso es normal y sano: el Top Ten es una guía de dónde mirar, no una obligación de "rellenar" las diez casillas.

• Tratar el Top Ten como una checklist de "aprobado". Cubrir las diez categorías no equivale a estar seguro; es el mínimo. Para verificar de verdad, usa ASVS (lección siguiente).
• Confundir categorías con vulnerabilidades. "Injection" no es un bug, es una familia de bugs. Un mismo hallazgo puede tocar varias categorías.
• Usar una edición antigua sin darse cuenta. Mucha documentación en internet sigue citando el Top Ten 2017 (con XSS y XXE como categorías propias). Verifica siempre que trabajas sobre 2021.
• Buscar aquí el "cómo se arregla". El Top Ten conciencia; la remediación detallada vive en las Cheat Sheets y en el módulo 3. No te frustres si esta lección no te da el parche exacto: no es su función.
• Consejo: memoriza al menos A01, A03 y A06 de entrada. Son, para un e-commerce típico como BazarNube, los que más probablemente te vas a encontrar en la práctica.

Ejercicio 1. Clasifica cada situación de BazarNube en la categoría Top Ten 2021 más adecuada: (a) el frontend de Marc muestra sin escapar un comentario de producto que contiene <script>; (b) el Dockerfile del módulo Java arranca en modo debug con la consola de administración expuesta; (c) un atacante prueba miles de contraseñas contra /login sin que nada lo frene.

Ejercicio 2. Explica en 3–5 líneas por qué el Top Ten no basta como criterio para afirmar ante un cliente que "BazarNube cumple con la seguridad exigida", y qué proyecto de OWASP encajaría mejor para esa afirmación.

Ejercicio 3. El Top Ten 2021 introdujo dos categorías nuevas respecto a 2017. Nómbralas y, para cada una, da un ejemplo plausible en BazarNube.

Solución 1. (a) A03 Injection (concretamente XSS, que en 2021 vive dentro de Injection); (b) A05 Security Misconfiguration (configuración insegura, servicios de administración expuestos —y aquí también podría entrar XXE si procesa XML); (c) A07 Identification and Authentication Failures (falta de protección contra fuerza bruta / credential stuffing).

Solución 2. El Top Ten es un documento de concienciación, no un estándar de verificación: cubre solo las diez categorías más frecuentes y no define requisitos comprobables uno a uno. Afirmar cumplimiento requiere un estándar de requisitos verificables, y ese es OWASP ASVS, que veremos en la lección 02-02: permite decir "hemos verificado los requisitos de nivel X" con evidencia concreta.

Solución 3. Las dos novedades son A04: Insecure Design y A10: SSRF. Ejemplos en BazarNube: (A04) el proceso de checkout se diseñó sin controles antifraude ni límite de intentos de pago, un fallo de diseño más que de código; (A10) un endpoint que descarga la imagen de un producto a partir de una URL facilitada por el usuario podría ser engañado para pedir recursos internos de la red (metadatos del contenedor, servicios privados).

Has conocido la primera herramienta de la caja OWASP: el Top Ten, un documento de concienciación que lista los diez riesgos web más críticos, elaborado con datos + encuesta y organizado en categorías de riesgo. Sabes para qué sirve (punto de partida, vocabulario común, priorización) y para qué no (no es estándar de certificación ni lista exhaustiva). Has recorrido la edición 2021 con sus categorías A01–A10, entendido las fusiones (XSS→A03, XXE→A05) y las novedades (Insecure Design y SSRF), y has empezado a etiquetar el backlog de BazarNube con este vocabulario.

Pero el propio Top Ten nos ha dejado una pregunta abierta: si conciencia pero no verifica, ¿cómo demostramos, requisito a requisito, que BazarNube es seguro? Esa es exactamente la función de la siguiente herramienta. En la lección 02-02 presentamos OWASP ASVS, el estándar que convierte "estar concienciado" en "poder verificarlo".