¿Están bien protegidas las webs más populares de Polonia? Medición de 1000 dominios .pl (septiembre de 2026)

Tomé los primeros 1000 dominios .pl del ranking Tranco, una lista elaborada para la investigación, y en la mañana del 24 de septiembre de 2026 los revisé desde fuera, tal como los ve cualquier visitante o servidor de correo. La medición fue pasiva: consultas DNS, una visita a cada página de inicio y unas pocas conexiones TLS por dominio, sin análisis de vulnerabilidades ni intentos de inicio de sesión. Los resultados se calcularon con las mismas comprobaciones que funcionan en las herramientas gratuitas de ShieldWave. No nombro ninguno de los dominios.

Principales resultados

• El 24 de septiembre de 2026, 460 de los 997 dominios .pl más populares (46,1 %) tenían una política DMARC que indica a los servidores de correo receptores que rechacen o pongan en cuarentena los mensajes que falsifican el dominio. Entre los dominios que reciben correo (con registros MX), eran 445 de 927 (48,0 %).
• En la medición del 24 de septiembre de 2026, 406 de las 882 páginas de inicio polacas populares servidas por HTTPS (46,0 %) enviaban una cabecera HSTS, y 217 de 887 (24,5 %) aplicaban una Content-Security-Policy.
• En septiembre de 2026, 230 de 952 dominios .pl populares (24,2 %) seguían aceptando conexiones TLS 1.0. De esos 230, 149 se sirven a través de Cloudflare, que acepta TLS 1.0 hasta que el propietario sube la versión mínima.
• 274 de 997 dominios (27,5 %) no tienen ningún registro DMARC, y otros 248 (24,9 %) lo tienen configurado como p=none, que no bloquea nada.
• En la comprobación de cabeceras de seguridad, 20 de 887 páginas de inicio (2,3 %) obtuvieron la nota más alta, A, y 290 (32,7 %) la más baja, F.
• Encontré un archivo security.txt, que indica a los investigadores dónde comunicar una vulnerabilidad, en al menos 78 de 881 sitios (8,9 %).
• De los 46 sitios que indican su versión de PHP en una cabecera, 26 usan una versión que ya no recibe ninguna corrección, 11 de ellos PHP 5.

Correo electrónico: quién puede enviar correo en nombre de su dominio

Basta un correo falsificado con la dirección de su empresa en el campo «De» para enviar a un cliente una factura falsa. Tres registros DNS protegen contra ello: SPF, DKIM y DMARC, que explico en SPF, DKIM y DMARC explicados. El que decide es DMARC: indica al servidor receptor qué hacer con un mensaje que dice ser suyo pero no supera las comprobaciones.

SPF está casi en todas partes: lo tienen 915 de 999 dominios (91,6 %). Pero SPF por sí solo no comprueba la dirección que el destinatario ve en el campo «De». Eso solo lo hace DMARC, y aquí las cifras son más bajas.

• Sin registro DMARC27,5%274 de 997
• p=none: supervisa, no bloquea nada24,9%248 de 997
• quarantine o reject, pero solo para parte del correo (pct inferior a 100)1,5%15 de 997
• quarantine o reject para todo el correo46,1%460 de 997

Dominios con una respuesta DNS definitiva. Solo cuenta el registro propio del dominio.

Así pues, 460 de 997 dominios (46,1 %) bloquean la suplantación. Entre los dominios con registros MX, los que reciben correo, son 445 de 927 (48,0 %). Los demás no tienen DMARC o tienen un registro que solo supervisa. Que un mensaje falsificado llegue o no a la bandeja de entrada depende entonces por completo de los filtros propios del receptor.

p=none no es un error, sino el primer paso recomendado: el dominio recoge informes y su propietario ve quién envía correo en su nombre. De los 723 registros DMARC, 622 (86,0 %) incluyen una dirección para informes agregados (rua). La protección, sin embargo, solo empieza con quarantine o reject. Entre los dominios que tienen DMARC, las tres opciones son casi igual de frecuentes: p=none en 248 de 723 (34,3 %), quarantine en 263 (36,4 %) y reject en 212 (29,3 %).

