OWASP Top 10 2025 — Complete Guide for SMEs

¿Qué es el OWASP Top 10?

El Open Worldwide Application Security Project (OWASP) es una fundación sin fines de lucro dedicada a mejorar la seguridad del software. Su publicación insignia, el OWASP Top 10, cataloga los diez riesgos de seguridad más críticos que enfrentan las aplicaciones web. Publicado por primera vez en 2003, se ha convertido en el estándar de facto para la concienciación sobre la seguridad de aplicaciones web.

La edición 2025 se basa en datos de más de 500.000 aplicaciones y contribuciones de cientos de expertos en seguridad. Para las PYME, estos riesgos no son teóricos — representan los vectores de ataque exactos utilizados en la mayoría de las brechas reales. Según el informe de investigaciones de brechas de datos de Verizon 2024, el 83 % de las brechas involucraron actores externos que explotaron vulnerabilidades de aplicaciones web directamente mapeables al OWASP Top 10.

A01: Control de acceso deficiente

Qué es:El control de acceso aplica políticas para que los usuarios no puedan actuar fuera de sus permisos previstos. Cuando estos controles fallan, los atacantes pueden ver datos de otros usuarios, modificar registros o escalar privilegios a nivel de administrador.

Impacto real:En 2023, un importante operador australiano de telecomunicaciones expuso 10 millones de registros de clientes debido a un endpoint de API defectuoso que no verificaba la identidad del solicitante. El atacante simplemente iteró a través de los IDs de clientes en la URL. El coste medio de una brecha por control de acceso deficiente es de 4,35 millones de dólares (IBM Cost of a Data Breach Report 2024).

Cómo verificar:Pruebe si los usuarios autenticados pueden acceder a recursos de otros usuarios modificando parámetros de URL, cuerpos de solicitudes API o cookies. Verifique que las funciones administrativas son inaccesibles para usuarios regulares.

Cómo corregir:Implemente verificaciones de control de acceso del lado del servidor en cada solicitud. Utilice políticas de denegación por defecto. Aplique la propiedad de registros a nivel de consulta de base de datos (por ejemplo, filtre siempre por ID de usuario autenticado). Desactive el listado de directorios y asegúrese de que los archivos de metadatos (.git, .env) no sean accesibles.

A02: Fallos criptográficos

Qué es:Anteriormente denominada "Exposición de datos sensibles", esta categoría cubre los fallos en la criptografía que llevan a la exposición de datos sensibles. Esto incluye la transmisión de datos en texto plano, el uso de algoritmos obsoletos (MD5, SHA1 para contraseñas), la generación débil de claves y la validación incorrecta de certificados.

Impacto real:La brecha de MOVEit en 2024 afectó a más de 2.600 organizaciones debido al cifrado inadecuado de datos en reposo. Las organizaciones sanitarias son particularmente vulnerables: las violaciones HIPAA por fallos criptográficos han resultado en multas superiores a 10 millones de dólares.

Cómo verificar:Verifique que todos los datos en tránsito utilizan TLS 1.2 o superior. Compruebe que las contraseñas están hasheadas con bcrypt, scrypt o Argon2. Asegúrese de que no se almacenan datos sensibles en texto plano en bases de datos o registros. Busque certificados caducados o autofirmados.

Cómo corregir:Aplique HTTPS en todas partes con cabeceras HSTS (incluidos subdominios). Utilice algoritmos de hashing modernos para contraseñas. Cifre los datos sensibles en reposo con AES-256. Rote periódicamente las claves de cifrado. Nunca registre datos sensibles como contraseñas, tokens o números de tarjeta de crédito.

A03: Inyección

Qué es:Los fallos de inyección ocurren cuando datos no confiables se envían a un intérprete como parte de un comando o consulta. Inyección SQL, inyección NoSQL, inyección de comandos del sistema operativo e inyección LDAP son las variantes más comunes. Cross-site scripting (XSS) también se clasifica aquí en la edición 2025.

Impacto real:La inyección SQL sigue siendo la clase de vulnerabilidad más explotada. La brecha de Fortra GoAnywhere en 2024 utilizó una inyección por deserialización para comprometer más de 130 organizaciones. Los ataques XSS representaron el 27 % de todas las vulnerabilidades de aplicaciones web reportadas en 2024 (HackerOne Annual Report).

