How well protected are popular UAE and Saudi websites? 1,000 .ae and .sa domains measured (September 2026)

I took the first 500 domains ending in .ae and the first 500 ending in .sa in the Tranco ranking, a list built for research, and on the morning of 24 September 2026 checked them from the outside, the way any visitor or mail server sees them. The measurement was passive: DNS queries, one visit to each homepage and a few TLS connections per domain, with no vulnerability scanning and no login attempts. The results were counted by the same checks that run in ShieldWave's free tools. I do not name any of the domains.

I measured from Poland. For 344 of the 1,000 domains the homepage gave no answer to my requests, showed a bot check or returned an error. Those homepages are left out of the page figures and are not counted as insecure; the method section explains why.

Key findings

• On 24 September 2026, 499 of 987 popular .ae and .sa domains (50.6%) had a DMARC policy telling receiving mail servers to reject or quarantine forged mail: 234 of 498 in the UAE (47.0%) and 265 of 489 in Saudi Arabia (54.2%).
• In the measurement of 24 September 2026, 408 of 652 popular UAE and Saudi homepages served over HTTPS (62.6%) sent an HSTS header, and 280 of 656 (42.7%) enforced a Content-Security-Policy.
• In September 2026, 182 of 832 popular UAE and Saudi domains (21.9%) still accepted TLS 1.0 connections. Of those 182, 101 are served through Cloudflare, which accepts TLS 1.0 until the owner raises the minimum version.
• Saudi domains that publish DMARC mostly choose its strictest setting: 232 of 363 Saudi records (63.9%) say p=reject, against 139 of 368 in the UAE (37.8%).
• There is no DMARC record at all for 256 of 987 domains (25.9%), and another 198 (20.1%) have one set to p=none, which blocks nothing.
• I found a security.txt file, which tells researchers where to report a vulnerability, on at least 41 of 649 sites (6.3%).
• Compared with the same measurement of Polish domains, UAE and Saudi homepages send HSTS and CSP more often, while fewer of the domains support TLS 1.3. The comparison has limits, described below.

E-mail spoofing: DMARC and SPF

A forged e-mail with your company's address in the From field is all it takes to send a customer a fake invoice. Three DNS records protect against it: SPF, DKIM and DMARC, which I explain in SPF, DKIM and DMARC explained (in Arabic: fake invoices from your company's e-mail). DMARC is the one that decides: it tells the receiving server what to do with a message that claims to be yours but fails the checks.

SPF is common: 843 of 987 domains have it (85.4%), 426 of 497 in the UAE (85.7%) and 417 of 490 in Saudi Arabia (85.1%). SPF alone does not check the address the recipient sees in the From field, though. Only DMARC does.

• UAE (.ae)47.0%234 of 498
• Saudi Arabia (.sa)54.2%265 of 489
• Poland (.pl), for comparison46.1%460 of 997

The domain's own record with p=quarantine or p=reject, applied to all mail (pct=100 or no pct). Domains with a definitive DNS answer. Poland: the same measurement on the same day.

Among domains that receive mail (with MX records), the share with a blocking policy is a little higher: 216 of 430 in the UAE (50.2%) and 253 of 426 in Saudi Arabia (59.4%). For the rest, whether a forged message reaches the inbox is left entirely to the receiving side's own filters.

p=none is not a mistake but the recommended first step: the domain collects reports, and its owner sees who sends mail in its name. Of the 731 DMARC records, 618 (84.5%) include an address for aggregate reports (rua). Protection only starts with quarantine or reject, though. Saudi domains that publish DMARC mostly go all the way: 232 of 363 records (63.9%) say p=reject. In the UAE the three settings are closer to even: p=none on 126 of 368 (34.2%), quarantine on 103 (28.0%) and reject on 139 (37.8%).

One detail in the Saudi list: 26 domains use quarantine or reject with a pct below 100, which applies the policy to only that share of the failing mail.

Smaller SPF faults: 10 of 843 records (1.2%) need more than the 10 DNS lookups the standard allows, 11 domains (1.3%) publish two SPF records instead of one, and one ends its record in +all, which lets any server send mail in its name.

I do not report DKIM. The selectors under which DKIM keys are published cannot be listed through DNS, so "not found" would only mean "not under the common names".

Encryption: HTTPS, HSTS and TLS

HTTPS itself is standard: 652 of 656 analysed homepages (99.4%) load from an https:// address. The differences are in what goes with it.