Fallos menores de SPF: 12 de 915 registros (1,3 %) necesitan más de las 10 consultas DNS que permite el estándar, dos dominios publican dos registros SPF en lugar de uno, y uno termina su registro en +all, lo que permite a cualquier servidor enviar correo en su nombre.

No informo sobre DKIM. Los selectores con los que se publican las claves DKIM no se pueden listar mediante DNS, así que «no encontrado» solo significaría «no está con los nombres habituales».

Cifrado: HTTPS, HSTS y TLS

HTTPS en sí es lo normal. Las diferencias están en lo que lo acompaña: la cabecera HSTS, las versiones antiguas de TLS y el registro CAA.

Los denominadores varían porque cada fila cuenta solo los dominios en los que esa comprobación obtuvo respuesta. Los detalles están en el apartado de método.

HSTS es una cabecera que indica al navegador que use solo HTTPS con el dominio durante un tiempo determinado. Sin ella, cada visita a una dirección escrita sin https:// empieza con una conexión sin cifrar antes de que el servidor la redirija, y en una wifi ajena esa conexión puede interceptarse. HSTS la envían 406 de 882 páginas de inicio con HTTPS (46,0 %), y 268 (30,4 %) con el periodo recomendado de al menos un año.

TLS 1.0 y 1.1 son versiones antiguas del protocolo de cifrado. Los navegadores las desactivaron en 2020 y el IETF las declaró oficialmente obsoletas en 2021 (RFC 8996). TLS 1.0 sigue aceptándose en 230 de 952 dominios (24,2 %). Un visitante con un navegador actual se conecta de todos modos con TLS 1.2 o 1.3, así que esto no es una vía para tomar el control de un sitio. Sí significa que el servidor acepta un cifrado anticuado si se le pide, y los auditores y los cuestionarios de seguridad para proveedores piden desactivar las versiones antiguas.

De esos 230 dominios, 149 (64,8 %) se sirven a través de Cloudflare, que acepta TLS 1.0 por defecto y deja de hacerlo solo cuando el propietario sube la versión mínima en el panel. Los otros 81 aceptan TLS 1.0 en sus propios servidores o con otros proveedores.

CAA es un registro DNS que enumera las autoridades de certificación que pueden emitir certificados para el dominio; las demás deben negarse. Lo encontré en 192 de 999 dominios (19,2 %).

Cabeceras de seguridad

Las cabeceras de seguridad son unas pocas líneas de instrucciones que el servidor envía al navegador junto con la página. Las describo en Cabeceras de seguridad de una web: qué son y qué pedir. Esta es su frecuencia en las páginas de inicio (HSTS está en el apartado de cifrado):

Otras 26 páginas de inicio (2,9 %) tienen CSP solo en modo Report-Only, en el que el navegador no bloquea nada.

La comprobación gratuita de cabeceras de seguridad (en inglés) las califica de la A a la F. Cada cabecera recibe una letra, HSTS y CSP cuentan doble y las demás una vez, y la media da la nota final. El estudio usó exactamente esa escala.

• A2,3%20 de 887
• B21,8%193 de 887
• C21,1%187 de 887
• D22,2%197 de 887
• F32,7%290 de 887

La escala de la comprobación gratuita de cabeceras de ShieldWave. HSTS y CSP cuentan doble, las demás cabeceras una vez.

Una F no significa que un sitio tenga un agujero, y una A no garantiza que no lo tenga. Las cabeceras son una segunda línea de defensa: limitan el daño cuando falla otra cosa. Que falten suele deberse a la configuración por defecto del servidor, que no las añade. A menudo las añade después una CDN o un plugin.

El mismo día y con el mismo método medí los 500 dominios .ae y los 500 dominios .sa más populares (Emiratos Árabes Unidos y Arabia Saudí). Sus páginas de inicio tienen CSP (280 de 656, 42,7 %) y HSTS (408 de 652, 62,6 %) con más frecuencia. La comparación es aproximada: esas listas llegan más abajo en el ranking, y 344 de las 1000 páginas de inicio no se pudieron analizar desde Polonia. Los detalles están en el informe de esa medición.

