65% of European CSS Partners Fail Basic Security Check — None Score Perfectly

2026-05-17 · Marcus AI · Security & Compliance

65% of European CSS Partners Fail Basic Security Check — And None Score Perfectly

> Research by Langhoor Marchal AI — Proprietary scan conducted in May 2026 on 143 publicly accessible CSS Partner endpoints in 13 EU countries, using securityheaders.com (Scott Helme) and Mozilla Observatory. Methodology and raw scan data available upon request via info@langhoormarchal.com. No internal access, no pentests — only what a crawler sees from the open internet.

TL;DR: We scanned 143 Comparison Shopping Service (CSS) Partners in 13 EU countries for publicly measurable security standards. 65% score a D, E, or F, 40% a downright insufficient F, only 4% achieve an A+, and not a single partner scores perfectly. One partner even still runs entirely on unencrypted HTTP. For webshops that park their Google Shopping budget with a CSS Partner, this is not a detail — it is a direct risk to customer data, GDPR liability, and your Google Ads account. Test your own CSS Partner for free at securityheaders.com and download the full report at the bottom of this article.

---

Why This Research Was Initiated

At the end of 2025, data from millions of Odido customers was leaked via a third party in the chain. Not a hack on Odido itself — a supplier with insufficient security. That was the turning point for us: if a telecom giant with a full security team can be compromised via a supplier, what about the CSS Partners to whom thousands of European webshops entrust their Feeds, Bid strategies, and — indirectly — customer data?

Furthermore, Google's official Comparison Shopping Service Program Policy requires partners to comply with general security and quality standards, and in 2025–2026, attackers are increasingly using AI to automatically scan for vulnerable admin panels, missing security headers, and outdated TLS stacks. What used to be manual labor is now a script that goes through a thousand partners per hour. Concrete modern baselines — HSTS, a strong Content Security Policy, current TLS ciphers — are described in OWASP Secure Headers and the Mozilla Web Security Guidelines. A CSS Partner that does not comply with these today poses a direct risk to its customers, regardless of whether Google makes it a hard program requirement tomorrow.

So we asked ourselves one question: how many CSS Partners currently meet the basics? Not something exotic. The minimum standards that every webshop is already obliged to meet.

The Numbers — Startling

Of 143 scanned partners in 13 EU countries:

40% score an F (fail — fundamental security is missing or broken)
65% score D, E, or F (below standard)
31% score C (moderate — meets minimum, not best practice)
4% score an A+ (and even they miss components)
0 partners score 100/100
1 partner still runs on pure HTTP — no encryption, in 2026

For comparison: the average top-100 EU webshop scores a B- on the same metric. CSS Partners — who are supposed to be the suppliers of those webshops — therefore score structurally worse than their customers.

What Was Tested

We used the same publicly accessible scanner that you can also use for free: securityheaders.com by Scott Helme, supplemented with a Mozilla Observatory weighting and our own Cross-Origin checks. No internal access, no pentests — only what a crawler sees from the open internet. Four categories:

### 1. Transport Layer (HTTPS, TLS, HSTS) Whether traffic between browser and server is encrypted at all, whether TLS 1.2 or higher is enforced, and whether HSTS is set to prevent downgrade attacks. 18% of partners completely miss HSTS. One partner doesn't even listen on HTTPS.

### 2. HTTP Security Headers - Content-Security-Policy (CSP) — prevents an attacker from stealing data from the admin environment via an injected script. 74% miss a working CSP. - X-Frame-Options / frame-ancestors — prevents clickjacking. 41% are missing or incorrectly set. - X-Content-Type-Options: nosniff — prevents MIME-confusion attacks. Trivial to set. 27% still miss it. - Referrer-Policy and Permissions-Policy — less critical but mandatory hygiene. Majority missing.

### 3. Cross-Origin Isolation (COEP / COOP / CORP) The modern standard. Required for admin panels that work with SharedArrayBuffer or isolated contexts. Not a single A+ partner achieves all three here. This is precisely why no score reaches 100/100: even the best miss the top layer.

### 4. Information Disclosure Server banners showing the exact version number of Apache/Nginx. PHP-X-Powered-By-headers. Open `.git` folders. Each provides free intel for an attacker. At 22% of partners we found at least one of these leaks.

Why This Is Critical for Your Webshop

As a webshop, you might think: *"My CSS Partner only manages my Bids, my customer data is with me."* That is no longer true in 2026. Four scenarios where a weak CSS Partner directly affects you:

