Wie gut sind beliebte Websites in den VAE und Saudi-Arabien geschützt? 1.000 .ae- und .sa-Domains gemessen (September 2026)

Ich habe die ersten 500 Domains mit der Endung .ae und die ersten 500 mit der Endung .sa im Tranco-Ranking genommen, einer für die Forschung erstellten Liste, und sie am Morgen des 24. September 2026 von außen geprüft, so wie jeder Besucher oder Mailserver sie sieht. Die Messung war passiv: DNS-Abfragen, ein Aufruf jeder Startseite und einige TLS-Verbindungen pro Domain, ohne Schwachstellenscans und ohne Anmeldeversuche. Gezählt wurden die Ergebnisse mit denselben Prüfungen, die in den kostenlosen Tools von ShieldWave laufen. Ich nenne keine der Domains.

Gemessen habe ich von Polen aus. Bei 344 der 1.000 Domains antwortete die Startseite nicht auf meine Anfragen, zeigte eine Bot-Prüfung oder lieferte einen Fehler. Diese Startseiten fehlen in den Zahlen zu den Seiten und werden nicht als unsicher gezählt. Warum, erklärt der Abschnitt zur Methode.

Die wichtigsten Ergebnisse

• Am 24. September 2026 hatten 499 von 987 beliebten .ae- und .sa-Domains (50,
   %) eine DMARC-Richtlinie, die empfangende Mailserver anweist, gefälschte Mails abzuweisen oder in Quarantäne zu stellen: 234 von 498 in den VAE (47,
   %) und 265 von 489 in Saudi-Arabien (54,
   %).
• In der Messung vom 24. September 2026 sendeten 408 von 652 beliebten Startseiten aus den VAE und Saudi-Arabien, die über HTTPS ausgeliefert werden (62,
   %), einen HSTS-Header, und 280 von 656 (42,
   %) setzten eine Content-Security-Policy durch.
• Im September 2026 akzeptierten 182 von 832 beliebten Domains aus den VAE und Saudi-Arabien (21,
   %) noch TLS-1.0-Verbindungen. Von diesen 182 laufen 101 über Cloudflare, das TLS 1.0 akzeptiert, bis der Inhaber die Mindestversion anhebt.
• Saudische Domains, die DMARC veröffentlichen, wählen meist die strengste Einstellung: 232 von 363 saudischen Einträgen (63,
   %) lauten p=reject, gegenüber 139 von 368 in den VAE (37,
   %).
• Für 256 von 987 Domains (25,
   %) gibt es überhaupt keinen DMARC-Eintrag, und weitere 198 (20,
   %) haben einen mit p=none, der nichts blockiert.
• Eine security.txt-Datei, die Forschern sagt, wohin sie eine Schwachstelle melden können, fand ich auf mindestens 41 von 649 Websites (6,
   %).
• Verglichen mit derselben Messung polnischer Domains senden Startseiten aus den VAE und Saudi-Arabien häufiger HSTS und CSP, während weniger der Domains TLS 1.3 unterstützen. Der Vergleich hat Grenzen, die weiter unten beschrieben sind.

E-Mail-Spoofing: DMARC und SPF

Eine gefälschte E-Mail mit der Adresse Ihres Unternehmens im Absenderfeld genügt, um einem Kunden eine falsche Rechnung zu schicken. Dagegen schützen drei DNS-Einträge: SPF, DKIM und DMARC, die ich in SPF, DKIM und DMARC erklärt beschreibe. Entscheidend ist DMARC: Es sagt dem empfangenden Server, was er mit einer Nachricht tun soll, die angeblich von Ihnen stammt, die Prüfungen aber nicht besteht.

SPF ist verbreitet: 843 von 987 Domains haben es (85,
 %), 426 von 497 in den VAE (85,
 %) und 417 von 490 in Saudi-Arabien (85,
 %). SPF allein prüft allerdings nicht die Adresse, die der Empfänger im Absenderfeld sieht. Das tut nur DMARC.