The denominators differ because each row counts only the domains where that check got an answer. The method section has the details.

HSTS is a header that tells the browser to use only HTTPS for the domain for a set time. Without it, every visit to an address typed without https:// starts with an unencrypted connection before the server redirects it, and on someone else's Wi-Fi that connection can be intercepted. HSTS is sent by 408 of 652 HTTPS homepages (62.6%), and by 246 (37.7%) with the recommended period of at least a year.

TLS 1.0 and 1.1 are old versions of the encryption protocol. Browsers switched them off in 2020, and the IETF formally deprecated them in 2021 (RFC 8996). TLS 1.0 is still accepted by 182 of 832 domains (21.9%). A visitor with a current browser connects over TLS 1.2 or 1.3 anyway, so this is not a way to take over a site. It does mean the server agrees to outdated encryption when asked, and auditors and supplier security questionnaires ask for the old versions to be switched off.

Of those 182 domains, 101 (55.5%) are served through Cloudflare, which accepts TLS 1.0 by default and stops only when the owner raises the minimum version in the dashboard: 60 of 92 in the UAE and 41 of 90 in Saudi Arabia. The others accept TLS 1.0 on their own servers or with other providers.

TLS 1.3, the current version, works on 620 of 834 domains (74.3%), more often in the UAE (350 of 443, 79.0%) than in Saudi Arabia (270 of 391, 69.1%).

CAA is a DNS record listing the certificate authorities that may issue certificates for the domain; the others must then refuse. I found one for 99 of 994 domains (10.0%).

Security headers

Security headers are a few lines of instructions the server sends the browser with the page. I describe them in Website security headers: what they are and what to ask for. This is how often they appear on the homepages (HSTS is in the encryption section):

Another 12 homepages (1.8%) have CSP only in Report-Only mode, in which the browser blocks nothing.

The free security headers check grades them from A to F. Each header gets a letter, HSTS and CSP count twice, the others once, and the average gives the final grade. The study used exactly that scale.

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

The scale of the ShieldWave free headers check. HSTS and CSP count twice, the other headers once.

An F does not mean a site has a hole, and an A does not guarantee it has none. Headers are a second line of defence: they limit the damage when something else fails. Missing headers usually mean a server's default setup, which does not add them. Often a CDN or a plugin adds them later.

Platforms and outdated software

I recognised a platform on 267 of the 656 homepages. The other 389 (59.3%) are custom-built or do not reveal what they run on, so the shares below are lower bounds.

WordPress runs 88 of 656 homepages (13.4%): 55 of 346 in the UAE and 33 of 310 in Saudi Arabia. Next come Drupal (31), Microsoft SharePoint (28), Shopify (27), Sitecore (23) and Magento (15).

The WordPress version is visible on 58 of the 88. These are small numbers, so I give counts only:

• 30 of the 58 are not on the latest release, 7.1.2,
• 25 are on a branch older than 7.1,
• 18 are not on the latest release of their own branch, so they miss security fixes already published for it.

Only 34 of 656 homepages state their PHP version in a header, so this describes those 34, not the whole web. Of those, 16 run branches that no longer get any fixes (8.1 and older), 13 get security fixes only (8.2 and 8.3), and 5 are fully supported (8.4 and 8.5).

A server name with a version number shows in the headers of 60 of 656 homepages (9.1%); in 34 of those 60 it is Microsoft IIS. Disclosing the version is not a hole in itself, but it narrows down which known bugs apply.

I did not check plugins in this study. If your site runs on WordPress, start with Outdated WordPress plugins: what to update first and what to delete.

security.txt: where to report a vulnerability

The file /.well-known/security.txt (RFC 9116) gives the address where a security researcher can report a vulnerability they found. Without it, a report goes to a general contact address, or nowhere.

I found one with a Contact: field on 41 of 649 sites (6.3%): 16 of 345 in the UAE (4.6%) and 25 of 304 in Saudi Arabia (8.2%). That is a lower bound: another 21 sites answered with a redirect to a security.txt file at another address, and I did not follow redirects. Of the 41 files, 32 have the Expires field the standard requires.

Trackers and consent platforms

This part is descriptive. No JavaScript ran, so I only see tools named in the homepage's HTML. Whether and when they run I cannot tell: a script may wait for the visitor's consent, and Google Tag Manager can load tools that are not in the page code.

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

In any form: script, install snippet or a bare call. Being in the code does not show whether the tool runs before consent.

