Vulnerabilidades web más comunes: el OWASP Top 10 para pymes

Las vulnerabilidades web más comunes son, según la lista de referencia del sector, el OWASP Top 10:2025: fallos de control de acceso, configuraciones de seguridad incorrectas, componentes de terceros desactualizados o comprometidos, cifrado deficiente, inyección de código, diseño inseguro, fallos de autenticación, fallos de integridad, falta de registros y alertas, y mala gestión de errores. En una pyme, la mayoría de los incidentes empiezan por algo más sencillo: un gestor, un plugin o un lenguaje sin actualizar, o una contraseña débil.

Esta guía explica cada riesgo sin tecnicismos, qué puedes hacer para reducirlo y qué parte se puede comprobar desde fuera con un análisis automático y cuál necesita una auditoría autorizada.

Qué es el OWASP Top 10

OWASP (Open Worldwide Application Security Project) es una fundación sin ánimo de lucro que publica guías y herramientas abiertas sobre seguridad de aplicaciones. Su Top 10 es, en sus propias palabras, un documento de concienciación que recoge un amplio consenso sobre los riesgos de seguridad más críticos de las aplicaciones web.

La edición vigente es la 2025, que sustituye a la de 2021. Se elabora con datos de pruebas reales aportados por empresas de seguridad y con una encuesta a profesionales del sector. No es una norma ni una certificación: es una lista de prioridades para saber por dónde empezar.

Las 10 vulnerabilidades del OWASP Top 10:2025, explicadas

A01. Fallos de control de acceso

Ocurren cuando alguien puede ver o hacer algo para lo que no tiene permiso: ver el pedido de otra persona cambiando un número en la dirección, entrar en una zona de administración sin iniciar sesión o descargar facturas ajenas. OWASP indica que se encontró alguna forma de este fallo en todas las aplicaciones analizadas para la edición 2025.

Qué hacer: comprobar permisos en cada página y cada acción, no solo ocultar botones; dar a cada cuenta solo los permisos que necesita.

A02. Configuración de seguridad incorrecta

Valores por defecto sin cambiar, mensajes de error que muestran detalles internos, listados de carpetas abiertos, cabeceras de seguridad que faltan o un modo de depuración activado en la web publicada.

Qué hacer: revisar la configuración del servidor y del gestor tras cada instalación o cambio; desactivar lo que no se usa. El proyecto OWASP Secure Headers describe las cabeceras recomendadas.

A03. Fallos en la cadena de suministro de software

Tu web depende de piezas de terceros: el gestor de contenidos, plugins, temas, librerías y el propio lenguaje del servidor. Si una de ellas tiene un fallo conocido, está abandonada o ha sido manipulada, tu web hereda el problema. Esta categoría amplía la antigua «componentes vulnerables y desactualizados» y, según OWASP, fue la que más profesionales situaron en primer lugar en su encuesta.

Qué hacer: mantener un inventario de lo que usa la web, actualizar con regularidad, eliminar plugins y temas que no se usen y elegir componentes con mantenimiento activo. En nuestra guía sobre la versión de PHP para WordPress verás un ejemplo reciente.

A04. Fallos criptográficos

Datos sensibles que viajan o se guardan sin cifrar, o con un cifrado débil: una web sin HTTPS, contraseñas guardadas de forma insegura o certificados mal configurados.

Qué hacer: HTTPS en toda la web, con certificado válido y renovación automática. Lo explicamos en certificado SSL caducado o no válido.

A05. Inyección

Sucede cuando lo que alguien escribe en un formulario o en la dirección se trata como una orden y no como un simple dato. Incluye la inyección en bases de datos y la inyección de scripts en el navegador (conocida como XSS).

Qué hacer: que el código valide y trate de forma segura todo lo que llega de fuera. En gestores como WordPress, la mayor parte de este riesgo viene de plugins y temas, así que mantenerlos al día es la primera defensa. Una política de seguridad de contenidos (CSP) bien configurada ayuda a limitar los daños.

A06. Diseño inseguro

Fallos que no se deben a un error de programación, sino a cómo se pensó el proceso: un formulario de recuperación de contraseña que permite probar sin límite o una tienda que deja aplicar un cupón tantas veces como se quiera.

Qué hacer: pensar en el mal uso desde el principio y revisar los procesos críticos (pago, registro, recuperación de acceso) antes de publicarlos.

A07. Fallos de autenticación

Contraseñas débiles o repetidas, inicios de sesión sin límite de intentos, sesiones que no caducan o ausencia de verificación en dos pasos en las cuentas de administración.

Qué hacer: contraseñas únicas generadas con un gestor, verificación en dos pasos para quien administra y límite de intentos en el acceso.

A08. Fallos de integridad del software o de los datos

Confiar en código o datos sin comprobar que no se han alterado: actualizaciones descargadas de fuentes no oficiales, plugins «gratuitos» de versiones de pago o scripts cargados desde servidores ajenos sin control.

Qué hacer: instalar solo desde fuentes oficiales y revisar qué scripts externos carga la web.

A09. Fallos de registro y alertas de seguridad

Si nadie registra los accesos ni recibe avisos, un ataque puede pasar inadvertido durante meses. Muchas pymes descubren el problema cuando Google marca la web o la clientela avisa.