• VAE (.ae)47,0%234 von 498
• Saudi-Arabien (.sa)54,2%265 von 489
• Polen (.pl), zum Vergleich46,1%460 von 997

Der eigene Eintrag der Domain mit p=quarantine oder p=reject, angewandt auf alle Mails (pct=100 oder ohne pct). Domains mit eindeutiger DNS-Antwort. Polen: dieselbe Messung am selben Tag.

Unter den Domains, die E-Mail empfangen (mit MX-Einträgen), ist der Anteil mit blockierender Richtlinie etwas höher: 216 von 430 in den VAE (50,
 %) und 253 von 426 in Saudi-Arabien (59,
 %). Bei den übrigen hängt es ganz von den Filtern der Empfängerseite ab, ob eine gefälschte Nachricht im Posteingang landet.

p=none ist kein Fehler, sondern der empfohlene erste Schritt: Die Domain sammelt Berichte, und ihr Inhaber sieht, wer in ihrem Namen Mails verschickt. Von den 731 DMARC-Einträgen enthalten 618 (84,
 %) eine Adresse für Sammelberichte (rua). Schutz beginnt aber erst mit quarantine oder reject. Saudische Domains, die DMARC veröffentlichen, gehen meist den ganzen Weg: 232 von 363 Einträgen (63,
 %) lauten p=reject. In den VAE sind die drei Einstellungen gleichmäßiger verteilt: p=none bei 126 von 368 (34,
 %), quarantine bei 103 (28,
 %) und reject bei 139 (37,
 %).

Ein Detail in der saudischen Liste: 26 Domains nutzen quarantine oder reject mit einem pct unter 100, wodurch die Richtlinie nur für diesen Anteil der durchgefallenen Mails gilt.

Kleinere SPF-Fehler: 10 von 843 Einträgen (1,
 %) brauchen mehr als die 10 DNS-Abfragen, die der Standard erlaubt, 11 Domains (1,
 %) veröffentlichen zwei SPF-Einträge statt einem, und eine beendet ihren Eintrag mit +all, womit jeder Server in ihrem Namen Mails verschicken darf.

DKIM werte ich nicht aus. Die Selektoren, unter denen DKIM-Schlüssel veröffentlicht werden, lassen sich über DNS nicht auflisten, „nicht gefunden“ hieße also nur „nicht unter den gängigen Namen“.

Verschlüsselung: HTTPS, HSTS und TLS

HTTPS selbst ist Standard: 652 von 656 analysierten Startseiten (99,
 %) laden von einer https://-Adresse. Die Unterschiede liegen in dem, was dazugehört.

Die Nenner unterscheiden sich, weil jede Zeile nur die Domains zählt, bei denen diese Prüfung eine Antwort bekam. Einzelheiten stehen im Abschnitt zur Methode.

HSTS ist ein Header, der den Browser anweist, für die Domain eine bestimmte Zeit lang nur HTTPS zu verwenden. Ohne ihn beginnt jeder Aufruf einer Adresse, die ohne https:// eingetippt wurde, mit einer unverschlüsselten Verbindung, bevor der Server umleitet, und in einem fremden WLAN kann diese Verbindung abgefangen werden. HSTS senden 408 von 652 HTTPS-Startseiten (62,
 %), 246 (37,
 %) davon mit der empfohlenen Dauer von mindestens einem Jahr.

TLS 1.0 und 1.1 sind alte Versionen des Verschlüsselungsprotokolls. Die Browser haben sie 2020 abgeschaltet, und die IETF hat sie 2021 offiziell für veraltet erklärt (RFC 8996). TLS 1.0 akzeptieren noch 182 von 832 Domains (21,
 %). Ein Besucher mit aktuellem Browser verbindet sich ohnehin über TLS 1.2 oder 1.3, ein Weg zur Übernahme einer Website ist das also nicht. Es bedeutet aber, dass der Server auf Nachfrage veraltete Verschlüsselung akzeptiert, und Prüfer sowie Sicherheitsfragebögen für Lieferanten verlangen, die alten Versionen abzuschalten.

