OWASP Top 10 2025: riesgos en empresas españolas

El OWASP Top 10 2025 sigue siendo la referencia más útil para aterrizar, en lenguaje de negocio, cuáles son las vulnerabilidades web que más daño pueden hacer a una empresa. Si tu organización opera con eCommerce, portales B2B, APIs o aplicaciones internas expuestas, estas diez categorías explican la mayoría de incidentes que vemos en España.

En este post lo llevamos a la práctica: qué significa cada riesgo, cómo se explota en entornos reales y qué medidas (técnicas y de proceso) reducen el impacto de forma medible.

Por qué el OWASP Top 10 2025 importa (especialmente en España)

Aunque OWASP publica su Top 10 de forma periódica, en 2026 el documento se usa como “lenguaje común” entre CTO/CISO, desarrollo y proveedores. En empresas españolas encaja especialmente bien por tres motivos:

• Regulación y auditoría: ENS (RD 311/2022), ISO 27001:2022, RGPD y el empuje de NIS2 están obligando a demostrar control sobre seguridad de aplicaciones y cadena de suministro.
• Superficie de ataque real: proliferación de APIs, integraciones con terceros, SSO, microservicios y despliegues cloud acelerados. Esto amplifica fallos de control de acceso, configuración e integridad.
• Cadencia de cambio: releases semanales/diarias. Sin pruebas continuas, aparecen regresiones de seguridad que no se detectan con auditorías puntuales.

En términos de amenaza, muchas intrusiones comienzan como MITRE ATT&CK T1190 (Exploit Public-Facing Application) y escalan combinando fallos de autenticación, exposición de secretos o permisos excesivos. El Top 10 es una forma práctica de priorizar dónde poner el foco primero.

OWASP Top 10 2025: las 10 categorías que más vemos en pentesting

Cuando hablamos de OWASP Top 10 2025 nos referimos a la clasificación que, en la práctica, sigue dominando los hallazgos en aplicaciones web y APIs en 2026. A continuación, desglosamos cada categoría con ejemplos típicos en empresas españolas y medidas de mitigación.

1) Broken Access Control (Control de acceso roto)

El fallo más frecuente y, a menudo, el más crítico: usuarios que pueden acceder a recursos que no les corresponden, o modificar estados del sistema sin autorización.

Ejemplos reales que vemos:

• Cambiar un accountId o orderId en una petición y acceder a datos de otro cliente (IDOR).
• Acciones de “admin” ocultas solo por el frontend (botón no visible) pero accesibles vía API.
• Falta de validación por objeto y por acción (permiso para “ver” no implica permiso para “editar”).

Impacto típico:

• Exposición de datos personales (RGPD).
• Fraude (modificación de precios, descuentos, estados de pedidos).
• Acceso a paneles internos, pivotaje y movimiento lateral.

Qué hacer:

• Autorización en el backend para cada operación (policy-based / RBAC/ABAC).
• Revisar controles con pruebas de abuso: cambio de IDs, enumeración, bypass de flujos.
• Telemetría de “denegaciones” para detectar enumeración.

Alineación útil: NIST SP 800-53 (AC), ISO 27001 controles de control de acceso, ENS medidas de protección de acceso y segregación.

2) Cryptographic Failures (Fallos criptográficos)

Ya no es solo “usar HTTPS”. En 2026, el fallo típico es gestionar mal secretos, cifrado y datos sensibles.

Ejemplos:

• Datos sensibles (DNI, IBAN, tokens) almacenados sin cifrar o con claves accesibles desde el repositorio.
• TLS con configuraciones débiles o sin HSTS en portales con login.
• Uso incorrecto de cifrado simétrico (IV fijo, modos inseguros) o hashing rápido para contraseñas.

Qué hacer:

• Contraseñas con Argon2id o bcrypt y políticas de rotación de credenciales comprometidas.
• Gestión de secretos con vault/servicios cloud, rotación y control de acceso.
• Clasificación de datos y cifrado por defecto en reposo y en tránsito.

Mapeo: NIST SP 800-63 (identidad), NIST 800-53 (SC), ENS cifrado y protección de la información.

3) Injection (Inyección)

La inyección no ha desaparecido; se ha diversificado: SQL/NoSQL, LDAP, OS command, template injection, GraphQL, y abusos de búsquedas.

Ejemplos:

• SQLi en filtros “avanzados” o endpoints legacy.
• NoSQLi en autenticación con JSON mal validado.
• Inyección de comandos en servicios que invocan herramientas del sistema para generar PDFs, procesar imágenes o ejecutar conversiones.

Qué hacer:

• Consultas parametrizadas y validación de entradas por esquema.
• Separar privilegios de la cuenta de base de datos (mínimo privilegio).
• WAF como capa adicional, pero nunca como sustituto del arreglo.

MITRE ATT&CK frecuente: T1059 (Command and Scripting Interpreter) cuando se encadena a RCE.

4) Insecure Design (Diseño inseguro)

Es la categoría más “incómoda” porque no se arregla con un parche puntual. Aparece cuando el sistema carece de controles por diseño: límites, validaciones de negocio, antifraude, “misuse cases”.

