Escaneo de exposición del sitio — encuentra las puertas abiertas antes que un atacante.

No. Es reconocimiento estrictamente no intrusivo: peticiones GET de solo lectura a URLs públicas del sitio que has verificado que es tuyo. Nunca envía payloads de explotación, ni hace fuerza bruta de logins, ni fuzzing de entradas, ni cambia nada, así que no puede dañar una tienda en producción. Además se identifica como Relvato en la petición, en lugar de actuar como un atacante sigiloso.

El escaneo de vulnerabilidades comprueba tus plugins y temas instalados contra CVEs conocidos: va de código vulnerable. El escaneo de exposición comprueba la configuración y qué es accesible desde fuera —archivos expuestos, endpoints abiertos, cabeceras débiles—, algo que ningún escáner de código ve. Son complementarios: uno encuentra software vulnerable, el otro puertas abiertas.

Sí. Las pruebas genéricas —claves publicadas en tus páginas y scripts, source maps, reglas de cookies y CORS, archivos expuestos, listado de directorios, cabeceras de seguridad ausentes— se aplican a cualquier sitio; las pruebas específicas de WordPress (XML-RPC, enumeración de usuarios por REST, versión del readme) simplemente no coinciden en otros. No hace falta ningún plugin. En WordPress, instalarlo añade la parte que solo ve el servidor: qué hay realmente en tu raíz web y qué ajustes amplían el daño de cualquier otro fallo.

Es deliberadamente suave: una lista pequeña y curada de peticiones a baja frecuencia, cada una con un tiempo de espera corto, desde un user-agent identificado. Solo se ejecuta en un dominio que has verificado, y te apuntas activando el monitor. Es el mismo primer barrido no intrusivo que un profesional de seguridad haría en un sitio que está autorizado a probar.

Un secreto o backup expuesto hace fallar el monitor y te avisa de inmediato: son problemas de cerrar ya. Las carencias de hardening (cabeceras ausentes, XML-RPC habilitado, enumeración) se señalan como avisos para revisar. Lo que sea esperado en tu sitio puedes marcarlo como revisado para que no vuelva a molestar.

No debería. La mayor parte del análisis es tráfico normal: las páginas y los scripts que cualquier navegador carga. La parte que pide archivos como /.env es justo lo que un firewall de servidor está hecho para bloquear, así que Relvato solo hace esas peticiones cuando merecen la pena: con el plugin instalado pregunta a tu sitio cuáles de esos archivos existen de verdad y pide únicamente esos. Y si tu firewall las rechaza, el resultado dice que la prueba de archivos fue rechazada en lugar de dar un aprobado limpio.

No. Cuando pregunta a tu sitio desde dentro, la respuesta es una lista de nombres y tamaños, nunca el contenido. Ese endpoint solo responde por rutas dentro de la raíz web y rechaza cualquier intento de salir de ella, y un hallazgo muestra como mucho los primeros caracteres de una clave, para que el propio informe no se convierta en la filtración.

En WordPress con el plugin de Relvato, ocho hallazgos habituales tienen un arreglo con un clic que aplicas en WordPress → Relvato, y cada uno se puede volver a desactivar allí: desde desactivar XML-RPC hasta añadir cabeceras de seguridad seguras. Relvato nunca añade automáticamente una Content-Security-Policy ni HSTS: un valor incorrecto en cualquiera de las dos puede romper un sitio, así que tiene que configurarlas una persona.

Sí, en WordPress 6.9 o posterior con el plugin de Relvato 1.43.0 o posterior. Los plugins pueden registrar abilities que los asistentes de IA y la API REST pueden llamar. El escaneo las lista desde dentro de tu sitio y pregunta al propio callback de permisos de cada una, como visitante sin sesión, si cualquiera puede ejecutarla, sin ejecutarla. Una ability que cualquiera puede ejecutar y que no es de solo lectura se informa como grave; las abiertas de solo lectura, las que borran datos y pueden usar los asistentes de IA, y las nuevas tras una actualización son avisos.