Von diesen 182 Domains laufen 101 (55,
 %) über Cloudflare, das TLS 1.0 standardmäßig akzeptiert und erst damit aufhört, wenn der Inhaber die Mindestversion im Dashboard anhebt: 60 von 92 in den VAE und 41 von 90 in Saudi-Arabien. Die übrigen akzeptieren TLS 1.0 auf eigenen Servern oder bei anderen Anbietern.

TLS 1.3, die aktuelle Version, funktioniert auf 620 von 834 Domains (74,
 %), häufiger in den VAE (350 von 443, 79,
 %) als in Saudi-Arabien (270 von 391, 69,
 %).

CAA ist ein DNS-Eintrag, der die Zertifizierungsstellen auflistet, die für die Domain Zertifikate ausstellen dürfen. Alle anderen müssen dann ablehnen. Ich fand einen für 99 von 994 Domains (10,
 %).

Sicherheits-Header

Sicherheits-Header sind einige Zeilen mit Anweisungen, die der Server zusammen mit der Seite an den Browser schickt. Ich beschreibe sie in Sicherheits-Header für Websites: was sie sind und worum Sie bitten sollten. So oft kommen sie auf den Startseiten vor (HSTS steht im Abschnitt zur Verschlüsselung):

Weitere 12 Startseiten (1,
 %) haben CSP nur im Modus Report-Only, in dem der Browser nichts blockiert.

Der kostenlose Sicherheits-Header-Check (auf Englisch) bewertet sie von A bis F. Jeder Header bekommt eine Note, HSTS und CSP zählen doppelt, die übrigen einfach, und der Durchschnitt ergibt die Gesamtnote. Die Studie hat genau diese Skala verwendet.

• A2,6%17 von 656
• B39,0%256 von 656
• C19,4%127 von 656
• D18,6%122 von 656
• F20,4%134 von 656

Die Skala des kostenlosen Header-Checks von ShieldWave. HSTS und CSP zählen doppelt, die übrigen Header einfach.

Ein F heißt nicht, dass eine Website eine Lücke hat, und ein A garantiert nicht, dass sie keine hat. Header sind eine zweite Verteidigungslinie: Sie begrenzen den Schaden, wenn etwas anderes versagt. Fehlende Header bedeuten meist die Standardkonfiguration eines Servers, die sie nicht hinzufügt. Oft ergänzt sie später ein CDN oder ein Plugin.

Plattformen und veraltete Software

Eine Plattform habe ich auf 267 der 656 Startseiten erkannt. Die übrigen 389 (59,
 %) sind individuell entwickelt oder verraten nicht, worauf sie laufen. Die folgenden Anteile sind deshalb Untergrenzen.

WordPress betreibt 88 von 656 Startseiten (13,
 %): 55 von 346 in den VAE und 33 von 310 in Saudi-Arabien. Danach folgen Drupal (31), Microsoft SharePoint (28), Shopify (27), Sitecore (23) und Magento (15).

Die WordPress-Version ist bei 58 der 88 sichtbar. Das sind kleine Zahlen, deshalb nenne ich nur Anzahlen:

• 30 der 58 sind nicht auf der neuesten Version 7.1.2,
• 25 laufen auf einem Zweig älter als 7.1,
• 18 sind nicht auf der neuesten Version ihres eigenen Zweigs und verpassen damit Sicherheitskorrekturen, die für ihn schon veröffentlicht sind.

Nur 34 von 656 Startseiten nennen ihre PHP-Version in einem Header. Das Folgende beschreibt also diese 34, nicht das ganze Web. Davon laufen 16 auf Zweigen, die keinerlei Korrekturen mehr bekommen (8.1 und älter), 13 bekommen nur noch Sicherheitskorrekturen (8.2 und 8.3), und 5 werden voll unterstützt (8.4 und 8.5).

