Referencias y fuentes

Fuentes de OWASP

De dónde procede el conocimiento de las especializaciones OWASP integradas, relacionado con sus páginas canónicas de ataques y Cheat Sheets de OWASP.

Este documento relaciona cada ataque (www-community) y cada Cheat Sheet (CheatSheetSeries) de OWASP con una categoría de seguridad, cada uno enlazado a su página pública canónica. Dentro de una categoría, los elementos equivalentes comparten una única línea de la lista: los ataques y las cheat sheets que abordan el mismo riesgo aparecen juntos, separados por comas. Los elementos sin un equivalente directo ocupan su propia línea.

  • El mérito es de OWASP. Los ataques están en https://owasp.org/www-community/attacks/<attack> y las cheat sheets en https://cheatsheetseries.owasp.org/cheatsheets/<cheat>.html.

1. Inyección (genérica)​


2. Inyección SQL y en bases de datos​


3. Inyección de comandos del sistema operativo​


4. Inyección LDAP, XPath y XML​


5. Cross-Site Scripting (XSS)​


6. Cross-Site Request Forgery (CSRF) y clickjacking​


7. Redirecciones y reenvíos​


8. Control de acceso y autorización​


9. Autenticación y credenciales​


10. Gestión de sesiones​


11. Federación de identidades (OAuth, SAML y JWT)​


12. Criptografía y seguridad del transporte​


13. Server-Side Request Forgery (SSRF)​


14. Recorrido de directorios y manejo de archivos​


15. Abuso del protocolo HTTP (cabeceras, caché y splitting)​


16. Codificación y suplantación de contenido​


17. Inyección en CSV y hojas de cálculo​


18. CORS (Cross-Origin Resource Sharing)​


19. Denegación de servicio​


20. Seguridad de la memoria y código nativo​


21. Código móvil y ejecución de código no fiable​


22. Deserialización​


23. Malware y amenazas del lado del cliente​


24. Registro de eventos, repudio y gestión de errores​


25. Lógica de negocio y abuso de funcionalidades​

La lógica de negocio y el abuso de funcionalidades no tienen una única superficie en el código que pueda defender una especialización por superficie: la defensa es un diseño propio de cada aplicación, el mismo razonamiento que guía el modelado de amenazas del proyecto. Se ha movido a "Fuera del alcance".


26. Seguridad de IA, LLM y agentes​


27. Contaminación de prototipos y cross-site leaks​


28. Frameworks y plataformas de lenguaje​


29. Front-end web y navegador​


30. API y servicios​


31. Nube, contenedores e infraestructura​

La configuración de contenedores y cargas de trabajo es configuración como código que el desarrollador entrega con la aplicación (Dockerfile, Compose, el securityContext del Pod), una superficie real que harden corrige y verify demuestra, así que está dentro del alcance. La administración del clúster (RBAC, etcd, API server, admission, segmentación de red) es terreno del operador y queda fuera del alcance.


32. Cadena de suministro y CI/CD​


33. Secretos y configuración​

La gestión de secretos es operativa: almacenes de secretos, CI/CD, configuración en la nube, rotación. La única faceta a nivel de código (un secreto escrito directamente en el código fuente) es un análisis determinista, no una especialización de riesgo. Se ha movido a "Fuera del alcance".


34. Procesos, diseño y gobernanza​

La protección de la privacidad del usuario es una cuestión de políticas y de diseño (minimización de datos, transparencia, conservación), no una superficie en el código que defienda una especialización. Se ha movido a "Fuera del alcance".


35. Pagos y cumplimiento normativo​


36. Sistemas embebidos, IoT y ámbitos especializados​

La seguridad de automoción y la de drones son ámbitos de sistemas embebidos (bus CAN, firmware OTA, integridad de sensores y radio, acceso físico), no el código fuente de aplicaciones web o de API que audita Lagune. Se ha movido a "Fuera del alcance".


Fuera del alcance (sin superficie en el código)​

Estos elementos no son terreno de especializaciones y no llevan casilla: son gobernanza, procesos, bastionado operativo o uso de frameworks, sin una única superficie en el código que pueda defender una especialización por superficie. Su valor para la seguridad es real, pero reside en los procesos y la arquitectura (o, en el caso de un framework, en la skill de su propio lenguaje), no en una defensa que incluya este catálogo. Se enumeran como referencia, no como trabajo pendiente.