saltar al contenido
sec/atlas
base de conocimiento · owasp top 10

El OWASP Top 10, en código.

Cada uno de los diez riesgos web explicado, con código vulnerable y corregido en varios lenguajes y la prueba que demuestra la corrección.

$ haz clic en una tarjeta para ver los detalles · ctrl+k para buscar

mapa de aprendizaje

Los temas están organizados por nivel, de los fundamentos a lo avanzado. Las flechas van del requisito previo a lo que se apoya en él. Selecciona un tema para ver una vista previa o sigue el siguiente paso destacado.

Tu siguiente paso

0 de 10 estudiados
empezar este tema

01 Fundamentos

Las ideas sobre las que se apoya todo lo demás.

02 Práctica

Aplica los controles y haz que funcionen en la práctica.

03 Avanzado

Diseña, escala y opera en profundidad.

  • estudiado
  • listo para estudiar
  • faltan requisitos previos

dónde se decide cada riesgo

Del diseño a la operación: cada riesgo tiene una fase donde prevenir es barato. Cada chip abre el tema correspondiente.

  1. 01diseño

    decide qué debe ser imposible

    modelos de amenazas y casos de abusoquién puede hacer qué, en cada solicitudrequisitos de seguridad (ASVS)

    gate: toda funcionalidad tiene casos de abuso y una regla de autorización antes del código

  2. 02código

    maneja entradas, secretos e identidad de forma segura

    mantén los datos lejos de las instruccionesprotege los datos en reposo y en tránsitodemuestra quién es el usuario

    gate: los patrones peligrosos se bloquean en la revisión y en el CI

  3. 03entrega

    entrega código verificado con configuraciones seguras

    conoce y fija aquello de lo que dependesverifica lo que ejecutasconfiguración endurecida y escaneada

    gate: solo los artefactos firmados, escaneados y endurecidos llegan a producción

  4. 04operación

    detecta ataques y falla de forma segura

    logs que se convierten en alertaserrores que niegan, no filtranrunbooks y respuesta

    gate: un ataque se detecta, se contiene y deja rastro

temas

A01 Broken Access Control
La autenticación dice quién eres; el control de acceso dice qué puedes hacer. Cuando el servidor olvida verificar en cada solicitud, cambiar un id en una URL es todo lo que necesita un atacante.
técnica· etapa: design
A02 Security Misconfiguration
Los valores por defecto se hacen para la comodidad, no para internet. Una bandera de debug, un bucket abierto, un error detallado o una contraseña por defecto convierten código correcto en un incidente.
práctica· etapa: ship
A03 Software Supply Chain Failures
Tu aplicación es en su mayor parte código de otras personas. Una biblioteca vulnerable, un paquete malicioso o un paso de build manipulado llega a producción con tu nombre.
práctica· etapa: ship
A04 Cryptographic Failures
La criptografía rara vez se rompe; se omite, se configura mal o se usa mal. El transporte en texto plano, los hashes de contraseña rápidos y las claves incrustadas en el código son la forma en que los datos realmente se filtran.
técnica· etapa: code
A05 Injection
Cuando los datos y las instrucciones viajan en la misma cadena, quien controla los datos controla la instrucción. La cura es mantenerlos separados, en cualquier lenguaje.
técnica· etapa: code
A06 Insecure Design
Una implementación perfecta de un mal diseño sigue siendo una vulnerabilidad. La seguridad hay que pedirla antes de la primera línea de código, como un requisito, y no encontrarla después como un bug.
concepto· etapa: design
A07 Authentication Failures
El login es la puerta de entrada. Los intentos ilimitados, las contraseñas reutilizadas, las sesiones que nunca expiran y los tokens que no se verifican de verdad dejan que un atacante entre como un usuario real.
técnica· etapa: code
A08 Software or Data Integrity Failures
Si el programa acepta actualizaciones, plugins, objetos serializados o la salida de un pipeline sin probar de dónde vienen, quien pueda alterarlos puede ejecutar código como tú.
técnica· etapa: ship
A09 Security Logging and Alerting Failures
No puedes responder a lo que no puedes ver. Los logs sin alertas son un archivo; las alertas sin buenos logs son ruido. Ambos deben existir, y ninguno puede ser inyectable ni estar lleno de secretos.
práctica· etapa: operate
A10 Mishandling of Exceptional Conditions
La seguridad a menudo depende de lo que pasa cuando algo sale mal. Si un error significa "permitir", un stack trace significa "aquí está mi código" o una operación a medias significa "estado corrupto", el camino de fallo es la vulnerabilidad.
técnica· etapa: operate