Ein Servername mit Versionsnummer erscheint in den Headern von 60 von 656 Startseiten (9,
 %), bei 34 dieser 60 ist es Microsoft IIS. Die Version preiszugeben, ist für sich keine Lücke, grenzt aber ein, welche bekannten Fehler in Frage kommen.

Plugins habe ich in dieser Studie nicht geprüft. Läuft Ihre Website mit WordPress, beginnen Sie mit Veraltete WordPress-Plugins: was Sie zuerst aktualisieren und was Sie löschen sollten.

security.txt: wohin man eine Schwachstelle meldet

Die Datei /.well-known/security.txt (RFC 9116) nennt die Adresse, an die ein Sicherheitsforscher eine gefundene Schwachstelle melden kann. Ohne sie geht eine Meldung an eine allgemeine Kontaktadresse oder nirgendwohin.

Eine mit dem Feld Contact: fand ich auf 41 von 649 Websites (6,
 %): 16 von 345 in den VAE (4,
 %) und 25 von 304 in Saudi-Arabien (8,
 %). Das ist eine Untergrenze: Weitere 21 Websites antworteten mit einer Umleitung auf eine security.txt-Datei an einer anderen Adresse, und Umleitungen bin ich nicht gefolgt. Von den 41 Dateien haben 32 das Feld Expires, das der Standard vorschreibt.

Tracker und Consent-Plattformen

Dieser Teil ist beschreibend. Es lief kein JavaScript, ich sehe also nur Werkzeuge, die im HTML der Startseite genannt sind. Ob und wann sie laufen, kann ich nicht sagen: Ein Skript kann auf die Einwilligung des Besuchers warten, und der Google Tag Manager kann Werkzeuge laden, die nicht im Seitencode stehen.

• Google Tag Manager38,6%253 von 656
• Google Analytics36,4%239 von 656
• Meta Pixel9,8%64 von 656
• Microsoft Clarity5,9%39 von 656
• TikTok Pixel3,8%25 von 656
• Snap Pixel3,5%23 von 656
• Hotjar3,0%20 von 656
• X (Twitter) Pixel2,4%16 von 656

In jeder Form: Skript, Installations-Snippet oder bloßer Aufruf. Dass ein Werkzeug im Code steht, zeigt nicht, ob es vor der Einwilligung läuft.

Google Analytics oder Google Tag Manager erscheint im Code von 395 von 656 Startseiten (60,
 %). Der Google Consent Mode mit Standard „verweigert“, bei dem Googles Werkzeuge bis zur Einwilligung ohne Cookies arbeiten, zeigt sich auf 12 von 656 Startseiten (1,
 %).

Eine bekannte Consent-Plattform wie OneTrust, CookieYes oder TrustArc zeigt sich auf 41 von 656 Startseiten (6,
 %). Das heißt nicht, dass die übrigen kein Cookie-Banner haben. Eigene Banner, in eine Plattform eingebaute Banner und über den Google Tag Manager geladene Werkzeuge sind mit dieser Methode unsichtbar. Rückschlüsse auf die Rechtskonformität ziehe ich aus diesen Zahlen deshalb nicht.

Im Vergleich mit Polen

Am selben Tag und mit denselben Prüfungen habe ich die 1.000 beliebtesten .pl-Domains gemessen (Ergebnisse). Die DNS-Zahlen lassen sich gut vergleichen, weil sie in beiden Listen fast jede Domain abdecken. Die Zahlen zu den Startseiten weniger: Die Golf-Listen reichen weiter in das Ranking hinunter (bis Rang 835.367, gegenüber 136.495 für Polen), und 344 der 1.000 Startseiten aus der Golfregion ließen sich von Polen aus nicht analysieren, gegenüber 113 der 1.000 polnischen. Lesen Sie die Zahlen zu den Startseiten als groben Vergleich.

• HSTS, VAE und Saudi-Arabien62,6%408 von 652
• HSTS, Polen46,0%406 von 882
• CSP, VAE und Saudi-Arabien42,7%280 von 656
• CSP, Polen24,5%217 von 887

