← Back to blog

Privacy and security of Lithuanian websites 2026: what 193,522 sites revealed

Atakos vektorius used an automated browser to visit 211,474 .lt domains and analysed the homepages of 193,522 working websites. We looked at three things: does the site track the visitor before consent, does it send the basic security headers, and is it protected by any WAF, CDN or bot protection layer.

Why another study?

In summer 2026, EcomWall and the law firm Constat published the most comprehensive GDPR and ePrivacy compliance study of .lt websites to date: 104,033 sites, with an assessment of consent banners, privacy policies and the legal position. Their finding that 96% of sites show at least one sign of non-compliance, and that tracking before consent was recorded on 53.9% of sites, was widely covered in the Lithuanian media. We recommend reading it.

Our study complements it rather than repeating it:

• A larger sample. 193,522 working websites, almost twice as many.
• An independent measurement with a different method. We count only recognised cookies, so our result is a lower bound (see the methodology). Two different measurements point in the same direction.
• A security angle. Beyond cookies, we analysed security headers, software version disclosure, and what actually stands in front of Lithuanian websites: Cloudflare, F5 BIG-IP, Akamai, or nothing at all.

Methodology and sample

Each domain was visited by an automated Firefox browser from a Lithuanian IP address between 19 April and 20 May 2026. The browser opened the homepage (over https:// first, falling back to http://), waited for the page to load (the load event), and recorded every cookie in the browser (first- and third-party) together with the headers of the first HTML response. Nothing was clicked: no consent, no scrolling. Cookies were cleared before every domain to imitate a first-time visitor.

Cookie classification. We mapped cookie names to categories using the open Open Cookie Database, plus a small supplementary list of common trackers missing from it (for example Amplitude, Omnisend, Microsoft Clarity and Jetpack analytics). We count an analytics or marketing cookie as a “tracker”. Strictly necessary and functional cookies (session, language, basket) are not included in that figure.

1. One in four websites tracks the visitor before consent

The principle in Article 73(4) of Lithuania’s Law on Electronic Communications (Article 5(3) of the ePrivacy Directive) is simple: non-essential cookies may only be set after consent. Even so, 50,470 websites (26.1%) set analytics or marketing cookies on the first visit, before the visitor clicked anything. Including WooCommerce order attribution cookies, which track the traffic source but whose classification is debatable, the share rises to 28.4%.

Analytics cookies were found on 25.7% of websites and marketing (advertising) cookies on 10.3%. At least one cookie of any kind was found on 44.7% of websites.

Most common trackers before consent

Share of websites, % (of 193,522). Scale 0–100%.

• Google Analytics20.0%
• Meta (Facebook) Pixel6.5%
• WooCommerce attribution*5.6%
• Google Ads / DoubleClick4.5%
• Amplitude1.7%
• Omnisend1.3%
• Hotjar1.0%
• Jetpack / WooCommerce analytics0.9%
• PixelYourSite0.6%
• Yandex Metrica0.3%
• TikTok0.2%

* WooCommerce order attribution (sbjs_* cookies) is enabled by default since version 8.5; it is not included in the headline 26.1%. One website can run several trackers.

The consent banner is installed, but the trackers don’t wait for it

This was the most surprising finding. On 9,902 websites (5.1%) we found a consent platform cookie (CookieYes, CookieScript, OneTrust, Complianz, Cookiebot and others), meaning a banner is installed. Yet 59.8% of them had already loaded trackers before the visitor touched the banner. Among websites without such a cookie, the share is 26.7%.

Trackers before consent, by whether a consent platform cookie was found

Share of websites in the group, %. Scale 0–100%.

• Consent platform cookie found59.8%
• Not found26.7%

Some banners only set a cookie after the visitor makes a choice, so “not found” does not mean there is no banner. The gap shows that installing a banner is not enough: trackers have to be blocked until consent.

The likely cause: a banner is added to the site, while the analytics and advertising code stays pasted directly into the page template or into Google Tag Manager without consent conditions. The banner is then just decoration.

2. Tracking that no longer serves anyone

Google stopped processing data for standard Universal Analytics properties on 1 July 2023, and for 360 properties on 1 July 2024. Even so, 10,690 websites (5.5%) still set Universal Analytics cookies in 2026, and 3,162 (1.6%) have no newer GA4 tag at all. Visitor data still goes to Google, but the site owner no longer gets any reports: the privacy cost is paid for no benefit.

3. Parked domains that track on the owner’s behalf

5,698 .lt domains showed not a website but the default page of one large hosting provider. That page loads the provider’s own Google Analytics tag: a visitor arriving at a newly registered or unfinished domain is tracked without any consent, and the domain owner may not even know it. We excluded these domains from the main figures because they are not real websites, but the pattern deserves attention: a domain owner is also responsible for what their “empty” domain shows.

4. Security headers: 7 in 10 websites send none

HTTP security headers are the cheapest protection a website can switch on: a few lines of server configuration help defend against clickjacking, limit the impact of XSS, prevent traffic interception over HTTP and stop data leaking through the Referer. We assessed the six headers recommended by the OWASP Secure Headers project.

How many of the six security headers a website sends

Share of websites, % (of 183,258). Scale 0–100%.

• 0 headers69.3%
• 116.1%
• 25.0%
• 35.5%
• 42.8%
• 50.9%
• All 60.5%

Headers: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy.

Adoption of each header

Share of websites, % (of 183,258). Scale 0–100%.

• Content-Security-Policy18.4%
• X-Content-Type-Options14.4%
• Strict-Transport-Security12.5%
• X-Frame-Options8.1%
• Referrer-Policy4.2%
• Permissions-Policy3.6%

Even where a header is present, it does not always work as intended:

• CSP: on 20.2% of websites with a CSP, the policy consists only of frame-ancestors (which protects against framing, not XSS); 7.5% allow 'unsafe-inline' and 4.3% allow 'unsafe-eval'.
• HSTS: 73.4% set a lifetime of at least a year, 50.1% cover subdomains and 39.7% are ready for the preload list; 1.2% send max-age=0, which effectively switches HSTS off.
• Obsolete headers: 10.2% of websites still send X-XSS-Protection, which modern browsers no longer support, more often than Referrer-Policy and Permissions-Policy combined.

5. Who protects Lithuanian websites?

WAF (web application firewall), CDN, DDoS and bot protection services leave traces. Cloudflare responses carry Server: cloudflare and CF-RAY headers, and its bot protection sets the __cf_bm cookie. F5 BIG-IP usually hides itself in the headers but gives itself away through TS… cookies (for example TS01a2b3c4) and BIGipServer…. Akamai sets _abck and bm_sz, Imperva incap_ses_…, and DataDome the datadome cookie.

Based on the website’s own headers, we saw a dedicated protection layer on only 13.8% of websites (25,377). Counting vendor cookies as well, the share reaches 15.4%. In other words, roughly 85% of .lt websites face the internet without any visible WAF or anti-DDoS layer, and active bot protection (Cloudflare with __cf_bm or cf_clearance) was confirmed on just 1.3% of websites.

Headers come from the website’s own response, so they are the most reliable evidence. Cookies were recorded across the whole browser, so some of them may come from embedded third-party widgets rather than the site’s own protection. Hosting and platform edge networks (Wix, Vercel, Netlify, hosting providers’ CDNs) are not counted as dedicated protection.

Protected websites are better maintained, but track more often

Websites behind a WAF or CDN send almost four times as many security headers (the CDN adds some of them itself). Yet they load trackers before consent more often. More professionally run websites make heavier use of analytics and advertising, and technical maturity does not yet mean privacy maturity.

* Including WooCommerce attribution cookies.

6. What websites give away about themselves

The Server and X-Powered-By headers often state the exact software version. That saves an attacker reconnaissance time: they only need to look up the known vulnerabilities for that version. 10.0% of websites publish an exact server version (for example nginx/1.18.0 (Ubuntu)), 15.0% send an X-Powered-By header, and 10.6% (19,343) reveal their PHP version.

Of those, 44.9% (8,694 websites) run a PHP version that no longer receives security updates, including almost 800 on PHP 5.x, whose support ended more than seven years ago. Note that security support for PHP 8.2 ends on 31 December 2026, so another 6,557 websites will soon join that list.

Disclosed PHP versions

Number of websites (12 most common versions). Scaled to the largest value.

Supported (April 2026)Unsupported (EOL)

• 8.4511
• 8.33,487
• 8.2 (until 2026-12-31)6,557
• 8.1 · EOL2,621
• 8.0 · EOL834
• 7.4 · EOL3,095
• 7.3 · EOL332
• 7.2 · EOL500
• 7.0 · EOL174
• 5.6 · EOL404
• 5.4 · EOL219
• 5.3 · EOL166

Support dates from php.net. We only see websites that disclose their PHP version themselves; the real prevalence of old versions is probably higher.

What a website owner should do

Check your own site in two minutes

1. Open your website in a private (incognito) browser window and do not click the consent banner.
2. Open the developer tools (F12) → Application (Chrome) or Storage (Firefox) → Cookies. If you see _ga, _fbp, _gcl_au or similar cookies, trackers are running without consent.
3. In a terminal, run curl -I https://your-site.lt and check that the response contains the six security headers listed above, and that the Server and X-Powered-By headers do not reveal exact versions.

Privacy

• Load analytics and advertising tags only after consent: block them in your consent platform or with Google Tag Manager rules (Consent Mode). Installing a banner without blocking does not solve the problem.
• Remove Universal Analytics code (UA-…, ga.js, analytics.js): it no longer works, but it still tracks.
• Check what your inactive or parked domains show.
• We described how to run analytics server-side while respecting consent in the article “Cloudflare Zaraz or a Worker for GA4” (in Lithuanian).

Security

• Switch on the six security headers. This starting set suits most websites (adapt the CSP to your site’s resources):

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

• Hide versions: expose_php = Off (PHP), server_tokens off; (nginx), ServerTokens Prod (Apache).
• Upgrade PHP to at least 8.3. If your site runs on 8.2, plan the upgrade this year.
• Put your website behind a WAF or CDN. Even Cloudflare’s free plan gives basic DDoS and bot protection and lets you add security headers without changing the server. We explain how in the article “Cloudflare WAF on the free plan” (in Lithuanian).

Headers and a WAF are the first layer, not the whole defence. Only testing shows whether your website has real vulnerabilities: penetration testing, WAF configuration advice or a free DAST scan (in Lithuanian).

Conclusions

The problem with Lithuanian websites is not sophisticated attacks. It starts with the basics: one in four websites tracks visitors before consent, three in five websites with a consent banner do not wait for it, seven in ten send no security headers at all, and about 85% have no visible WAF or anti-DDoS layer. Almost half of the websites that reveal their PHP version run an unsupported one.

The good news is that most of these problems take hours to fix, not months: a properly configured consent platform, a few lines of server configuration and a free CDN layer. They are the cheapest security and privacy investments a website owner can make.

Sources

1. “Audit: 96% of Lithuanian websites have GDPR or privacy gaps” (EcomWall and Constat study) — LRT, in Lithuanian
2. Open Cookie Database — GitHub
3. OWASP Secure Headers Project
4. “Universal Analytics is going away” — Google Analytics Help
5. Supported Versions — PHP.net
6. Atakos vektorius measurement, 19 April – 20 May 2026 (211,474 .lt domains, Firefox, Lithuanian IP). Aggregate data and the analysis method are available on request.