Ejemplos:

• Flujos de reset de contraseña que validan solo email sin verificación robusta.
• Lógica de cupones/descuentos sin reglas antiabuso (multiplicar saldo, reusar cupones).
• APIs sin límites de rate, permitiendo enumeración de usuarios o scraping.

Qué hacer:

• Threat modeling (OWASP ASVS, OWASP SAMM) y requisitos de seguridad por historia de usuario.
• Controles de negocio: límites, anti-automatización, reglas antifraude.
• Revisiones de arquitectura y pruebas de abuso en QA.

NIST SSDF (SP 800-218) encaja muy bien aquí: prácticas de diseño seguro y validación continua.

5) Security Misconfiguration (Configuración insegura)

Suele ser la puerta de entrada “silenciosa”: cabeceras, CORS, almacenamiento público, servicios expuestos, debugging habilitado.

Ejemplos:

• Buckets o blobs accesibles públicamente con documentos internos.
• CORS permisivo (*) en APIs con cookies/sesiones.
• Paneles de administración expuestos sin restricción por IP/VPN.
• Errores verbosos con trazas, versiones y rutas internas.

Qué hacer:

• Baselines de hardening y “config as code”.
• Revisión de exposición en cloud (CSPM) y escaneo de cabeceras.
• Entornos: separar y asegurar dev/staging; evitar datos reales en preproducción.

ENS e ISO 27001 aquí suelen exigir evidencias claras de configuración segura y gestión de cambios.

6) Vulnerable and Outdated Components (Componentes vulnerables y obsoletos)

En 2026, la velocidad del ecosistema open source hace que sea fácil quedarse atrás. El riesgo no es solo “un CVE”: es no saber qué tienes desplegado (inventario) y no poder parchear rápido.

Ejemplos:

• Dependencias transitorias con vulnerabilidades críticas.
• Frameworks sin soporte o librerías de autenticación abandonadas.
• Imágenes Docker con paquetes del sistema vulnerables.

Qué hacer:

• SBOM (Software Bill of Materials) y políticas de actualización.
• SCA en CI/CD y control de versiones con “allow/deny lists”.
• Gestión de excepciones con caducidad y compensación.

Esto conecta directamente con controles de cadena de suministro y con ataques tipo MITRE T1195 (Supply Chain Compromise) en escenarios más avanzados.

7) Identification and Authentication Failures (Fallos de identificación y autenticación)

Aquí entran debilidades de login, sesión y gestión de tokens. En empresas españolas es muy común al integrar SSO, proveedores de identidad y apps móviles.

Ejemplos:

• Falta de MFA en cuentas privilegiadas.
• Tokens JWT sin validación robusta (algoritmo, audiencia, expiración) o con secretos débiles.
• Gestión de sesión: cookies sin HttpOnly/Secure/SameSite, sesiones largas, ausencia de revocación.

Qué hacer:

• MFA para admins y accesos remotos, y evaluación por riesgo donde aplique.
• Rotación y revocación de tokens; tiempos de vida razonables.
• Protección contra credential stuffing (rate limit, detección, listas de contraseñas filtradas).

NIST 800-63 es referencia directa para niveles de autenticación y buenas prácticas.

8) Software and Data Integrity Failures (Integridad de software y datos)

Crítico en pipelines CI/CD y en integraciones. En 2026, vemos impacto real cuando:

• Se confía ciegamente en artefactos o actualizaciones.
• Se deserializa contenido no confiable.
• Se permiten webhooks o integraciones sin firma/verificación.

Ejemplos:

• Actualizaciones de plugins sin firma o sin validación de origen.
• Webhooks que aceptan eventos sin validar HMAC/firmas, permitiendo acciones internas.
• Deserialización insegura en servicios Java/.NET que derivan en ejecución de código.

Qué hacer:

• Firmado y verificación de artefactos, protección de pipelines, revisiones de permisos en CI.
• Validación criptográfica de webhooks e integridad de mensajes.
• Restricción y aislamiento de runners/agents de CI.

Alineación: NIST SSDF y controles de “secure build” + ENS/ISO en control de cambios.

9) Security Logging and Monitoring Failures (Fallos de logging y monitorización)

No tener visibilidad convierte incidentes menores en brechas prolongadas. Además, con RGPD y ENS, la trazabilidad es una exigencia práctica.

Ejemplos:

• No se registran eventos de autenticación, elevación de privilegios o accesos a datos sensibles.
• Logs sin correlación (sin request-id), sin retención o sin alertas.
• Falta de detección de patrones: enumeración, fuerza bruta, abuso de APIs.

Qué hacer:

• Logging “security-grade”: autenticación, autorización, cambios críticos, exportación de datos.
• Integración SIEM/SOAR y alertas por umbrales y comportamiento.
• Pruebas de detección durante pentesting (no solo “explotar”, también verificar si se detecta).

MITRE ATT&CK: sin detección, técnicas como T1110 (Brute Force) o T1078 (Valid Accounts) pasan desapercibidas.

10) Server-Side Request Forgery (SSRF)

SSRF sigue apareciendo en integraciones, parsers de URL, previsualizadores, importadores y funciones “convenientes” que descargan recursos.

