Seguridad web
HTTPS, cabeceras y superficie expuesta
Ejemplo de informe
Este ejemplo usa datos ficticios de una web de pyme típica. Te muestra el score, las prioridades y el plan de acción tal como los recibirías tú.
Este informe usa datos ficticios de cafeteria-ejemplo.es. No representa ningún negocio real.
Mejorable
Dominio analizado
HTTPS, cabeceras y superficie expuesta
MX, SPF y DMARC del dominio
Aviso legal, privacidad y cookies
Title, meta, H1, sitemap, robots
Tamaño del HTML y compresión
Señales públicas del servidor
La web de cafeteria-ejemplo.es tiene una base técnica correcta — HTTPS activo, HSTS declarado y SEO básico en orden — pero presenta dos señales relevantes de correo y seguridad que conviene resolver antes de lanzar campañas o mandar correos a clientes: DMARC en modo observación y CSP ausente.
WordPress está detectado y xmlrpc.php responde públicamente. No implica compromiso, pero es un punto a tapar por higiene. El resto de señales son mejoras de mantenimiento sin urgencia inmediata.
2
Altos
2
Medios
1
Bajos
Revisión manual
Un experto revisa tu informe real, descarta falsos positivos y te da un plan de acción claro que tú o tu técnico podéis ejecutar.
Ordenado por impacto y facilidad de ejecución.
Para el negocio
Tu dominio publica DMARC pero en modo pasivo. Esto no protege a tus clientes frente a correos falsificados con tu nombre de dominio. Si alguien recibe un correo falso tuyo, su bandeja no lo rechaza automáticamente.
Para el técnico
Actualizar el registro TXT _dmarc con p=quarantine o p=reject de forma progresiva. Revisar informes DMARC durante al menos 2 semanas antes de endurecer la política.
Para el negocio
Sin CSP, el navegador de tus visitas no recibe instrucciones sobre qué fuentes de scripts son seguras. No significa que la web esté comprometida, pero reduce una capa de protección ante ciertos ataques.
Para el técnico
Añadir un header Content-Security-Policy inicial con default-src 'self', script-src, object-src 'none', base-uri 'self' y frame-ancestors 'none'. Probar primero en Report-Only para no romper scripts externos.
Para el negocio
WordPress activa por defecto un punto de acceso llamado xmlrpc.php que ya no es necesario en webs modernas. No indica que la web esté hackeada, pero es un endpoint habitual en listas de escaneo.
Para el técnico
Deshabilitar o restringir xmlrpc.php via .htaccess o un plugin de seguridad (Wordfence, iThemes Security). Si no se usa XML-RPC para Jetpack o apps móviles, bloquearlo completamente.
Para el negocio
El registro SPF existe pero termina en ~all (softfail) en lugar de -all (reject). Esto permite que servidores no autorizados envíen correo con tu dominio sin rechazo explícito.
Para el técnico
Cambiar el sufijo del registro TXT SPF de ~all a -all si todos los servidores de correo legítimos están ya listados. Verificar con MXToolbox antes del cambio.
Para el negocio
Algunas cookies no declaran el atributo SameSite. Es una señal técnica menor sin impacto inmediato, pero puede afectar a la compatibilidad futura con navegadores.
Para el técnico
Revisar cookies de sesión y analítica y añadir SameSite=Lax (o SameSite=Strict cuando sea posible). Un plugin de caché o de cookies en WordPress puede añadirlo automáticamente.
Revisión manual
Un experto revisa tu informe real, descarta falsos positivos y te da un plan de acción claro que tú o tu técnico podéis ejecutar.
Datos ficticios · Analiza tu dominio real en trust-check.es · Consultas: contacto@trust-check.es