Qué hacer: activar los registros del servidor y del gestor, y decidir quién recibe las alertas. Si ya ha ocurrido, en WordPress hackeado: qué hacer tienes los pasos.

A10. Gestión incorrecta de condiciones excepcionales

Es la categoría nueva de 2025: qué hace la aplicación cuando algo sale mal (un error, una respuesta inesperada, un recurso agotado). Si falla «abierta», puede dejar pasar lo que debería bloquear o mostrar información interna.

Qué hacer: que los errores muestren mensajes genéricos a quien visita la web y que, ante la duda, la aplicación deniegue en lugar de permitir.

Qué puede ver un análisis externo y qué no

Esta es la parte que más confusión genera cuando se busca «escanear vulnerabilidades web online». Hay dos tipos de revisión muy distintos.

Análisis externo pasivo (sin permiso especial)

Mira la web como lo vería cualquier persona que la visita, sin intentar forzar nada. Puede detectar:

• Versiones visibles del servidor, del lenguaje o del gestor, cuando el servidor las muestra, y si tienen avisos de seguridad publicados (A03).
• Cabeceras de seguridad que faltan, como HSTS o la política de seguridad de contenidos (A02).
• Certificado y cifrado: caducidad, redirección a HTTPS y recursos cargados sin cifrar (A04).
• Librerías antiguas visibles en la página, como versiones de jQuery con fallos conocidos (A03).
• Configuración del correo del dominio (SPF y DMARC), que no forma parte del Top 10 pero se usa mucho para suplantar a empresas.

Lo que necesita una auditoría o una prueba de intrusión autorizada

Los fallos de control de acceso, inyección, diseño o autenticación no se ven desde fuera sin probar activamente la aplicación. Eso es una prueba de intrusión (pentest): un equipo especializado intenta aprovechar fallos de forma controlada, con un alcance pactado y autorización por escrito de quien es titular de la web. OWASP publica una guía de pruebas de seguridad web que sirve de referencia para estos trabajos.

Lanzar herramientas de ataque contra una web sin permiso no es un «escaneo online»: puede causar daños y tener consecuencias legales. Si una herramienta en línea promete encontrar todas las vulnerabilidades de cualquier web con solo escribir la dirección, desconfía.

Por dónde empezar en una pyme

1. Inventario: qué gestor, tema, plugins y versión de lenguaje usa tu web, y quién se encarga de cada cosa.
2. Actualizaciones: aplica las pendientes con copia de seguridad previa y elimina lo que no uses.
3. Accesos: revisa las cuentas con permisos de administración, cambia contraseñas compartidas y activa la verificación en dos pasos.
4. Configuración: HTTPS en toda la web, cabeceras de seguridad y sin versiones a la vista.
5. Copias y registros: copias automáticas fuera del servidor, probadas, y alguien que reciba los avisos.
6. Revisión periódica: repite el análisis tras cada cambio importante y cuando se publiquen avisos que te afecten.

Si tu organización trabaja con el sector público o necesita un marco más formal, el Esquema Nacional de Seguridad ordena estas medidas: lo explicamos en qué es el ENS.

Errores frecuentes

• Pensar que una web pequeña no interesa a nadie. La mayoría de los ataques son automáticos y buscan cualquier web con una versión vulnerable, no a una empresa concreta.
• Confundir el candado con seguridad. HTTPS protege la conexión, no la aplicación.
• Instalar plugins para todo. Cada componente nuevo es más código que mantener.
• Dar por buena una web porque un análisis no encuentra nada. Desde fuera solo se ve lo que el servidor enseña.

Cómo comprobarlo

El diagnóstico gratuito de XEVIA es un análisis externo pasivo: revisa la página de inicio desde fuera, sin accesos ni intrusión, y señala versiones visibles con avisos de seguridad, cabeceras que faltan, el estado del certificado, librerías antiguas y la configuración del correo. Es orientativo y no sustituye una auditoría. Puedes centrarte en esta parte con la herramienta para comprobar la seguridad de tu web; tienes el resto en el índice de herramientas.

Para confirmar versiones desde dentro, revisar gestor y complementos y ponerlos al día con copia y pruebas, consulta la revisión de seguridad web de XEVIA. No es una prueba de intrusión ni certifica la seguridad de la web: si la necesitas, te lo diremos.

Preguntas frecuentes

¿Cuál es la vulnerabilidad web más común?

Según el OWASP Top 10:2025, los fallos de control de acceso ocupan el primer puesto. En webs de pymes basadas en gestores de contenidos, lo más habitual en la práctica son los componentes sin actualizar.

¿Ha cambiado mucho el OWASP Top 10 desde 2021?

Sí. En 2025 aparecen los fallos de la cadena de suministro de software, que amplían la antigua categoría de componentes vulnerables, y la gestión incorrecta de condiciones excepcionales como categoría nueva. La configuración incorrecta sube al segundo puesto.

¿Es legal escanear una web para buscar vulnerabilidades?

Mirar lo que la web muestra públicamente, como hace un análisis pasivo, es lo mismo que hace cualquier navegador. Intentar aprovechar fallos o forzar accesos requiere autorización expresa de quien es titular de la web.

¿Cada cuánto debo revisar la seguridad de mi web?

Tras cada cambio importante (actualización, plugin nuevo, cambio de servidor) y cuando se publique un aviso que afecte a tu tecnología. Para webs con tienda o datos de clientela, conviene además una revisión periódica.