Cómo verificar:Pruebe todas las entradas de usuario (formularios, parámetros de URL, cabeceras, cookies) con payloads de inyección. Utilice escáneres automatizados para detectar XSS reflejado y almacenado. Verifique que los endpoints API rechacen tipos de datos inesperados.

Cómo corregir:Utilice exclusivamente consultas parametrizadas o sentencias preparadas — nunca concatene entradas de usuario en las consultas. Valide y sanee todas las entradas del lado del servidor con esquemas estrictos (Zod, Joi). Implemente cabeceras Content Security Policy (CSP) para mitigar XSS. Utilice ORMs con parametrización integrada (Prisma, Drizzle).

A04: Diseño inseguro

Qué es:Una nueva categoría introducida en 2021. El diseño inseguro se refiere a fallos en la arquitectura y diseño de una aplicación que no pueden corregirse solo con la implementación. Incluye la ausencia de modelado de amenazas, lógica de negocio insegura y la falta de defensa en profundidad.

Impacto real:Una fintech europea perdió 2,3 millones de euros cuando los atacantes explotaron un fallo de lógica de negocio en su flujo de pagos — la aplicación permitía importes de transacción negativos, permitiendo a los atacantes transferir dinero a sí mismos. Ninguna validación de entradas habría detectado esto sin un modelado adecuado de amenazas.

Cómo verificar:Revise la arquitectura de la aplicación para defensa en profundidad. Verifique que los requisitos de seguridad se definieron antes del desarrollo. Compruebe la limitación de tasa en funciones críticas (inicio de sesión, restablecimiento de contraseña, pago). Evalúe si se realizó un modelado de amenazas.

Cómo corregir:Integre la seguridad desde la fase de diseño. Realice modelado de amenazas utilizando metodologías STRIDE o PASTA. Defina casos de abuso junto con los casos de uso. Implemente limitación de tasa, circuit breakers y límites de transacción. Separe tenants y niveles de confianza a nivel arquitectónico.

A05: Mala configuración de seguridad

Qué es:El problema más frecuentemente observado en la práctica. Incluye credenciales por defecto, almacenamiento cloud abierto, funciones innecesarias habilitadas, configuraciones incompletas, CORS excesivamente permisivo, cabeceras de seguridad faltantes y mensajes de error detallados que exponen trazas de pila.

Impacto real:En 2024, miles de organizaciones fueron comprometidas a través de buckets S3 mal configurados, APIs Docker expuestas y credenciales por defecto de dashboards Kubernetes. El informe de seguridad 2024 de Microsoft reveló que el 80 % de las brechas cloud provenían de malas configuraciones, no de exploits zero-day.

Cómo verificar:Busque cabeceras de seguridad faltantes (X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, Content-Security-Policy, Permissions-Policy). Pruebe con credenciales por defecto. Verifique que las páginas de error no divulgan trazas de pila ni rutas internas. Compruebe que los métodos HTTP innecesarios (TRACE, OPTIONS) están desactivados.

Cómo corregir:Implemente una lista de verificación de hardening para cada despliegue. Establezca cabeceras de seguridad completas. Desactive el listado de directorios, cuentas por defecto y modos de depuración en producción. Utilice infraestructura como código para imponer configuraciones consistentes. Automatice las auditorías de configuración con herramientas como WarDek.

A06: Componentes vulnerables y obsoletos

Qué es:Aplicaciones que utilizan bibliotecas, frameworks u otros módulos de software con vulnerabilidades conocidas. Esto incluye sistemas operativos sin parchear, servidores web, sistemas de gestión de bases de datos, APIs y todos los componentes incluidas bibliotecas, frameworks y otros módulos de software.

Impacto real:La vulnerabilidad Log4Shell (CVE-2021-44228) en Apache Log4j afectó a millones de aplicaciones en todo el mundo. En 2024, las vulnerabilidades críticas en XZ Utils (CVE-2024-3094) demostraron cómo los ataques a la cadena de suministro a través de dependencias open-source pueden comprometer ecosistemas enteros. Synopsys informó que el 84 % de las bases de código contienen al menos una vulnerabilidad conocida en componentes open-source.