Ejemplos:

• Un endpoint que recibe una URL para “importar” datos y permite acceder a metadatos cloud.
• Previsualización de enlaces sin validación, permitiendo escanear red interna.
• Lectura de file:// o gopher:// por parsers permisivos.

Qué hacer:

• Listas permitidas (allowlist) por dominio/host, no solo por regex.
• Bloqueo de rangos internos y metadatos, y egress control.
• Timeouts, límites de redirecciones y validación estricta de esquemas.

En cloud, SSRF puede ser el inicio de robo de credenciales temporales y posterior escalada.

OWASP Top 10 2025 y cómo priorizar: impacto real vs. esfuerzo

No todas las categorías tienen el mismo retorno inmediato. Para priorizar en un backlog de seguridad de aplicaciones, recomendamos combinar:

Riesgo técnico (probabilidad) + impacto negocio

• Probabilidad: ¿es un patrón repetible? ¿hay superficie expuesta? ¿existen controles compensatorios?
• Impacto: datos personales, transacciones, continuidad, reputación, sanciones.

En España, por experiencia, el “top” práctico suele empezar por:

1. Broken Access Control, 2) Security Misconfiguration, 3) Vulnerable and Outdated Components, 4) Authentication Failures, 5) Injection.

Evidencia y trazabilidad (ENS / ISO 27001)

Para auditorías y para gestionar proveedores, la pregunta no es “¿tenéis seguridad?”, sino “¿podéis demostrarlo?”. Aquí ayuda:

• Inventario de activos y dependencias (incluyendo SBOM).
• Procedimientos de hardening y gestión de cambios.
• Evidencias de pruebas: pentests, DAST/escaneos continuos, revisión de hallazgos y remediación.

Cómo lo abordamos en Secra: de pentesting a mejora continua

Un pentest aislado encuentra vulnerabilidades; un programa maduro reduce su reaparición. En Secra solemos estructurarlo así:

Auditoría técnica (web, móvil y API) orientada a riesgo

Cuando el objetivo es descubrir fallos explotables con impacto, una auditoría ofensiva aporta profundidad: lógica de negocio, encadenamiento de vulnerabilidades, bypass de controles y validación del impacto real.

Si necesitas una evaluación completa de aplicaciones y APIs, puedes ver nuestro enfoque en auditoría web y móvil, incluyendo priorización y recomendaciones accionables para el equipo de desarrollo.

DAST y pruebas continuas en CI/CD

Para evitar regresiones (por ejemplo, reintroducir CORS inseguro o perder validaciones), el DAST ayuda a detectar cambios peligrosos de forma recurrente, especialmente en entornos de staging/preproducción.

En programas DevSecOps, combinamos pruebas automatizadas y revisiones manuales; aquí encaja nuestro servicio de DAST en SSDLC/DevSecOps, ideal para equipos con despliegues frecuentes y múltiples aplicaciones.

Alineación con estándares (y con lo que pide el auditor)

• OWASP ASVS: convierte “Top 10” en requisitos verificables por nivel (L1-L3).
• NIST SSDF (SP 800-218): prácticas de desarrollo seguro y supply chain.
• ENS / ISO 27001: gobernanza, control de cambios, gestión de vulnerabilidades, evidencias.

La combinación permite: detectar, corregir, y demostrar control en el tiempo.

Señales de alerta: checklist rápido para CTO/CISO

Si respondes “no” a varias de estas preguntas, es probable que el OWASP Top 10 2025 esté afectando ya a tus aplicaciones aunque no lo veas:

Control de acceso y autenticación

• ¿La autorización se valida siempre en backend, por objeto y por acción?
• ¿MFA está activado para cuentas privilegiadas y accesos críticos?
• ¿Existe revocación de sesiones/tokens y tiempos de vida razonables?

Configuración y despliegue

• ¿Tenéis baselines de hardening (cabeceras, CORS, TLS) y se validan automáticamente?
• ¿Hay entornos segregados y sin datos reales en preproducción?
• ¿Conocéis qué servicios están expuestos a Internet hoy (no “en teoría”)?

Dependencias e integridad

• ¿Disponéis de SBOM y SCA en CI/CD con políticas de bloqueo?
• ¿Los artefactos de build están firmados/verificados y el pipeline está protegido?
• ¿Los webhooks e integraciones validan firma y origen?

Detección

• ¿Se registran eventos de seguridad y se alertan patrones de abuso (fuerza bruta, enumeración, scraping)?
• ¿Podéis responder “qué pasó” ante un incidente sin improvisar?

Este checklist no sustituye una auditoría, pero ayuda a decidir por dónde empezar y dónde hay mayor exposición.

Próximos pasos: reduce el riesgo del OWASP Top 10 2025 con Secra

Si quieres saber cómo afecta el OWASP Top 10 2025 a tus aplicaciones (y qué arreglos dan más retorno en menos tiempo), podemos ayudarte con pentesting, pruebas continuas y planes de remediación alineados con ENS/ISO/NIST. Escríbenos para una primera toma de requisitos y propuesta: contactar con nuestro equipo.