Qué olvidan los sitios: el 30% sin ninguna cabecera segura

La seguridad de un sitio suele depender de pequeños ajustes que nadie llegó a activar: una cabecera ausente, un dominio de correo sin proteger, un plugin que lleva un año sin actualizarse. Analizamos qué tienen en común 215 sitios revisados con nuestro escáner gratuito PromoPilot Shield, y el panorama resulta más corriente, y más fácil de corregir, de lo que cabría esperar.

Datos: análisis del 16.07 al 06.11.2026, actualizado el 06.11.2026

Sobre la muestra

Son 215 sitios únicos que sus propietarios o especialistas enviaron a Shield entre el 16 de julio y el 6 de noviembre de 2026. La muestra no es aleatoria, así que todo lo que sigue describe nuestra muestra, no internet en su conjunto. Los detalles están en la sección «Metodología» al final.

Cabeceras de seguridad: la protección más barata que los sitios se saltan

Las cabeceras de seguridad son instrucciones breves que el servidor envía al navegador con cada página. No cuestan nada y normalmente requieren una línea de configuración cada una. Esto es lo que hacen las seis que revisamos:

• Strict-Transport-Security (HSTS) indica a los navegadores que usen siempre HTTPS con tu dominio, lo que ayuda a evitar los ataques de degradación.
• Content-Security-Policy (CSP) enumera los orígenes desde los que una página puede cargar scripts y limita el daño del código inyectado.
• X-Frame-Options impide que otros sitios incrusten tus páginas en un marco oculto (clickjacking).
• X-Content-Type-Options prohíbe que los navegadores adivinen el tipo de archivo, lo que cierra una vía para scripts camuflados.
• Referrer-Policy controla qué parte de la dirección de tu página se transmite a otros sitios.
• Permissions-Policy desactiva funciones del navegador, como la cámara o la geolocalización, que tus páginas no necesitan.

Las cabeceras ausentes tienden a venir en bloque. El resultado individual más frecuente fue no tener ninguna de las seis: 65 sitios. El segundo más frecuente fue tener las seis: 38 sitios. En medio, a 22 sitios les falta una, a 26 dos, a 13 tres, a 15 cuatro y a 36 cinco. Dicho de otro modo, los sitios rara vez añaden cabeceras de una en una: o tienen una configuración deliberada o no tienen nada.

HSTS es la más extendida de las seis y aun así falta en el 46% de los sitios (99 de 215). Content-Security-Policy es la más difícil de acertar, así que su 65% (140 de 215) es comprensible, pero las cabeceras más sencillas no tienen esa excusa.

Correo: quién puede enviar mensajes en tu nombre

Los registros de correo viven en el DNS, no en el sitio web, y por eso se olvidan con tanta frecuencia. SPF enumera los servidores autorizados a enviar correo de tu dominio. DMARC indica a los servidores receptores qué hacer con los mensajes que no superan la comprobación. Sin ambos, cualquiera puede enviar un correo que parece venir de ti.

En nuestra muestra, el 49% de los dominios (105 de 215) no tenía registro DMARC. Otro 33% (71) lo tenía en p=none, que solo recopila informes y no bloquea nada. Eso suma un 82% (176 de 215) sin DMARC estricto (DMARC estricto: p=quarantine o p=reject). Faltaba SPF en el 28% (60 de 215). Para una empresa las consecuencias son concretas: facturas falsas o correos de restablecimiento de contraseña que llegan a tus clientes con el nombre de tu dominio, y que tus correos reales acaben más a menudo en spam.

Otros dos registros faltaban casi en todas partes: CAA (93%, 200 de 215) y MTA-STS (71%, 152 de 215). CAA limita qué autoridades pueden emitir certificados para tu dominio; MTA-STS obliga a que el correo entrante se entregue cifrado. Conviene tener ambos, pero el riesgo es bajo para un sitio pequeño típico. Nosotros corregiríamos DMARC mucho antes que cualquiera de los dos.

WordPress frente al resto

Los sitios WordPress de nuestra muestra (n=50) se distinguen claramente de los otros 165 sitios.