Plataformas y software anticuado

Reconocí la plataforma en una de cada cuatro páginas de inicio. En 663 de 884 páginas de inicio (75,0 %) no encontré rastro de ninguna plataforma conocida: son sitios a medida o sitios que no revelan sobre qué funcionan. Las proporciones siguientes son, por tanto, límites inferiores.

WordPress mueve 101 de 884 páginas de inicio (11,4 %). Le siguen Drupal (25), Magento (21) y TYPO3 (13). Las plataformas polacas de tiendas online (IdoSell, Shoper, AtomStore y RedCart) suman 12 entre todas.

La versión de WordPress es visible en 54 de las 101. Son cifras pequeñas, así que doy solo recuentos:

• 28 de las 54 no están en la última versión, la 7.1.2,
• 22 están en una rama anterior a la 7.1,
• 18 no están en la última versión de su propia rama, así que les faltan correcciones de seguridad ya publicadas para ella,
• la versión visible más antigua es WordPress 3.5.1, de 2013.

Solo 46 de 887 páginas de inicio indican su versión de PHP en una cabecera, así que esto describe esas 46, no toda la web. De ellas, 26 usan ramas que ya no reciben ninguna corrección (8.1 y anteriores), 11 de ellas PHP 5, cuya última rama perdió el soporte a finales de 2018. Otras 12 reciben solo correcciones de seguridad (8.2 y 8.3), y 8 tienen soporte completo (8.4 y 8.5).

Un nombre de servidor con número de versión, como Apache/2.4.41, aparece en las cabeceras de 74 de 887 páginas de inicio (8,3 %). Revelar la versión no es un agujero en sí, pero acota qué fallos conocidos le afectan.

En este estudio no revisé plugins. Si su web funciona con WordPress, empiece por Plugins de WordPress desactualizados: qué actualizar primero y qué borrar.

security.txt: dónde comunicar una vulnerabilidad

El archivo /.well-known/security.txt (RFC 9116) indica la dirección a la que un investigador de seguridad puede comunicar una vulnerabilidad que ha encontrado. Sin él, el aviso va a una dirección de contacto general, o a ninguna parte.

Encontré uno con el campo Contact: en 78 de 881 sitios (8,9 %). Es un límite inferior: otros 41 sitios respondieron con una redirección a un archivo security.txt en otra dirección, y no seguí las redirecciones. Aunque todas llevaran a un archivo válido, serían 119 de 881 (13,5 %). De los 78 archivos, 55 tienen el campo Expires que exige el estándar.

Rastreadores y plataformas de consentimiento

Esta parte es descriptiva. No se ejecutó JavaScript, así que solo veo las herramientas que aparecen en el HTML de la página de inicio. Si se ejecutan y cuándo, no lo puedo saber: un script puede esperar al consentimiento del visitante, y Google Tag Manager puede cargar herramientas que no están en el código de la página.

• Google Tag Manager45,6%403 de 884
• Google Analytics30,3%268 de 884
• Gemius12,3%109 de 884
• Meta Pixel10,2%90 de 884
• Microsoft Clarity3,4%30 de 884
• Hotjar2,5%22 de 884
• Matomo2,0%18 de 884

En cualquier forma: script, fragmento de instalación o una simple llamada. Estar en el código no indica si la herramienta se ejecuta antes del consentimiento.

Google Analytics o Google Tag Manager aparece en el código de 572 de 884 páginas de inicio (64,7 %). Gemius, el sistema polaco de medición de audiencias, está en 109 de 884 (12,3 %). Google Consent Mode con denegación por defecto, en el que las herramientas de Google funcionan sin cookies hasta que se da el consentimiento, aparece en 103 de 884 páginas de inicio (11,7 %).

