¿Están bien protegidas las webs populares de Emiratos y Arabia Saudí? Medición de 1000 dominios .ae y .sa (septiembre de 2026)

Tomé los primeros 500 dominios terminados en .ae y los primeros 500 terminados en .sa 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.

Medí desde Polonia. En 344 de los 1000 dominios, la página de inicio no respondió a mis peticiones, mostró una comprobación antibots o devolvió un error. Esas páginas de inicio quedan fuera de las cifras de página y no se cuentan como inseguras; el apartado de método explica por qué.

Principales resultados

• El 24 de septiembre de 2026, 499 de 987 dominios .ae y .sa populares (50,6 %) tenían una política DMARC que indica a los servidores de correo receptores que rechacen o pongan en cuarentena el correo falsificado: 234 de 498 en Emiratos (47,0 %) y 265 de 489 en Arabia Saudí (54,2 %).
• En la medición del 24 de septiembre de 2026, 408 de las 652 páginas de inicio populares de Emiratos y Arabia Saudí servidas por HTTPS (62,6 %) enviaban una cabecera HSTS, y 280 de 656 (42,7 %) aplicaban una Content-Security-Policy.
• En septiembre de 2026, 182 de 832 dominios populares de Emiratos y Arabia Saudí (21,9 %) seguían aceptando conexiones TLS 1.0. De esos 182, 101 se sirven a través de Cloudflare, que acepta TLS 1.0 hasta que el propietario sube la versión mínima.
• Los dominios saudíes que publican DMARC eligen sobre todo su opción más estricta: 232 de 363 registros saudíes (63,9 %) dicen p=reject, frente a 139 de 368 en Emiratos (37,8 %).
• 256 de 987 dominios (25,9 %) no tienen ningún registro DMARC, y otros 198 (20,1 %) lo tienen configurado como p=none, que no bloquea nada.
• Encontré un archivo security.txt, que indica a los investigadores dónde comunicar una vulnerabilidad, en al menos 41 de 649 sitios (6,3 %).
• Frente a la misma medición de dominios polacos, las páginas de inicio de Emiratos y Arabia Saudí envían HSTS y CSP con más frecuencia, mientras que menos dominios admiten TLS 1.3. La comparación tiene límites, descritos más abajo.

Suplantación de correo: DMARC y SPF

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 es habitual: lo tienen 843 de 987 dominios (85,4 %), 426 de 497 en Emiratos (85,7 %) y 417 de 490 en Arabia Saudí (85,1 %). Pero SPF por sí solo no comprueba la dirección que el destinatario ve en el campo «De». Eso solo lo hace DMARC.

• Emiratos Árabes Unidos (.ae)47,0%234 de 498
• Arabia Saudí (.sa)54,2%265 de 489
• Polonia (.pl), para comparar46,1%460 de 997

El registro propio del dominio con p=quarantine o p=reject, aplicado a todo el correo (pct=100 o sin pct). Dominios con una respuesta DNS definitiva. Polonia: la misma medición, el mismo día.

Entre los dominios que reciben correo (con registros MX), la proporción con una política que bloquea es algo mayor: 216 de 430 en Emiratos (50,2 %) y 253 de 426 en Arabia Saudí (59,4 %). En el resto, que un mensaje falsificado llegue o no a la bandeja de entrada depende 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 731 registros DMARC, 618 (84,5 %) incluyen una dirección para informes agregados (rua). La protección, sin embargo, solo empieza con quarantine o reject. Los dominios saudíes que publican DMARC suelen ir hasta el final: 232 de 363 registros (63,9 %) dicen p=reject. En Emiratos las tres opciones están más igualadas: p=none en 126 de 368 (34,2 %), quarantine en 103 (28,0 %) y reject en 139 (37,8 %).

Un detalle de la lista saudí: 26 dominios usan quarantine o reject con un pct inferior a 100, lo que aplica la política solo a esa parte del correo que no supera las comprobaciones.

Fallos menores de SPF: 10 de 843 registros (1,2 %) necesitan más de las 10 consultas DNS que permite el estándar, 11 dominios (1,3 %) 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: 652 de 656 páginas de inicio analizadas (99,4 %) cargan desde una dirección https://. Las diferencias están en lo que lo acompaña.

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 408 de 652 páginas de inicio con HTTPS (62,6 %), y 246 (37,7 %) 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 182 de 832 dominios (21,9 %). 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 182 dominios, 101 (55,5 %) 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: 60 de 92 en Emiratos y 41 de 90 en Arabia Saudí. Los demás aceptan TLS 1.0 en sus propios servidores o con otros proveedores.

