OWASP Top 10: qué exigir en la seguridad de tu software a medida
El OWASP Top 10 reúne las categorías de riesgo de seguridad más críticas de las aplicaciones web. Los diez riesgos convertidos en preguntas para tu proveedor, el control de acceso en detalle, qué exigir por escrito y qué añade la protección de datos.
Cuando encargas un software, la seguridad no se ve en la demostración: se ve el día que alguien entra donde no debía. El OWASP Top 10 es una forma práctica de hablar de ella con tu proveedor sin ser informático. OWASP lo presenta como un documento estándar de concienciación para desarrolladores que representa un amplio consenso sobre los riesgos de seguridad más críticos de las aplicaciones web. Aquí tienes la lista traducida a preguntas que puedes hacer antes de firmar.
Qué es el OWASP Top 10
OWASP es una fundación sin ánimo de lucro que trabaja para mejorar la seguridad del software mediante proyectos de código abierto, comunidades y formación. Su Top 10 es una lista de categorías de riesgo, no una certificación: no dice que un programa sea seguro, sino dónde suelen estar los fallos.
Según la página del proyecto, la versión vigente es la de 2025; las anteriores son la de 2021 y la de 2017. Si un proveedor te habla de la lista, pregúntale con cuál trabaja.
Los diez riesgos, en preguntas para tu proveedor
| Riesgo (lista vigente) | Qué significa | Qué preguntar |
|---|---|---|
| A01 · Control de acceso roto | Alguien ve o hace lo que no le corresponde | ¿Cómo se comprueba que un usuario no ve datos de otro? |
| A02 · Configuración de seguridad incorrecta | Servidores o servicios mal configurados | ¿Quién revisa la configuración y cada cuánto? |
| A03 · Fallos en la cadena de suministro del software | Librerías y componentes de terceros con problemas | ¿Cómo se vigilan y se actualizan las dependencias? |
| A04 · Fallos criptográficos | Datos sensibles mal protegidos | ¿Qué se cifra y cómo se guardan las contraseñas? |
| A05 · Inyección | Datos que el programa ejecuta como órdenes | ¿Se usan consultas parametrizadas o interfaces seguras que separan datos y órdenes, además de validar las entradas? |
| A06 · Diseño inseguro | La seguridad no se pensó desde el principio | ¿Se analizaron los riesgos al diseñar? |
| A07 · Fallos de autenticación | Accesos fáciles de suplantar | ¿Hay doble factor y bloqueo tras intentos fallidos? |
| A08 · Fallos de integridad del software o de los datos | Actualizaciones o datos alterados sin que nadie lo note | ¿Cómo se comprueba lo que se instala y se actualiza? |
| A09 · Fallos de registro y alertas | Nadie sabe qué pasó ni se entera a tiempo | ¿Queda registrado quién hizo qué? ¿Quién recibe las alertas? |
| A10 · Mala gestión de condiciones excepcionales | El programa se comporta mal cuando algo falla | ¿Qué hace el sistema ante un error inesperado? |
Los nombres son nuestra traducción de las categorías oficiales en inglés; el detalle de cada una está en la documentación de OWASP.
El primero de la lista: el control de acceso
OWASP explica que el control de acceso hace cumplir políticas para que los usuarios no puedan actuar fuera de los permisos previstos, y que sus fallos suelen llevar a revelar, modificar o destruir datos sin autorización, o a que alguien haga una operación del negocio fuera de sus límites.
Entre sus recomendaciones, dos que conviene entender aunque no programes: el control de acceso solo es eficaz si se implementa en código de servidor de confianza, donde el atacante no puede modificarlo; y, salvo los recursos públicos, hay que denegar por defecto.
En un programa con varios clientes (un SaaS), el control de acceso es lo que separa los datos de una empresa de los de otra. Lo contamos en SaaS multi tenant: cómo se aíslan los datos.
Qué exigir por escrito
- Pruebas automáticas en cada entrega, incluidas las que intentan saltarse los permisos.
- Roles y permisos mínimos: cada persona ve y hace solo lo que necesita.
- Registro de accesos y cambios, y alguien que reciba las alertas.
- Actualización de dependencias: quién las vigila y en qué plazo se corrigen los fallos conocidos.
- Entornos separados para probar sin tocar datos reales.
- Copias de seguridad probadas y un plan para restaurar.
- Aviso de incidentes: quién avisa, a quién y en cuánto tiempo.
Buena parte de esto va en el contrato de mantenimiento; lo detallamos en qué incluir en un contrato de mantenimiento de software.
Lo que añade la normativa de protección de datos
Si el programa trata datos personales, la seguridad deja de ser solo una buena práctica. El artículo 25 del RGPD pide al responsable del tratamiento (tu empresa) aplicar, ya al decidir los medios del tratamiento, medidas técnicas y organizativas apropiadas, como la seudonimización, concebidas para aplicar de forma efectiva los principios de protección de datos. Y el artículo 32 pide al responsable y al encargado (el proveedor que trate datos por tu cuenta) medidas para garantizar un nivel de seguridad adecuado al riesgo, que pueden incluir la seudonimización y el cifrado de datos personales.
Traducido al encargo: la seguridad se diseña desde el principio y se documenta, no se añade al final.
Cómo lo hacemos en el software que construimos
En nuestra base técnica multi-tenant, los datos de cada cliente están aislados en la propia base de datos, con pruebas que intentan leer datos ajenos y deben fallar. La base técnica incluye roles y permisos, trazabilidad, pruebas automáticas y copias y restauración.
Antes de publicar un cambio pasan más de mil comprobaciones automáticas (una batería de 2.914 pruebas), y comprobamos que el programa arranca de verdad antes de sustituir la versión en marcha, porque que la versión vieja responda no prueba que la nueva funcione. Si quieres ver cómo trabajamos un proyecto de principio a fin, está en desarrollo de software a medida.
Fuentes consultadas
Comprobadas el 27 de septiembre de 2026. Enlazamos la fuente original para que puedas consultar el texto vigente.
- OWASP Top 10 (página del proyecto). OWASP Foundation.
- OWASP Top 10:2025 (lista). OWASP Foundation.
- A01:2025 Broken Access Control. OWASP Foundation.
- Reglamento (UE) 2016/679 (RGPD): artículos 25 y 32. DOUE (vía BOE).
- A05:2025 Injection. OWASP Foundation.
Preguntas frecuentes
¿Qué es OWASP?
Una fundación sin ánimo de lucro que trabaja para mejorar la seguridad del software con proyectos de código abierto, comunidades y formación. Su Top 10 es un documento de concienciación sobre los riesgos de seguridad más críticos de las aplicaciones web.
¿Cuál es la versión vigente del OWASP Top 10?
Según la página del proyecto, la versión vigente es la de 2025; las anteriores son la de 2021 y la de 2017.
¿Cumplir el OWASP Top 10 hace seguro un software?
No por sí solo: es una lista de concienciación sobre categorías de riesgo, no una certificación. Sirve para hablar de seguridad con tu proveedor y comprobar que los riesgos principales se han tenido en cuenta.
¿Qué pedir en el contrato sobre seguridad?
Quién corrige las vulnerabilidades y en qué plazo, cómo se actualizan las dependencias, qué se registra, cómo se hacen y se prueban las copias y cómo se avisa de un incidente.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.