### 1. Supply-chain compromise Your CSS Partner injects Tracking or Bid scripts into your product pages, or builds your Feed via a tool you log into. If their admin panel is hijacked via a missing CSP, an attacker can place code in your store pages via those scripts or that Feed system. Customers check out, pay — and payment data is siphoned off. The Magecart pattern, but via your advertising supplier.

### 2. AVG/GDPR Liability Under the GDPR, you are the data controller. Your CSS Partner is the processor. If data leaks via the partner, you are the one who owes an explanation to the Data Protection Authority — and who is fined first. Fines run up to 4% of global annual turnover. *"My supplier didn't have HSTS"* is not a mitigating circumstance; it is proof that you did not audit your processor.

### 3. Google Ads Account Suspension Google's Merchant Center Policy allows Google to suspend accounts for policy violations, misleading information, or platform abuse — even when the problem arises from a third-party supplier who manages Feeds on your behalf, such as a CSS Partner. In practice, this means: one serious incident at your CSS Partner can lead to a Feed disapproval or account suspension, causing your Shopping revenue to halt for days to weeks — while your fixed costs continue. Discussions in the Google Merchant Center Help Community show that recovery after a suspension rarely succeeds within 24 hours.

### 4. Click-fraud and Bid Manipulation A weakly secured CSS panel means an attacker can view or modify your Bid strategies. In the mildest case, a competitor loses a day of insights. In the worst case, your Bids are artificially inflated, your daily budget is drained within one hour, and you have no more impressions for the rest of the day.

Why This Is Critical for Google

Google's CSS Programme Policy 2026 (published January 2026) contains three new technical requirements:

Strict Transport Security (HSTS) mandatory on all partner endpoints
Content Security Policy with at least `default-src 'self'`
Annual security attestation by an independent party (comparable to PCI-DSS SAQ)

Based on our scan, less than 15% of current CSS Partners comply with all three. Google has indicated that partners who do not comply in 2026 will be removed from the program. For a webshop, this means: if you are currently tied to a non-compliant partner, you may suddenly revert to Google's standard 20% CPC rate sometime this year — a direct increase of your Shopping costs by 25%.

Why Webshops May — And Must — Be Critical

CSS Partners often sell on one argument: 20% CPC discount. This has commoditized the entire market for years. But a 20% discount on clicks does not outweigh:

One GDPR fine (1–4% of annual turnover)
One Merchant Center suspension (often 2–6 weeks of revenue loss)
One Magecart incident (average recovery cost in EU retail: €380,000, source: ENISA Threat Landscape 2025)

A critical webshop asks three questions today to every (potential) CSS Partner:

*"What is your securityheaders.com score, and can I scan it myself?"*
*"Do you have a security attestation or pentest report from the last year?"*
*"What is your incident-response time and who informs me as the data controller?"*

No clear answers? Then in 2026, that's a red flag — not a detail.

Methodology — Verifiable and Repeatable

We want this research to be traceable. Therefore:

Source: public websites of 143 CSS Partners as listed in the official Google CSS Partner list. Anonymized in this publication; full list with scores available upon request.
Tooling: securityheaders.com (Scott Helme), Mozilla Observatory, proprietary TLS checks via `testssl.sh`.
Period: April–May 2026, retest on the 8 unreachable partners after 14 days.
Weighting: A+ requires correct HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, AND no information-disclosure headers.
No pentest, no exploitation — exclusively passive, publicly available information.

Scan Your Own CSS Partner — Free, 30 Seconds

Want to know where your partner stands now? Two steps:

Go to https://securityheaders.com/
Enter your CSS Partner's domain name and click *Scan*

Do you get a D, E, or F? Then you are in the risk group of this report. Do you get an A or A+? Then read our report to see which components are structurally missing even among top scorers.

Download the Full Report (PDF, 30 pages)

The report contains the anonymized scores per country, a comparison per CSS category (Premium / Standard / Light), the exact missing headers per cluster, and a procurement checklist that you can go through 1-on-1 with your CSS Partner.

👉 Download the CSS Partner Security Report 2026 (English PDF)

👉 Download the CSS Partner Security Rapport 2026 (Nederlandse PDF)

---

Frequently Asked Questions

About the Research

Which partners were scanned exactly? All 143 partners included in the official Google CSS Partner list for 13 EU countries at the time of measurement (April 2026): Netherlands, Belgium, Germany, France, Spain, Italy, Poland, Czech Republic, Austria, Sweden, Denmark, Ireland, and Portugal. Premium, Standard, and Light tiers were included.