Esto no es un veredicto sobre WordPress en sí. Es el CMS más popular del mundo y por eso también la más estudiada: la base de datos abierta de vulnerabilidades de WordPress en la que se apoya nuestro escáner contiene 1 797 entradas de plugins y 84 de temas. Las coincidencias proceden de versiones desactualizadas de plugins, temas y núcleo. Una salvedad sobre el 4%: el escáner dispone de una base detallada de vulnerabilidades para plugins y temas de WordPress, mientras que en otras plataformas revisa sobre todo bibliotecas JavaScript y software de servidor, así que la diferencia refleja en parte lo que podemos ver y no solo lo segura que sea cada plataforma.

Conviene tener presente qué significa aquí «componente vulnerable»: la versión instalada cae dentro de un rango incluido en la base de datos. No comprobamos si el fallo puede explotarse realmente en ese sitio.

Cookies y divulgación de versiones

Las cookies y los banners del servidor son pequeños detalles que ayudan a un atacante a prepararse. Entre los 215 sitios:

• el 21% (45) establece cookies sin HttpOnly, por lo que los scripts de la página pueden leerlas;
• el 16% (35) establece cookies sin Secure, por lo que pueden viajar por HTTP sin cifrar;
• el 19% (40) establece cookies sin SameSite, lo que debilita la protección frente a solicitudes entre sitios;
• el 17% (36) envía una cabecera X-Powered-By con versión, y el 11% (24) muestra la versión del servidor en una cabecera;
• el 6% (13) no redirige a los visitantes de HTTP a HTTPS.

Ninguno de estos puntos es una brecha por sí solo. En conjunto le ahorran tiempo a un atacante, y se cierran en cuestión de minutos.

Una lista de comprobación de 30 minutos

1. Añade ahora cinco cabeceras, CSP por separado (siguiente paso). Ejemplo para Nginx (dentro del bloque server):

   add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
   add_header X-Frame-Options "SAMEORIGIN" always;
   add_header X-Content-Type-Options "nosniff" always;
   add_header Referrer-Policy "strict-origin-when-cross-origin" always;
   add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

   Apache (.htaccess):

   Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
   Header always set X-Frame-Options "SAMEORIGIN"
   Header always set X-Content-Type-Options "nosniff"
   Header always set Referrer-Policy "strict-origin-when-cross-origin"
   Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

   Añade Content-Security-Policy al final, primero como Content-Security-Policy-Report-Only, porque puede romper scripts de los que dependes.
2. Publica un registro SPF que enumere solo los servicios que realmente envían tu correo.
3. Publica DMARC. Empieza con p=none y una dirección para informes, lee los informes durante un par de semanas y después pasa a quarantine y, por último, a reject.
4. Actualiza plugins, temas y núcleo, y elimina todo lo que no uses.
5. Oculta la versión del CMS y elimina X-Powered-By (expose_php = Off elimina el X-Powered-By de PHP, server_tokens off oculta la versión de Nginx).
6. Establece HttpOnly, Secure y SameSite en las cookies de sesión.
7. Redirige todo el tráfico HTTP a HTTPS con una redirección permanente.

Prueba el resultado tras cada cambio, porque una cabecera incorrecta puede romper contenido incrustado, widgets de pago o analítica.

Comprueba tu propio sitio

Puedes ver cómo está tu sitio con un análisis gratuito en PromoPilot Shield (promopilot.link/es/security/). Es una comprobación pasiva y un punto de partida, no una protección por sí misma: corregir lo que encuentre sigue siendo cosa tuya.

Metodología