TLS 1.3, la versión actual, funciona en 620 de 834 dominios (74,3 %), más a menudo en Emiratos (350 de 443, 79,0 %) que en Arabia Saudí (270 de 391, 69,1 %).

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 99 de 994 dominios (10,0 %).

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 12 páginas de inicio (1,8 %) 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,6%17 de 656
• B39,0%256 de 656
• C19,4%127 de 656
• D18,6%122 de 656
• F20,4%134 de 656

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.

Plataformas y software anticuado

Reconocí la plataforma en 267 de las 656 páginas de inicio. Las otras 389 (59,3 %) son sitios a medida o no revelan sobre qué funcionan, así que las proporciones siguientes son límites inferiores.

WordPress mueve 88 de 656 páginas de inicio (13,4 %): 55 de 346 en Emiratos y 33 de 310 en Arabia Saudí. Le siguen Drupal (31), Microsoft SharePoint (28), Shopify (27), Sitecore (23) y Magento (15).

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

• 30 de las 58 no están en la última versión, la 7.1.2,
• 25 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.

Solo 34 de 656 páginas de inicio indican su versión de PHP en una cabecera, así que esto describe esas 34, no toda la web. De ellas, 16 usan ramas que ya no reciben ninguna corrección (8.1 y anteriores), 13 reciben solo correcciones de seguridad (8.2 y 8.3), y 5 tienen soporte completo (8.4 y 8.5).

Un nombre de servidor con número de versión aparece en las cabeceras de 60 de 656 páginas de inicio (9,1 %); en 34 de esas 60 es Microsoft IIS. 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 41 de 649 sitios (6,3 %): 16 de 345 en Emiratos (4,6 %) y 25 de 304 en Arabia Saudí (8,2 %). Es un límite inferior: otros 21 sitios respondieron con una redirección a un archivo security.txt en otra dirección, y no seguí las redirecciones. De los 41 archivos, 32 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 Manager38,6%253 de 656
• Google Analytics36,4%239 de 656
• Meta Pixel9,8%64 de 656
• Microsoft Clarity5,9%39 de 656
• TikTok Pixel3,8%25 de 656
• Snap Pixel3,5%23 de 656
• Hotjar3,0%20 de 656
• X (Twitter) Pixel2,4%16 de 656

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 395 de 656 páginas de inicio (60,2 %). 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 12 de 656 páginas de inicio (1,8 %).

Una plataforma de consentimiento conocida, como OneTrust, CookieYes o TrustArc, aparece en 41 de 656 páginas de inicio (6,3 %). Eso no significa que las demás no tengan banner de consentimiento. Los banners a medida, los integrados en una plataforma 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.

Comparación con Polonia

El mismo día y con las mismas comprobaciones medí los 1000 dominios .pl más populares (resultados). Las cifras de DNS se comparan bien, porque en ambas listas cubren casi todos los dominios. Las de la página de inicio, menos: las listas del Golfo llegan más abajo en el ranking (hasta la posición 835.367, frente a la 136.495 en Polonia), y 344 de las 1000 páginas de inicio del Golfo no se pudieron analizar desde Polonia, frente a 113 de las 1000 polacas. Lea las cifras de la página de inicio como una comparación aproximada.

• HSTS, Emiratos y Arabia Saudí62,6%408 de 652
• HSTS, Polonia46,0%406 de 882
• CSP, Emiratos y Arabia Saudí42,7%280 de 656
• CSP, Polonia24,5%217 de 887

HSTS sobre las páginas de inicio servidas por HTTPS, CSP sobre todas las páginas de inicio analizadas. Ambas medidas el 24 de septiembre de 2026 con las mismas comprobaciones.

También reciben una F en la comprobación de cabeceras menos páginas de inicio de Emiratos y Arabia Saudí: 134 de 656 (20,4 %), frente a 290 de 887 (32,7 %) en Polonia. Polonia va por delante en TLS 1.3 (833 de 953 dominios, 87,4 %, frente a 620 de 834, 74,3 %) y en registros CAA (192 de 999, 19,2 %, frente a 99 de 994, 10,0 %). En DMARC la diferencia es menor: el 50,6 % de los dominios de Emiratos y Arabia Saudí y el 46,1 % de los polacos bloquean el correo suplantado.