HSTS bezogen auf Startseiten, die über HTTPS ausgeliefert werden, CSP bezogen auf alle analysierten Startseiten. Beides gemessen am 24. September 2026 mit denselben Prüfungen.

Weniger Startseiten aus den VAE und Saudi-Arabien bekommen beim Header-Check ein F: 134 von 656 (20,
 %), gegenüber 290 von 887 (32,
 %) in Polen. Polen liegt vorn bei TLS 1.3 (833 von 953 Domains, 87,
 %, gegenüber 620 von 834, 74,
 %) und bei CAA-Einträgen (192 von 999, 19,
 %, gegenüber 99 von 994, 10,
 %). Bei DMARC ist der Abstand kleiner: 50,
 % der Domains aus den VAE und Saudi-Arabien und 46,
 % der polnischen blockieren gefälschte Mails.

Was das für Ihr Unternehmen bedeutet

Wenn diese Einstellungen bei einigen der beliebtesten Websites der Region fehlen, werden sie auch auf einer kleineren leicht übersehen. Jede der folgenden Prüfungen dauert eine Minute und braucht keinen Zugang zu Ihrem Server.

1. E-Mail. Führen Sie den SPF-, DKIM- und DMARC-Check (auf Englisch) aus. Haben Sie kein DMARC oder p=none, wechseln Sie schrittweise zu quarantine, wie in SPF, DKIM und DMARC erklärt beschrieben. Das schützt vor falschen Rechnungen, die von Ihrer Domain verschickt werden.
2. Verschlüsselung. Der SSL-Zertifikats-Check (auf Englisch) zeigt das Zertifikat, die HTTPS-Umleitung und die TLS-Versionen. Liegt Ihre Website hinter Cloudflare, ändern Sie die Mindestversion im Dashboard unter SSL/TLS, Edge Certificates, Minimum TLS Version. Stellen Sie TLS 1.2 ein.
3. Header. Der Sicherheits-Header-Check (auf Englisch) zeigt, was fehlt. Sicherheits-Header für Websites enthält eine fertige Vorgabe für Ihren Entwickler: Beginnen Sie mit HSTS mit kurzem max-age und CSP im Modus Report-Only.
4. security.txt. Veröffentlichen Sie /.well-known/security.txt mit den Feldern Contact und Expires. Das sind ein paar Zeilen Text.
5. Software. Aktualisieren Sie CMS und Plugins und entfernen Sie Versionsnummern aus den Server-Headern. Für WordPress siehe Veraltete WordPress-Plugins.
6. Tracker und Einwilligung. Der Check „Cookies vor der Einwilligung“ (auf Englisch) zeigt, ob Ihre Startseite Tracking-Cookies setzt oder Analyse- und Werbewerkzeuge lädt, bevor der Besucher zustimmt.

Die Datenschutzgesetze beider Länder verlangen geeignete technische Maßnahmen zum Schutz personenbezogener Daten: in den VAE Artikel 20 des Bundesgesetzesdekrets Nr. 45 von 2021, in Saudi-Arabien Artikel 19 des Gesetzes zum Schutz personenbezogener Daten. Keines nennt DMARC oder HSTS, aber das sind Einstellungen, die jeder von außen prüfen kann. Was das jeweilige Gesetz von einer Firmenwebsite verlangt, steht in den Artikeln zu den VAE und zu Saudi-Arabien. Wenn Sie Unternehmen in der EU beliefern, fragen deren NIS2-Lieferantenfragebögen nach denselben Einstellungen: siehe NIS2 und Ihre Website.

Methode