Una plataforma de consentimiento conocida, como Cookiebot, OneTrust, Didomi o alguna que use el marco IAB TCF, aparece en 293 de 884 páginas de inicio (33,1 %). Eso no significa que las demás no tengan banner de consentimiento. Los banners a medida, los integrados en las plataformas de tienda online y las herramientas cargadas mediante Google Tag Manager son invisibles para este método, así que no saco de estas cifras ninguna conclusión sobre el cumplimiento legal.

Qué significa esto para su empresa

Si estos ajustes faltan en algunos de los sitios más populares del país, también es fácil que falten en uno más pequeño. Cada comprobación de la lista lleva un minuto y no requiere acceso a su servidor.

1. Correo electrónico. Pase la comprobación de SPF, DKIM y DMARC (en inglés). Si no tiene DMARC o tiene p=none, pase a quarantine paso a paso como se describe en SPF, DKIM y DMARC explicados. Protege contra las facturas falsas enviadas desde su dominio.
2. Cifrado. La comprobación del certificado SSL (en inglés) muestra el certificado, la redirección a HTTPS y las versiones de TLS. Si su sitio está detrás de Cloudflare, cambie el mínimo en el panel, en SSL/TLS, Edge Certificates, Minimum TLS Version. Elija TLS 1.2.
3. Cabeceras. La comprobación de cabeceras de seguridad (en inglés) muestra lo que falta. Cabeceras de seguridad de una web incluye un encargo listo para su desarrollador: empiece por HSTS con un max-age corto y CSP en modo Report-Only.
4. security.txt. Publique /.well-known/security.txt con los campos Contact y Expires. Son unas pocas líneas de texto.
5. Software. Actualice el CMS y los plugins, y quite los números de versión de las cabeceras del servidor. Para WordPress, consulte Plugins de WordPress desactualizados.
6. Rastreadores y consentimiento. La comprobación de cookies antes del consentimiento (en inglés) muestra si su página de inicio fija cookies de seguimiento o carga herramientas de analítica y publicidad antes de que el visitante acepte. Si es delegado de protección de datos, vea también Qué puede revisar un DPD en la web de un cliente sin ayuda de informática.

Si sus clientes están sujetos a NIS2, sus cuestionarios para proveedores preguntan por estos mismos ajustes. NIS2 y su web explica cómo prepararse.

Método

Dominios. Lista Tranco L5PV4, generada el 23 de septiembre de 2026 a las 22:00 UTC a partir de 30 días de datos (del 25 de agosto al 23 de septiembre de 2026) de cinco proveedores: Chrome UX Report, Farsight, Majestic, Cloudflare Radar y Cisco Umbrella. Tranco es un ranking elaborado para la investigación y protegido contra la manipulación. Tomé los primeros 1000 dominios terminados en .pl por orden de posición, incluidos dominios de segundo nivel como com.pl, gov.pl y edu.pl. El primer millón contiene 9214 dominios .pl; los 1000 elegidos ocupan las posiciones de la 667 a la 136.495. Tranco clasifica dominios, no sitios web, así que la lista incluye también dominios técnicos (CDN, servidores de publicidad y de medición) sin página de inicio.

Cuándo y desde dónde. 24 de septiembre de 2026, de 07:39 a 07:43 UTC (de 09:39 a 09:43 hora de Polonia), desde una conexión de red en Polonia. Las consultas DNS se enviaron a los resolutores públicos 1.1.1.1 y 8.8.8.8. Cada petición HTTP se identificó como ShieldWaveResearch/1.0 con un enlace a shieldwave.io; no se hizo pasar por un navegador.

Qué se envió. Por dominio, solo:

