Comprobar la seguridad de una web, gratis y online

La mayoría de los ataques a webs de pymes no van dirigidos a nadie en concreto. Son programas que recorren internet buscando versiones sin actualizar y configuraciones descuidadas. Lo primero que miran es lo mismo que puede ver cualquiera desde fuera. Este diagnóstico hace esa misma lectura, pero para avisarte a ti.

Qué es, y qué no es, este análisis

Es un análisis pasivo: pedimos tu página de inicio como lo haría un navegador, leemos las cabeceras que devuelve el servidor, consultamos el certificado y comprobamos un par de direcciones públicas. No probamos contraseñas, no enviamos datos raros a tus formularios ni intentamos entrar. Por eso es seguro pasarlo sobre cualquier web, y por eso tiene límites.

No es una prueba de intrusión ni una auditoría de seguridad. No certifica que tu web sea segura. Si necesitas confirmar versiones, revisar el gestor y sus plugins o aplicar parches, eso es la revisión de seguridad web de XEVIA, que se hace con tu permiso y con acceso.

La conexión

Lo básico: que la web vaya cifrada. Si no usa HTTPS, cualquiera en la misma red puede leer lo que se envía y el navegador la marca como «no segura». Si usa HTTPS pero la versión http:// no redirige, se puede seguir navegando sin cifrar. Y si el certificado caduca en menos de 30 días, te avisamos para que no te pille por sorpresa. Todo esto lo explicamos con calma en la herramienta para comprobar el certificado SSL.

Las cabeceras de seguridad

Son instrucciones que tu servidor envía al navegador con cada página. No cambian cómo se ve la web, pero cierran puertas a ataques habituales. El proyecto OWASP Secure Headers las documenta. Las que revisamos:

• Strict-Transport-Security (HSTS): obliga al navegador a usar siempre HTTPS con tu web.
• Content-Security-Policy: limita desde dónde se pueden cargar scripts y otros recursos.
• X-Content-Type-Options: evita que el navegador interprete un archivo como algo que no es.
• X-Frame-Options o frame-ancestors: impide que otra web meta la tuya dentro de un marco para engañar a la visita («clickjacking»).
• Referrer-Policy y Permissions-Policy: controlan qué información se comparte al salir de tu web y qué funciones del navegador puede usar.

Cómo corregirlo: la mayoría se añaden en la configuración del servidor o del alojamiento, sin tocar la web. Pide a tu proveedor que las active una a una y prueba la web después de cada cambio. La Content-Security-Policy es la más delicada: una regla mal hecha puede romper formularios o analítica, así que conviene empezar en modo de solo informe.

Lo que tu web cuenta de sí misma

Muchos servidores responden con su nombre y versión exacta, por ejemplo Server: Apache/2.4.41 o X-Powered-By: PHP/8.1.2. Algunos gestores de contenidos publican su versión en una etiqueta generator. Ese dato no es un fallo en sí, pero ahorra trabajo a quien busca webs con una versión vulnerable.

También buscamos jQuery anterior a la 3.5. Las versiones desde la 1.12 hasta antes de la 3.5 tienen un fallo público de inyección de código, recogido en el aviso CVE-2020-11022. Es frecuente en webs con temas o plugins antiguos.

Cómo corregirlo:

1. Oculta las versiones en las cabeceras (tu proveedor sabe hacerlo en minutos).
2. Quita la etiqueta generator con un ajuste del gestor o un plugin de seguridad.
3. Actualiza el gestor, el tema y los plugins. Si alguno obliga a mantener un jQuery viejo, plantéate sustituirlo.

Si tu web es un WordPress, te ayudará la guía sobre la versión de PHP en WordPress.

Los avisos de seguridad de cada momento

Cuando detectamos con qué tecnología funciona tu web (PHP, Node.js, Java o Python) la cruzamos con los avisos oficiales de seguridad que seguimos. Si el servidor muestra la versión, comparamos con la corregida. Si no la muestra, no te decimos que estás a salvo: te pedimos que lo confirmes con tu proveedor. También avisamos si el certificado depende de la cadena de eMudhra, cuyas claves de varios certificados intermedios se comprometieron en octubre de 2026. Tienes los avisos vigentes, con su fuente, en la página de revisión de seguridad web.

Detalles que suman

• Cookies sin protecciones. Las cookies que instala el servidor deberían llevar Secure (solo por HTTPS), HttpOnly (fuera del alcance de los scripts) y SameSite (no viajan en peticiones de otras webs). Es un cambio de configuración.
• Contenido mixto. Recursos que se piden por http:// dentro de una página segura. Cámbialos a https://.
• Scripts de terceros sin integridad. Si cargas más de dos scripts externos sin el atributo integrity (SRI), un fallo en ese proveedor se ejecutaría en tu web. Úsalo en las librerías con versión fija.
• Sin security.txt. El estándar RFC 9116 propone un archivo en /.well-known/security.txt con un contacto y una fecha de caducidad, para que quien encuentre un fallo sepa a quién avisar.

En el área de seguridad también revisamos el correo del dominio, porque la suplantación por correo es una puerta habitual. Lo tienes en la herramienta de SPF y DMARC.

Lo que un análisis automático no ve

Desde fuera solo se ve lo que el servidor enseña, y solo en la página de inicio. No vemos la versión de los plugins, ni si hay usuarios con contraseñas débiles, ni copias de seguridad, ni fallos en el área privada o en la lógica de la aplicación. Que el informe no marque un problema no significa que no exista. Si ya notas algo raro, como redirecciones a otras webs o páginas que no reconoces, lee la guía sobre qué hacer si tu WordPress ha sido hackeado y escríbenos.