Google Analytics or Google Tag Manager appears in the code of 395 of 656 homepages (60.2%). Google Consent Mode with default denied, in which Google's tools work without cookies until consent is given, shows on 12 of 656 homepages (1.8%).

A known consent platform, such as OneTrust, CookieYes or TrustArc, shows on 41 of 656 homepages (6.3%). That does not mean the rest have no consent banner. Custom banners, banners built into a platform and tools loaded through Google Tag Manager are invisible to this method, so I draw no conclusions about legal compliance from these numbers.

Compared with Poland

On the same day and with the same checks I measured the 1,000 most popular .pl domains (results). The DNS figures compare well, because in both lists they cover almost every domain. The homepage figures less so: the Gulf lists reach further down the ranking (to rank 835,367, against 136,495 for Poland), and 344 of the 1,000 Gulf homepages could not be analysed from Poland, against 113 of the 1,000 Polish ones. Read the homepage figures as a rough comparison.

• HSTS, UAE and Saudi Arabia62.6%408 of 652
• HSTS, Poland46.0%406 of 882
• CSP, UAE and Saudi Arabia42.7%280 of 656
• CSP, Poland24.5%217 of 887

HSTS over homepages served over HTTPS, CSP over all analysed homepages. Both measured on 24 September 2026 with the same checks.

Fewer UAE and Saudi homepages also get an F from the headers check: 134 of 656 (20.4%), against 290 of 887 (32.7%) in Poland. Poland is ahead on TLS 1.3 (833 of 953 domains, 87.4%, against 620 of 834, 74.3%) and on CAA records (192 of 999, 19.2%, against 99 of 994, 10.0%). On DMARC the gap is smaller: 50.6% of the UAE and Saudi domains and 46.1% of the Polish ones block spoofed mail.

What this means for your company

If these settings are missing on some of the most popular sites in the region, they are easy to miss on a smaller one too. Each check below takes a minute and needs no access to your server.

1. E-mail. Run the SPF, DKIM and DMARC check. If you have no DMARC or p=none, move to quarantine step by step as described in SPF, DKIM and DMARC explained. It protects against fake invoices sent from your domain.
2. Encryption. The SSL certificate check shows the certificate, the HTTPS redirect and the TLS versions. If your site is behind Cloudflare, change the minimum in the dashboard under SSL/TLS, Edge Certificates, Minimum TLS Version. Set TLS 1.2.
3. Headers. The security headers check shows what is missing. Website security headers has a brief ready for your developer: start with HSTS with a short max-age and CSP in Report-Only mode.
4. security.txt. Publish /.well-known/security.txt with Contact and Expires fields. It is a few lines of text.
5. Software. Update the CMS and plugins, and remove version numbers from server headers. For WordPress, see Outdated WordPress plugins.
6. Trackers and consent. The cookies before consent check shows whether your homepage sets tracking cookies or loads analytics and advertising tools before the visitor agrees.

The data protection laws of both countries ask for appropriate technical measures to protect personal data: in the UAE, Article 20 of Federal Decree-Law No. 45 of 2021; in Saudi Arabia, Article 19 of the Personal Data Protection Law. Neither names DMARC or HSTS, but these are settings anyone can check from the outside. What each law asks of a company website is explained in Arabic for the UAE and for Saudi Arabia. If you supply companies in the EU, their NIS2 supplier questionnaires ask about the same settings: see NIS2 and your website.

Method

Domains. Tranco list L5PV4, generated on 23 September 2026 at 22:00 UTC from 30 days of data (25 August to 23 September 2026) from five providers: Chrome UX Report, Farsight, Majestic, Cloudflare Radar and Cisco Umbrella. Tranco is a ranking built for research and hardened against manipulation. I took the first 500 domains ending in .ae and the first 500 ending in .sa in rank order, second-level domains such as gov.ae and com.sa included. The top million holds 744 .ae domains, and the chosen 500 rank from 3,319 to 705,110; it holds 548 .sa domains, and the chosen 500 rank from 1,245 to 835,367. Domains under the Arabic-script country codes are not included. Tranco ranks domains, not websites, so the lists also hold technical domains (CDNs, ad and measurement hosts) without a homepage.

When and from where. 24 September 2026: the .sa list from 07:32 to 07:39 UTC (10:32 to 10:39 in Riyadh) and the .ae list from 07:43 to 07:47 UTC (11:43 to 11:47 in the UAE), from one network connection in Poland. DNS queries went to the public resolvers 1.1.1.1 and 8.8.8.8. Every HTTP request identified itself as ShieldWaveResearch/1.0 with a link to shieldwave.io; it did not pretend to be a browser.