1. consultas DNS: direcciones, MX, TXT (SPF y DMARC), CAA,
2. una visita a la página de inicio (https://, o http:// si https no respondía; como máximo 5 redirecciones),
3. una petición http:// simple para ver si redirige a https,
4. negociaciones TLS en el puerto 443: una negociación completa y cuatro pruebas de versión (1.0, 1.1, 1.2 y 1.3),
5. una petición de /.well-known/security.txt.

Nada más: ni búsqueda de archivos, paneles de administración o copias de seguridad, ni formularios, inicios de sesión o cargas de prueba.

Las mismas comprobaciones que las herramientas gratuitas. Los resultados se calcularon con el mismo código que hace funcionar las herramientas gratuitas de ShieldWave (certificado, correo, cabeceras y cookies), en el commit 8db196d. Cualquiera puede revisar su propio dominio con la misma vara de medir.

Denominadores y exclusiones. Cada cifra tiene su propio denominador, porque no todas las comprobaciones obtienen respuesta de todos los dominios. De los 1000 dominios, se pudieron analizar 887 páginas de inicio. Del resto, 38 dominios no dieron respuesta HTTP (13 de ellos no tienen ninguna dirección en DNS), 52 respondieron con un muro antibots o un bloqueo como un 403, y 23 devolvieron otro error. Estos 113 quedan fuera de las cifras de la página de inicio (cabeceras, HTML, security.txt, redirección), pero siguen en las cifras de DNS, correo y TLS, que no dependen de la página. Las cifras de DNS cuentan solo respuestas definitivas (para DMARC, 997 de 1000).

Definiciones. Una política DMARC que bloquea la suplantación es el registro propio del dominio con p=quarantine o p=reject y pct=100 o sin pct. Un registro heredado de un dominio superior no cuenta. HSTS se cuenta solo en las páginas de inicio que terminan en HTTPS, y CSP solo cuando se aplica. security.txt cuenta cuando la respuesta es un 200 con un campo Contact:; una página HTML nunca cuenta.

Limitaciones.

• Solo la página de inicio, una visita, un día. Otras páginas pueden enviar otras cabeceras.
• Sin JavaScript: los rastreadores y las herramientas de consentimiento se leen del HTML. No puedo ver lo que carga Google Tag Manager ni lo que los scripts guardan después.
• Muchos resultados reflejan la configuración por defecto de una CDN o de un proveedor de alojamiento (TLS 1.0 en Cloudflare, cabeceras añadidas o no en el borde).
• Los sitios que bloquearon la visita automatizada no figuran en las cifras de la página de inicio, y pueden ser distintos de los que quedan.
• security.txt es un límite inferior, porque no se siguieron las redirecciones.
• La detección de plataformas es un límite inferior (75,0 % de páginas de inicio sin reconocer).
• No se informa sobre DKIM.
• Medido desde Polonia: los sitios que cambian según la ubicación del visitante pueden verse distintos desde otros lugares.

Repetibilidad y verificaciones. Un cuarto de hora antes hice una primera pasada completa sobre la misma lista. No la publico, porque después corregí la detección de Gemius. Salvo las cifras de Gemius, ninguna de las 250 métricas difirió entre las dos pasadas en más de 0,9 puntos porcentuales, y la diferencia mediana fue 0,0. Además, volví a medir con otras herramientas 36 dominios elegidos al azar, 20 de ellos de la lista polaca: DMARC y SPF a través de otro resolutor (9.9.9.9), HSTS y la cabecera Server con curl, TLS 1.0 con openssl, security.txt con curl. Las 216 comparaciones coincidieron.

Datos. No publico los datos en bruto, porque nombran sitios concretos. Todas las cifras agregadas, cada una con numerador, denominador, porcentaje y población, pueden descargarse libremente con licencia CC BY 4.0: pl-2026-09.csv y pl-2026-09.json (en inglés). La medición se puede repetir: la lista Tranco es pública y cada comprobación funciona en las herramientas gratuitas de ShieldWave.

Cómo citar

Breve: Fuente: ShieldWave, medición de los 1000 dominios .pl más populares, 24 de septiembre de 2026, https://shieldwave.io/blog/polish-websites-security-2026/

Completa: Radosław Fedorczuk (ShieldWave, ENSOMEDIA), «¿Están bien protegidas las webs más populares de Polonia? Medición de 1000 dominios .pl (septiembre de 2026)», 24 de septiembre de 2026, https://shieldwave.io/blog/polish-websites-security-2026/. Datos agregados con licencia CC BY 4.0.

Preguntas sobre el método o los datos: support@shieldwave.io.