Cómo verificar:Mantenga un inventario de componentes de software (SBOM). Ejecute auditorías de dependencias regularmente (npm audit, pip-audit, Trivy). Monitorice bases de datos de vulnerabilidades (NVD, GitHub Advisory Database) para los componentes en uso. Verifique que no se desplieguen componentes en fin de vida.

Cómo corregir:Automatice las actualizaciones de dependencias con herramientas como Dependabot o Renovate. Elimine las dependencias no utilizadas. Suscríbase a avisos de seguridad para componentes críticos. Fije versiones exactas de dependencias en producción. Pruebe las actualizaciones en staging antes del despliegue.

A07: Fallos de identificación y autenticación

Qué es:Debilidades en los mecanismos de autenticación que permiten a los atacantes comprometer contraseñas, tokens de sesión o explotar fallos de implementación para suplantar la identidad de otros usuarios. Incluye credential stuffing, ataques de fuerza bruta, políticas de contraseñas débiles y gestión incorrecta de sesiones.

Impacto real:Los ataques de credential stuffing cuestan a las empresas unos 6 mil millones de dólares anuales (Akamai 2024 State of the Internet Report). La brecha de 23andMe en 2023 comprometió 6,9 millones de perfiles de usuario mediante credential stuffing con credenciales filtradas de otras brechas.

Cómo verificar:Pruebe políticas de contraseñas débiles (longitud mínima, complejidad). Verifique el bloqueo de cuenta tras intentos fallidos. Compruebe que los tokens de sesión se invalidan al cerrar sesión. Pruebe la fijación de sesión y el almacenamiento inseguro de sesiones. Verifique que la autenticación multifactor está disponible.

Cómo corregir:Implemente la autenticación multifactor (MFA). Utilice bibliotecas de autenticación reconocidas (Better Auth, NextAuth, Auth0). Aplique políticas de contraseñas robustas (mínimo 12 caracteres). Limite la tasa de intentos de inicio de sesión. Invalide las sesiones al cambiar la contraseña. Almacene los tokens de sesión en cookies HttpOnly y Secure.

A08: Fallos de integridad de software y datos

Qué es:Código e infraestructura que no protegen contra violaciones de integridad. Incluye el uso de actualizaciones de software sin verificación, pipelines CI/CD inseguros y la deserialización de datos no confiables. Los ataques a la cadena de suministro caen plenamente en esta categoría.

Impacto real:La brecha de SolarWinds (2020) y el compromiso del bash uploader de Codecov (2021) son ejemplos de libro de texto de ataques a la cadena de suministro. En 2024, la puerta trasera de XZ Utils (CVE-2024-3094) demostró que incluso las utilidades esenciales de Linux pueden comprometerse mediante ingeniería social de los mantenedores. Estos ataques afectan simultáneamente a miles de organizaciones aguas abajo.

Cómo verificar:Verifique que las actualizaciones de software se distribuyen a través de canales firmados. Compruebe los pipelines CI/CD en busca de scripts no firmados o dependencias obtenidas sin verificación de integridad. Audite la integridad de subrecursos (SRI) para scripts y hojas de estilo cargados externamente.

Cómo corregir:Verifique las firmas digitales en todas las actualizaciones de software. Implemente hashes de Subresource Integrity (SRI) para recursos alojados en CDN. Asegure los pipelines CI/CD con commits firmados y ramas protegidas. Utilice archivos de bloqueo y verifique las sumas de verificación de las dependencias. Evite deserializar datos no confiables.

A09: Fallos de registro y monitorización de seguridad

Qué es:Registro, detección, monitorización y respuesta activa insuficientes. Sin un registro adecuado, las brechas no pueden detectarse, y sin monitorización, los eventos registrados nunca se revisan. El tiempo medio para identificar una brecha es de 204 días (IBM 2024), en gran parte debido a una monitorización inadecuada.

Impacto real:La brecha de Equifax pasó desapercibida durante 78 días a pesar de que la intrusión era visible en los registros que nadie revisó. Las organizaciones con una monitorización de seguridad adecuada detectan las brechas 68 días más rápido en promedio, reduciendo el coste en 1,76 millones de dólares (IBM 2024).