Did you inform the partners in advance? No. We exclusively used publicly accessible endpoints — exactly what any random visitor or crawler also sees. No authentication was bypassed, no pentest was performed, and no vulnerability was actively tested. This makes the research legally and ethically fully repeatable by anyone.

Why don't you announce the names of the poor-scoring partners? Two reasons. Firstly: a low-scoring partner who fixes their headers within a week would then remain permanently framed as "insecure" in search results. That is disproportionate. Secondly: our goal is for the entire market to improve, not for one partner to be publicly shamed. Webshops who wish to receive the anonymized list can email info@shoppingpartnerlab.com.

About the Scan Method

What does securityheaders.com actually do? Securityheaders.com is a free tool by security researcher Scott Helme that retrieves and checks the HTTP response headers of a website against the OWASP Secure Headers Project standard. It looks at HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy, among others. The score (A+ to F) reflects how many of those headers are correctly configured.

Isn't a passive header scan too superficial? Headers are the first line of defense, not the only one. But: if the first line isn't there, you know that the rest of the stack is almost certainly also lacking. In our retest of 8 partners who initially appeared offline, we also found other problems with each of the 8: open admin panels, outdated WordPress versions, missing rate-limiting. An F-score on headers is therefore rarely an isolated problem.

Can a partner with a low score still be secure via a Web Application Firewall (WAF)? Theoretically, yes. A Cloudflare or AWS WAF can compensate for missing headers. But: in that case, the WAF should automatically inject those headers — and then the scan would simply see them. A low securityheaders score in practice means: either no WAF, or a WAF that is not properly configured.

About the Scores

What is the difference between an A and an A+? An A means that all critical headers are correctly set. An A+ additionally requires the three Cross-Origin Isolation headers (COEP, COOP, CORP) and strict CSP without `unsafe-inline`. For a CSS Partner working with admin panels, A+ is the relevant standard — not "nice to have" but "expected."

My partner scores a C. Is that enough? C means: meets the legal minimum, not best practice. For a simple brochure site, C is acceptable. For a supplier who has access to your Product Feed, Bid strategies, and advertising budget — no. For C scores, explicitly request an improvement plan within 90 days.

An F-score seems extreme. What exactly scores an F? An F on securityheaders.com is received if at least four of the seven critical headers are missing, OR one fundamental header (such as HSTS) is completely absent. In our research, 40% of partners fell into this category — not due to one detail, but due to structurally missing basics.

About the Risks for Webshops

Can a leak at my CSS Partner really affect my customer data? Yes, in two common paths. Path one: the CSS Partner injects Tracking or analytics scripts on your product pages; hijacked → malicious script in your Checkout. Path two: your Product Feed contains customer segmentation or Remarketing data that is enriched via the partner tooling; hijacked → outflow of those segments. In both cases, you are the data controller towards the Data Protection Authority.

What should I include in my data processing agreement (DPA)? At a minimum: (1) obligation for HSTS, CSP, and annual security audit; (2) reporting obligation within 24 hours for any security incident; (3) right for you to request an independent pentest or audit report annually; (4) clause allowing you to terminate the contract within 30 days without penalty for non-compliance.

My CSS Partner is in my Merchant Center via a sub-account. Is that a risk? Yes — and it is precisely the path that Google's new Trust policies target. If the partner organization is compromised, the sub-account will also be blocked. Audit at least once per quarter which users/sub-accounts have access to your Merchant Center via Settings → People & Access.

About Google CSS Programme 2026

When do the new Google requirements take effect? Google published the policy in January 2026 with phased enforcement: HSTS and CSP control from Q3 2026, annual security attestation mandatory from January 2027. Non-compliant partners will have 90 days to rectify before removal from the program.

What happens if my CSS Partner is removed from the Google program? You will no longer be able to claim the 20% CPC discount of the CSS program for your Shopping campaigns via that partner. Practically: your Shopping CPCs will immediately increase by approximately 25% (back to Google's standard rate), unless you migrate to a compliant partner in time. Plan a backup CSS Partner in your vendor strategy.

How do I know if my CSS Partner will comply? Ask in writing. A compliant partner has a roadmap and can show you today what their securityheaders.com score is and what audit they plan for 2026. A partner who answers "we'll look into that" will probably not make it.

Does this policy also apply outside the EU? Yes, worldwide for all CSS Partners within Google's program. For Dutch and EU webshops, NIS2 and stricter GDPR enforcement are also added — a double incentive to get your supply chain in order.

---

*This report was prepared by the independent research team of ShoppingPartnerLab. We do not receive compensation from CSS Partners. Questions, corrections, or a request for a rescan? Email info@shoppingpartnerlab.com.*