What was sent. Per domain, only:

1. DNS queries: addresses, MX, TXT (SPF and DMARC), CAA,
2. one visit to the homepage (https://, or http:// when https did not answer; at most 5 redirects),
3. one plain http:// request to see whether it redirects to https,
4. TLS handshakes on port 443: one full handshake and four version probes (1.0, 1.1, 1.2 and 1.3),
5. one request for /.well-known/security.txt.

Nothing else: no probing for files, admin panels or backups, and no forms, logins or test payloads.

Same checks as the free tools. The results were computed by the same code that runs ShieldWave's free tools (certificate, e-mail, headers and cookies), as of commit 8db196d. Anyone can check their own domain by the same measure.

Denominators and exclusions. Each figure has its own denominator, because not every check gets an answer from every domain. From Poland, 656 of the 1,000 homepages could be analysed: 346 of 500 in the UAE and 310 of 500 in Saudi Arabia. Of the rest, 178 domains gave no HTTP answer at all (61 .ae, 117 .sa), 144 answered with a bot check or a block such as a 403 (84 .ae, 60 .sa), and 22 returned another error (9 .ae, 13 .sa). Most of the unanswered .sa domains resolve in DNS but let both the https and the http connection time out, which is what blocking of foreign traffic looks like, although I cannot prove the cause. These numbers describe my vantage point, not the sites' security. The excluded domains are left out of the homepage figures (headers, HTML, security.txt, redirect) and are not counted as insecure, but they stay in the DNS, e-mail and TLS figures, which do not depend on the page. DNS figures count only definitive answers (for DMARC, 987 of 1,000; the e-mail check of 10 .sa domains timed out on slow name servers).

Definitions. A DMARC policy that quarantines or rejects is the domain's own record with p=quarantine or p=reject and pct=100 or no pct. A record inherited from a parent domain does not count. HSTS is counted only on homepages that end on HTTPS, and CSP only when enforced. security.txt counts when the answer is a 200 with a Contact: field; an HTML page never counts.

Limitations.

• Homepage only, one visit, one day. Other pages may send other headers.
• No JavaScript: trackers and consent tools are read from the HTML. I cannot see what Google Tag Manager loads or what scripts store later.
• Many results reflect a CDN's or host's defaults (TLS 1.0 on Cloudflare, headers added or not at the edge).
• Sites that blocked the visit are missing from the homepage figures, and they may differ from the ones that remain.
• security.txt is a lower bound, because redirects were not followed.
• Platform detection is a lower bound (59.3% of homepages unrecognised).
• DKIM is not reported.
• Measured from Poland: sites that vary by visitor location may show visitors in the Gulf something else.

Repeatability and checks. The .ae list was also collected in a first full run about 15 minutes earlier, which I do not publish because I corrected the collection code after it. Between the two runs the median difference across the metrics was 0.0 percentage points and the 90th percentile 0.4; no metric with a denominator of 100 or more moved by more than 1.1 points. Larger moves, up to 6.3 points, were on denominators under 60, which is why small groups get counts only in this article. The .sa list was collected once, with the corrected code. Separately, I re-measured 36 randomly chosen domains (8 .ae, 8 .sa and 20 .pl) with other tools: DMARC and SPF through a different resolver (9.9.9.9), HSTS and the Server header with curl, TLS 1.0 with openssl, security.txt with curl. All 216 comparisons agreed.

Data. I do not publish the raw data, because it names individual sites. The aggregate figures, each with numerator, denominator, percentage and population, are free to download under CC BY 4.0: gulf-2026-09.csv and gulf-2026-09.json. They cover both countries together; the per-country figures in this article come from the same run, counted separately with the same code. The measurement can be repeated: the Tranco list is public, and every check runs in ShieldWave's free tools.

How to cite

Short: Source: ShieldWave, measurement of the 500 most popular .ae and 500 most popular .sa domains, 24 September 2026, https://shieldwave.io/blog/uae-saudi-websites-security-2026/

Full: Radosław Fedorczuk (ShieldWave, ENSOMEDIA), "How well protected are popular UAE and Saudi websites? 1,000 .ae and .sa domains measured (September 2026)", 24 September 2026, https://shieldwave.io/blog/uae-saudi-websites-security-2026/. Aggregate data under CC BY 4.0.

Questions about the method or the data: support@shieldwave.io.