Qué significa esto para su empresa

Si estos ajustes faltan en algunos de los sitios más populares de la región, 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.

Las leyes de protección de datos de ambos países piden medidas técnicas adecuadas para proteger los datos personales: en Emiratos, el artículo 20 del Decreto-ley Federal n.º 45 de 2021; en Arabia Saudí, el artículo 19 de la Ley de Protección de Datos Personales. Ninguna de las dos menciona DMARC ni HSTS, pero son ajustes que cualquiera puede comprobar desde fuera. Lo que cada ley exige al sitio web de una empresa se explica para Emiratos y para Arabia Saudí. Si es proveedor de empresas de la UE, sus cuestionarios de proveedores de NIS2 preguntan por estos mismos ajustes: consulte NIS2 y su web.

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 500 dominios terminados en .ae y los primeros 500 terminados en .sa por orden de posición, incluidos dominios de segundo nivel como gov.ae y com.sa. El primer millón contiene 744 dominios .ae, y los 500 elegidos ocupan las posiciones de la 3319 a la 705.110; contiene 548 dominios .sa, y los 500 elegidos ocupan las posiciones de la 1245 a la 835.367. No se incluyen los dominios con los códigos de país en escritura árabe. Tranco clasifica dominios, no sitios web, así que las listas incluyen 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: la lista .sa de 07:32 a 07:39 UTC (de 10:32 a 10:39 en Riad) y la lista .ae de 07:43 a 07:47 UTC (de 11:43 a 11:47 en Emiratos), 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. Desde Polonia se pudieron analizar 656 de las 1000 páginas de inicio: 346 de 500 en Emiratos y 310 de 500 en Arabia Saudí. Del resto, 178 dominios no dieron ninguna respuesta HTTP (61 .ae, 117 .sa), 144 respondieron con una comprobación antibots o un bloqueo como un 403 (84 .ae, 60 .sa), y 22 devolvieron otro error (9 .ae, 13 .sa). La mayoría de los dominios .sa sin respuesta se resuelven en DNS, pero dejan que tanto la conexión https como la http agoten el tiempo de espera, que es el aspecto que tiene un bloqueo del tráfico extranjero, aunque no puedo demostrar la causa. Estas cifras describen mi punto de observación, no la seguridad de los sitios. Los dominios excluidos quedan fuera de las cifras de la página de inicio (cabeceras, HTML, security.txt, redirección) y no se cuentan como inseguros, 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, 987 de 1000; la comprobación de correo de 10 dominios .sa agotó el tiempo de espera por servidores de nombres lentos).

Definiciones. Una política DMARC que pone en cuarentena o rechaza 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 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 (59,3 % 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 mostrar otra cosa a los visitantes del Golfo.

Repetibilidad y verificaciones. La lista .ae se recogió también en una primera pasada completa unos 15 minutos antes, que no publico porque después corregí el código de recogida. Entre las dos pasadas, la diferencia mediana entre las métricas fue de 0,0 puntos porcentuales y el percentil 90, de 0,4; ninguna métrica con un denominador de 100 o más varió más de 1,1 puntos. Las variaciones mayores, de hasta 6,3 puntos, se dieron en denominadores inferiores a 60, y por eso en este artículo los grupos pequeños se dan solo en recuentos. La lista .sa se recogió una sola vez, con el código corregido. Además, volví a medir con otras herramientas 36 dominios elegidos al azar (8 .ae, 8 .sa y 20 .pl): 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. Las cifras agregadas, cada una con numerador, denominador, porcentaje y población, pueden descargarse libremente con licencia CC BY 4.0: gulf-2026-09.csv y gulf-2026-09.json (en inglés). Cubren los dos países juntos; las cifras por país de este artículo proceden de la misma pasada, contadas por separado con el mismo código. 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 500 dominios .ae y los 500 dominios .sa más populares, 24 de septiembre de 2026, https://shieldwave.io/blog/uae-saudi-websites-security-2026/

Completa: Radosław Fedorczuk (ShieldWave, ENSOMEDIA), «¿Están bien protegidas las webs populares de Emiratos y Arabia Saudí? Medición de 1000 dominios .ae y .sa (septiembre de 2026)», 24 de septiembre de 2026, https://shieldwave.io/blog/uae-saudi-websites-security-2026/. Datos agregados con licencia CC BY 4.0.

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