Domains. Tranco-Liste L5PV4, erstellt am 23. September 2026 um 22:00 UTC aus 30 Tagen Daten (25. August bis 23. September 2026) von fünf Anbietern: Chrome UX Report, Farsight, Majestic, Cloudflare Radar und Cisco Umbrella. Tranco ist ein für die Forschung erstelltes Ranking, das gegen Manipulation gehärtet ist. Ich habe die ersten 500 Domains mit der Endung .ae und die ersten 500 mit der Endung .sa in Rangfolge genommen, einschließlich Second-Level-Domains wie gov.ae und com.sa. Die Top-Million enthält 744 .ae-Domains, die ausgewählten 500 liegen auf den Rängen 3.319 bis 705.110. Sie enthält 548 .sa-Domains, die ausgewählten 500 liegen auf den Rängen 1.245 bis 835.367. Domains unter den Länderkürzeln in arabischer Schrift sind nicht enthalten. Tranco bewertet Domains, nicht Websites, deshalb enthalten die Listen auch technische Domains (CDNs, Werbe- und Messhosts) ohne Startseite.

Wann und von wo. 24. September 2026: die .sa-Liste von 07:32 bis 07:39 UTC (10:32 bis 10:39 Uhr in Riad) und die .ae-Liste von 07:43 bis 07:47 UTC (11:43 bis 11:47 Uhr in den VAE), über eine einzige Netzwerkverbindung in Polen. DNS-Abfragen gingen an die öffentlichen Resolver 1.1.1.1 und 8.8.8.8. Jede HTTP-Anfrage gab sich als ShieldWaveResearch/1.0 mit einem Link auf shieldwave.io zu erkennen und gab sich nicht als Browser aus.

Was gesendet wurde. Pro Domain nur:

1. DNS-Abfragen: Adressen, MX, TXT (SPF und DMARC), CAA,
2. ein Aufruf der Startseite (https://, oder http://, wenn https nicht antwortete, höchstens 5 Umleitungen),
3. eine einfache http://-Anfrage, um zu sehen, ob sie auf https umleitet,
4. TLS-Handshakes auf Port 443: ein vollständiger Handshake und vier Versionsproben (1.0, 1.1, 1.2 und 1.3),
5. eine Anfrage nach /.well-known/security.txt.

Sonst nichts: keine Suche nach Dateien, Admin-Bereichen oder Backups, keine Formulare, Anmeldungen oder Test-Payloads.

Dieselben Prüfungen wie in den kostenlosen Tools. Die Ergebnisse wurden mit demselben Code berechnet, der die kostenlosen Tools von ShieldWave betreibt (Zertifikat, E-Mail, Header und Cookies), Stand Commit 8db196d. Jeder kann seine eigene Domain mit demselben Maßstab prüfen.

Nenner und Ausschlüsse. Jede Zahl hat ihren eigenen Nenner, weil nicht jede Prüfung von jeder Domain eine Antwort bekommt. Von Polen aus ließen sich 656 der 1.000 Startseiten analysieren: 346 von 500 in den VAE und 310 von 500 in Saudi-Arabien. Von den übrigen gaben 178 Domains überhaupt keine HTTP-Antwort (61 .ae, 117 .sa), 144 antworteten mit einer Bot-Prüfung oder einer Blockade wie einem 403 (84 .ae, 60 .sa), und 22 lieferten einen anderen Fehler (9 .ae, 13 .sa). Die meisten der nicht antwortenden .sa-Domains lösen im DNS auf, lassen aber sowohl die https- als auch die http-Verbindung in einen Timeout laufen. So sieht eine Sperre ausländischen Datenverkehrs aus, die Ursache kann ich aber nicht beweisen. Diese Zahlen beschreiben meinen Messstandort, nicht die Sicherheit der Websites. Die ausgeschlossenen Domains fehlen in den Zahlen zur Startseite (Header, HTML, security.txt, Umleitung) und werden nicht als unsicher gezählt, bleiben aber in den Zahlen zu DNS, E-Mail und TLS, die nicht von der Seite abhängen. DNS-Zahlen zählen nur eindeutige Antworten (für DMARC 987 von 1.000, die E-Mail-Prüfung von 10 .sa-Domains lief wegen langsamer Nameserver in einen Timeout).

Definitionen. Eine DMARC-Richtlinie, die in Quarantäne stellt oder abweist, ist der eigene Eintrag der Domain mit p=quarantine oder p=reject und pct=100 oder ohne pct. Ein von einer übergeordneten Domain geerbter Eintrag zählt nicht. HSTS wird nur auf Startseiten gezählt, die auf HTTPS enden, CSP nur, wenn sie durchgesetzt wird. security.txt zählt, wenn die Antwort ein 200 mit einem Feld Contact: ist. Eine HTML-Seite zählt nie.

Grenzen.

• Nur die Startseite, ein Aufruf, ein Tag. Andere Seiten können andere Header senden.
• Kein JavaScript: Tracker und Consent-Werkzeuge werden aus dem HTML gelesen. Was der Google Tag Manager lädt oder Skripte später speichern, sehe ich nicht.
• Viele Ergebnisse spiegeln die Standardeinstellungen eines CDN oder Hosters wider (TLS 1.0 bei Cloudflare, Header, die am Edge hinzugefügt werden oder nicht).
• Websites, die den Aufruf blockiert haben, fehlen in den Zahlen zur Startseite und können sich von den übrigen unterscheiden.
• security.txt ist eine Untergrenze, weil Umleitungen nicht gefolgt wurde.
• Die Plattformerkennung ist eine Untergrenze (59,
   % der Startseiten nicht erkannt).
• DKIM wird nicht ausgewertet.
• Gemessen von Polen aus: Websites, die je nach Standort des Besuchers variieren, können Besuchern in der Golfregion etwas anderes zeigen.

Wiederholbarkeit und Kontrollen. Die .ae-Liste wurde zusätzlich in einem ersten vollständigen Durchlauf etwa 15 Minuten früher erhoben, den ich nicht veröffentliche, weil ich den Erhebungscode danach korrigiert habe. Zwischen den beiden Durchläufen lag der Median der Abweichung über alle Kennzahlen bei 0,0 Prozentpunkten und das 90. Perzentil bei 0,4. Keine Kennzahl mit einem Nenner von 100 oder mehr bewegte sich um mehr als 1,1 Punkte. Größere Ausschläge, bis 6,3 Punkte, gab es bei Nennern unter 60, weshalb kleine Gruppen in diesem Artikel nur Anzahlen bekommen. Die .sa-Liste wurde einmal erhoben, mit dem korrigierten Code. Unabhängig davon habe ich 36 zufällig gewählte Domains (8 .ae, 8 .sa und 20 .pl) mit anderen Werkzeugen nachgemessen: DMARC und SPF über einen anderen Resolver (9.9.9.9), HSTS und den Server-Header mit curl, TLS 1.0 mit openssl, security.txt mit curl. Alle 216 Vergleiche stimmten überein.

Daten. Die Rohdaten veröffentliche ich nicht, weil sie einzelne Websites benennen. Die aggregierten Zahlen, jeweils mit Zähler, Nenner, Prozentwert und Grundgesamtheit, stehen unter CC BY 4.0 kostenlos zum Download: gulf-2026-09.csv und gulf-2026-09.json (auf Englisch). Sie umfassen beide Länder zusammen. Die Zahlen pro Land in diesem Artikel stammen aus demselben Durchlauf, getrennt gezählt mit demselben Code. Die Messung lässt sich wiederholen: Die Tranco-Liste ist öffentlich, und jede Prüfung läuft in den kostenlosen Tools von ShieldWave.

So zitieren Sie

Kurz: Quelle: ShieldWave, Messung der 500 beliebtesten .ae- und der 500 beliebtesten .sa-Domains, 24. September 2026, https://shieldwave.io/blog/sicherheit-websites-vae-saudi-arabien-2026/

Vollständig: Radosław Fedorczuk (ShieldWave, ENSOMEDIA), „Wie gut sind beliebte Websites in den VAE und Saudi-Arabien geschützt? 1.000 .ae- und .sa-Domains gemessen (September 2026)“, 24. September 2026, https://shieldwave.io/blog/sicherheit-websites-vae-saudi-arabien-2026/. Aggregierte Daten unter CC BY 4.0.

Fragen zur Methode oder zu den Daten: support@shieldwave.io.