Cómo verificar:Verifique que los intentos de inicio de sesión (exitosos y fallidos) se registran. Compruebe que los fallos de control de acceso generan alertas. Asegúrese de que los registros se almacenan de forma segura y no pueden ser manipulados. Verifique que los datos de registro se conservan durante un período suficiente (mínimo 90 días, preferiblemente 12 meses).

Cómo corregir:Registre todos los eventos de autenticación, los fallos de control de acceso y los fallos de validación de entradas del lado del servidor. Utilice registro estructurado (formato JSON) para análisis legible por máquina. Implemente alertas para patrones sospechosos (múltiples fallos de inicio de sesión, intentos de escalada de privilegios). Almacene los registros de forma centralizada con protección contra manipulación. Nunca registre datos sensibles (contraseñas, tokens, datos personales).

A10: Falsificación de solicitud del lado del servidor (SSRF)

Qué es:Los fallos SSRF ocurren cuando una aplicación web recupera un recurso remoto sin validar la URL proporcionada por el usuario. Los atacantes pueden forzar al servidor a realizar solicitudes a servicios internos, endpoints de metadatos cloud o sistemas externos, a menudo eludiendo firewalls y controles de acceso.

Impacto real:La brecha de Capital One (2019) explotó una vulnerabilidad SSRF para acceder a los metadatos de AWS y robar 100 millones de registros de clientes. En entornos cloud, SSRF es particularmente peligroso porque el endpoint de metadatos cloud (169.254.169.254) proporciona acceso a credenciales IAM, que pueden usarse para acceder a cualquier recurso cloud que la instancia tenga permiso de alcanzar.

Cómo verificar:Pruebe todos los campos de entrada de URL para SSRF enviando direcciones internas (127.0.0.1, 169.254.169.254, nombres de host internos). Compruebe si la aplicación sigue redirecciones que resuelven a direcciones internas. Verifique que la protección contra DNS rebinding está implementada.

Cómo corregir:Valide y sanee todas las URLs del lado del servidor. Implemente listas de autorización para dominios y protocolos permitidos. Bloquee solicitudes a rangos de IP privadas (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) y endpoints de metadatos cloud. Desactive las redirecciones HTTP o valide los destinos de redirección. Utilice segmentación de red para limitar el tráfico de salida del servidor.

Por qué las PYME son especialmente vulnerables

Las pequeñas y medianas empresas enfrentan un desafío de seguridad desproporcionado. Aunque poseen datos valiosos de clientes y procesan transacciones financieras, generalmente carecen de equipos de seguridad dedicados. Según el informe Hiscox Cyber Readiness 2024:

• El 43 % de los ciberataques se dirigen a pequeñas empresas
• El 60 % de las PYME que sufren una brecha cierran en 6 meses
• El coste medio de una brecha para una PYME es de 108.000 $
• Solo el 14 % de las PYME tienen un plan formal de respuesta a incidentes

La buena noticia es que abordar el OWASP Top 10 elimina la gran mayoría de la superficie de ataque. La mayoría de las vulnerabilidades en estas categorías pueden detectarse automáticamente y corregirse con cambios de configuración o actualizaciones menores del código — no se necesita un presupuesto de seguridad de seis cifras.

Cómo comenzar con el cumplimiento OWASP

El enfoque más eficaz para las PYME es comenzar con escaneos automatizados para identificar los problemas más críticos, y luego priorizar las correcciones según el riesgo. A continuación, un enfoque práctico en tres pasos:

1. Escanear: Ejecute un escaneo de seguridad automatizado para identificar cabeceras faltantes, problemas TLS, componentes vulnerables y malas configuraciones comunes. Esto cubre A02, A05, A06 y parcialmente A03 y A10.
2. Corregir primero los problemas críticos: Aborde las cabeceras de seguridad, active HTTPS con HSTS, actualice las dependencias vulnerables y revise la configuración de autenticación. Estos son típicamente cambios de configuración que toman horas, no semanas.
3. Integrar la seguridad en su proceso:Integre el escaneo automatizado en su pipeline CI/CD, programe actualizaciones regulares de dependencias y realice revisiones de seguridad trimestrales. La prevención siempre es más económica que la remediación.