• Fuente: análisis del escáner gratuito PromoPilot Shield del 16.07.2026 al 06.11.2026. El escáner es pasivo: lee respuestas del servidor, DNS y el HTML de la página principal y de un conjunto limitado de URL, sin intentos de intrusión.
• Unidad: un sitio (host sin www), con su último análisis correcto. De 285 ejecuciones, 272 fueron correctas y 218 sitios únicos; excluimos 3 (cuentas de prueba y sitios de PromoPilot), con lo que quedan 215.
• Plataforma: detectada por indicios en las respuestas (generator, rutas, cabeceras): WordPress 50, Next.js 10, Shopify 7, Joomla, Wix y OpenCart 3 cada uno; en 139 la plataforma no se detecta o es propia. Comparamos solo WordPress (n=50) con el resto (n=165), porque los demás grupos tienen menos de 20 sitios.
• Componente vulnerable: la versión del plugin, tema o núcleo coincide con un rango de la base de datos abierta de vulnerabilidades de WordPress (1 797 entradas de plugins y 84 de temas en nuestro feed al 06.11.2026). Es una coincidencia de versión; no se probó la explotación.
• Seis cabeceras: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, contadas como ausentes en la página principal.
• Correo: SPF y DMARC se leen del DNS del dominio. «DMARC débil» significa p=none o un registro sin política.
• Calificaciones: la escala de Shield de A+ a E y una puntuación de 0 a 100 ponderan los hallazgos según el nivel de riesgo.
• Limitaciones: la muestra no es aleatoria: son sitios que propietarios o especialistas decidieron enviar (autoselección). Las cifras describen esta muestra, no todo internet. Por país: .com 84, .ua 24, el resto menos de 20, por lo que no comparamos países. No publicamos dominios, solo agregados de grupos de 20 sitios o más.

FAQ

¿Qué cabeceras de seguridad son imprescindibles?

No existe una única lista obligatoria, pero seis cabeceras cubren lo básico: Strict-Transport-Security (HSTS), Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy y Permissions-Policy. HSTS y X-Content-Type-Options son las más fáciles de añadir y rara vez rompen algo. Content-Security-Policy es la más potente, pero requiere pruebas, así que empieza en modo report-only.

¿Por qué es peligroso que falte un registro DMARC?

Sin DMARC, los servidores de correo receptores no tienen instrucciones sobre qué hacer con los mensajes que afirman falsamente venir de tu dominio. Los atacantes pueden enviar a tus clientes correos de phishing que parecen tuyos. En nuestra muestra, el 49% de los dominios (105 de 215) no tenía registro DMARC y otro 33% (71) tenía p=none, que solo supervisa y no bloquea nada.

¿Es WordPress inseguro por sí mismo?

No. En nuestra muestra la diferencia está ligada a las versiones de plugins, temas y núcleo, no a la plataforma como tal. La versión de un plugin, tema o núcleo coincidió con una vulnerabilidad conocida en el 30% de los sitios WordPress (15 de 50) frente al 4% del resto (7 de 165). Actualizar y eliminar los plugins que no se usan elimina esas coincidencias. Parte de la brecha se debe a que la base de datos de WordPress es más detallada.

¿Cómo puedo comprobar mi propio sitio?

Ejecuta un análisis gratuito en PromoPilot Shield: lee de forma pasiva las respuestas de tu servidor, los registros DNS y el HTML de la página principal, y muestra qué cabeceras y registros de correo faltan y qué información se revela de más. También puedes inspeccionar las cabeceras con las herramientas de desarrollo del navegador o con curl -I, y comprobar SPF y DMARC con cualquier herramienta de consulta DNS.

¿Necesitan los sitios pequeños CAA y MTA-STS?

Normalmente son de baja prioridad. CAA faltaba en el 93% de los sitios (200 de 215) y MTA-STS en el 71% (152 de 215), pero el riesgo práctico es bajo en comparación con la falta de DMARC, los plugins desactualizados o la ausencia de HSTS. Añádelos cuando lo básico esté resuelto, sobre todo si gestionas correo sensible o pagos.

Cómo citar

PromoPilot (2026). Qué olvidan los sitios: ajustes de seguridad en 215 análisis de Shield. Datos 16.07–06.11.2026. CC BY 4.0: https://promopilot.link/uploads/blog/research/site-security-0711/site-security-settings-2026-11-06.csv . Artículo: https://promopilot.link/es/blog/que-olvidan-los-sitios-ajustes-de-seguridad-215-analisis

Descargar los datos

La tabla agregada (CSV, licencia CC BY 4.0): https://promopilot.link/uploads/blog/research/site-security-0711/site-security-settings-2026-11-06.csv. Contiene solo porcentajes, sin dominios.