Legal & GDPR

GDPR and Spam Filters: Do You Need Cookie Consent for Security?

1月 16, 2026 · 13 min read

A German regional court fined a small business 100 EUR in January 2022 for loading Google Fonts from Google’s servers without consent. Not for tracking users. Not for selling data. For making a font request that transmitted an IP address to a third-party server in the United States.

If a font file can trigger a GDPR violation, what about your spam filter?

Most WordPress anti-spam solutions — reCAPTCHA, Akismet, hCaptcha — send user data to external servers on every single page load. IP addresses, browser fingerprints, behavioral signals, cookies. All of it transmitted before the visitor has touched a single form field. All of it processed by a third-party company, often in a jurisdiction that the CJEU has already ruled provides inadequate data protection.

This is not a theoretical risk. The Austrian, French, and Italian data protection authorities have all issued rulings against Google Analytics and related services for exactly this type of cross-border data transfer. The same legal reasoning applies to any service that transmits personal data to US-based processors without a valid transfer mechanism.

If you run a website that serves European visitors, your GDPR spam filter configuration is a compliance question — not just a technical one.

The Problem: Spam Filters That Double as Trackers

Here is the uncomfortable reality most site administrators never examine: the anti-spam tool protecting your contact form is probably collecting more data than your marketing stack.

What reCAPTCHA Actually Does

Google’s reCAPTCHA is the most widely deployed spam filter on the web. It is also, functionally, a surveillance tool. When you embed reCAPTCHA on a page, the following happens before the user interacts with anything:

A cookie (_GRECAPTCHA) is set in the user’s browser.
A JavaScript payload is loaded from google.com, transferring the user’s IP address to Google’s servers.
The script collects browser fingerprinting data: screen resolution, installed plugins, language settings, timezone.
It tracks mouse movements, scroll behavior, and keystroke patterns across the entire page — not just within the form.
On subsequent page loads, it reads the cookie to correlate the user’s behavior across multiple sessions.

Google’s own privacy policy confirms that data collected through reCAPTCHA is used for “providing, maintaining, and improving reCAPTCHA” and for “general security purposes.” It does not guarantee that the data is not used for other purposes, and it does not provide a mechanism for sites to restrict downstream processing.

Under the GDPR (and the ePrivacy Directive, which governs cookie placement specifically), every piece of data processing needs a legal basis. The six legal bases are defined in Article 6(1), but for cookie-setting operations on websites, the practical question comes down to two options:

Consent (Article 6(1)(a)) — The user explicitly agrees before any data is processed.
Legitimate interest (Article 6(1)(f)) — The data controller has a legitimate reason, balanced against the user’s rights.

There is also a narrow exemption in the ePrivacy Directive (Article 5(3)) for cookies that are “strictly necessary” to provide a service the user has explicitly requested. This exemption does not require consent.

The critical question for spam filters is: which category do they fall into?

Technical Deep Dive: “Strictly Necessary” vs. Everything Else

This is where most guidance on the internet gets it wrong. You will find dozens of blog posts claiming that “security cookies are strictly necessary and don’t need consent.” That statement is an oversimplification that can get you fined.

What “Strictly Necessary” Actually Means

The Article 29 Working Party (now the EDPB) provided specific guidance on the “strictly necessary” exemption in their Opinion 04/2012. A cookie or data processing operation is strictly necessary only if:

It is essential for a functionality that the user has explicitly requested.
The service cannot be provided without it.
It is limited to what is necessary for that specific purpose.

A CSRF token on a form submission? Strictly necessary. The form cannot function securely without it. No consent required.

A session cookie that maintains login state? Strictly necessary. The user asked to log in; the cookie is the mechanism that makes that work.

But a third-party script that loads on every page, sets persistent cookies, transmits behavioral data to an external server, and performs analysis that extends well beyond the immediate interaction? That is not strictly necessary. Not under any reasonable interpretation of the guidance.

The Three-Part Test

When evaluating whether your GDPR spam filter qualifies for the strictly necessary exemption, apply these three questions:

1. Is the processing limited to the specific interaction?

A spam filter that validates a form submission at the moment of submission — and discards all data afterward — has a strong argument for being strictly necessary. A filter that loads tracking scripts on every page the user visits, regardless of whether they interact with a form, does not.

2. Does the data stay within the controller’s infrastructure?

If the processing happens entirely on your server, you are the data controller, and you control the processing. If the data is sent to a third-party server — especially one outside the EEA — you have introduced a data transfer that requires its own legal basis, its own Data Processing Agreement, and potentially a Transfer Impact Assessment under Schrems II.

3. Could the same result be achieved with less data?

This is the data minimization principle (Article 5(1)(c)). If a spam filter can achieve equivalent protection without cookies, without behavioral tracking, and without third-party data transfers, then the version that collects more data is not “necessary” by definition. The less invasive alternative exists. The GDPR expects you to use it.

A Practical Comparison

Criteria	reCAPTCHA v3	Server-Side Honeypot
Sets cookies	Yes (`_GRECAPTCHA`, plus Google cookies)	No
Loads third-party scripts	Yes (google.com)	No
Transfers data to third party	Yes (to Google, US-based)	No
Tracks behavior across pages	Yes	No
Processes data beyond the form interaction	Yes	No
Requires consent under ePrivacy Directive	Yes	No
Requires DPA with third party	Yes	No
Requires Transfer Impact Assessment (Schrems II)	Yes	No

The compliance burden is not even close.

The Legal Landscape: What Has Actually Been Enforced

This is not speculative. Data protection authorities across Europe have been actively enforcing these principles.

Austria: Google Analytics Ruling (January 2022)

The Austrian DSB (Datenschutzbehorde) ruled that the use of Google Analytics violated GDPR because it transferred personal data (including IP addresses and cookie identifiers) to Google’s US-based servers. The ruling followed the Schrems II decision, which invalidated the EU-US Privacy Shield.

The reasoning applies directly to reCAPTCHA. Both services are operated by Google. Both transfer personal data to Google’s US infrastructure. Both process data through Google’s infrastructure in ways that the site operator cannot fully control or audit.

France: CNIL Decisions on Google Analytics (February 2022)

The CNIL issued multiple decisions finding that Google Analytics transfers violated GDPR. The CNIL specifically noted that Google’s supplementary measures (including encryption and contractual clauses) were insufficient because Google, as a US company, is subject to FISA Section 702 surveillance orders — and therefore cannot guarantee that European personal data will not be accessed by US intelligence agencies.

The Bavarian DPA has consistently taken the position that any cookie or tracker that is not strictly necessary requires prior, informed, explicit consent — and that “consent” obtained through dark patterns (pre-checked boxes, confusing UI, “legitimate interest” claims for tracking) is not valid consent.

The EU-US Data Privacy Framework (2023)

The adoption of the EU-US Data Privacy Framework in July 2023 provided a new adequacy decision for certified US companies. Google is certified. However, legal scholars and privacy advocates — including noyb, the organization behind the original Schrems cases — have challenged this framework. A Schrems III challenge is widely anticipated.

Building your compliance strategy on a transfer mechanism that may be invalidated is a risk. Building it on a solution that never transfers data in the first place eliminates the risk entirely.

Why European Site Operators Are Moving Away from Third-Party Spam Filters

The trend is measurable. Since the Schrems II ruling in July 2020, there has been a significant increase in demand for privacy-first, self-hosted alternatives to US-based SaaS tools across every category — analytics, fonts, spam filtering, CDN services.

The drivers are straightforward:

1. Compliance Cost

Using reCAPTCHA in a GDPR-compliant manner requires:

A Consent Management Platform (CMP) that blocks the reCAPTCHA script until consent is obtained.
A Data Processing Agreement (DPA) with Google (which is available but buries the site operator with obligations).
A Records of Processing Activities (ROPA) entry documenting the processing.
A Transfer Impact Assessment evaluating the risk of US government access.
An update to your Privacy Policy disclosing the processing, the data transferred, and the legal basis.
A mechanism for users to withdraw consent and have their data deleted — which is effectively impossible once the data reaches Google’s infrastructure.

For a server-side solution that processes no personal data and sets no cookies? None of the above applies. The compliance cost is zero.

There is a fundamental UX problem with requiring consent for spam protection. If you block reCAPTCHA until the user consents, the user can submit the form without any spam protection. Your anti-spam measure only works for users who click “Accept” on the cookie banner.

Bots, of course, do not click “Accept.” They submit forms programmatically, bypassing the consent layer entirely.

The result: The only users who are “protected” by reCAPTCHA are the ones who consented to being tracked. The users who declined consent (and the bots) submit unprotected. The spam filter protects exactly the wrong population.

This is not just a technical problem. It is an architectural contradiction. Consent-dependent security is an oxymoron.

3. Liability Exposure

Under GDPR, the data controller (you, the site operator) is liable for the processing — not the data processor (Google, Akismet, etc.). If a DPA determines that your use of reCAPTCHA violates Article 44 (international transfers), the fine lands on you. Not on Google.

Maximum GDPR fines are 4% of annual global turnover or 20 million EUR, whichever is higher. Even if your organization is small, the compliance risk is disproportionate to the value provided by a third-party spam filter.

The path forward is architecturally simple, even if it requires rethinking assumptions about how spam filtering “should” work.

A GDPR spam filter that avoids all of the above issues needs to meet four criteria:

1. No Cookies

If no cookies are set, the ePrivacy Directive’s consent requirement does not apply. The entire CMP integration, the cookie banner, the consent logic — all of it becomes irrelevant for your spam protection layer.

2. No Third-Party Data Transfers

If all processing happens on your own server, there is no cross-border data transfer. No Schrems II analysis needed. No DPA required. No dependency on adequacy decisions that may be overturned.

3. No Behavioral Tracking

If the spam detection mechanism does not track user behavior across pages — does not log mouse movements, does not fingerprint browsers, does not correlate sessions — then the data minimization principle is satisfied by default.

4. Server-Side Verification

The detection logic must execute on the server, where it cannot be inspected or manipulated by the bot. Client-side-only defenses are both a security weakness and a privacy concern (since they require JavaScript execution in the user’s browser to collect signals).

How This Works in Practice

Server-side honeypot fields are the clearest example of this architecture. The server generates hidden form fields with randomized names and expected values. A legitimate user’s browser renders the form normally — the hidden fields are invisible, and the browser submits them with the expected values. A bot, parsing the form programmatically, either fills in the hidden fields (revealing itself) or submits unexpected values (revealing itself).

The entire interaction is:

Server generates the form with hidden fields. No cookies. No external scripts.
User fills out and submits the form. The browser submits the hidden fields with the expected values automatically.
Server validates the hidden fields. If they do not match, the submission is rejected.

No personal data is processed. No behavioral data is collected. No data leaves the server. The detection is based entirely on the structural integrity of the form submission — not on who the user is or what they did on the page.

For WordPress sites running Contact Form 7, Samurai Honeypot for Forms implements exactly this pattern — multi-layered server-side honeypot validation with zero cookies, zero third-party dependencies, and zero personal data processing. It is the kind of architecture that makes the GDPR compliance conversation irrelevant, because there is nothing to comply about.

If you are not sure whether your current spam protection creates GDPR liability, walk through these questions:

[ ] Does your spam filter set cookies? Open your browser’s DevTools, clear cookies, load a page with a form, and check what was set. If anything appeared before you interacted with a consent banner, you have a problem.
[ ] Does it load external scripts? Check the Network tab in DevTools. If you see requests to google.com, gstatic.com, akismet.com, or any other third-party domain, data is being transferred.
[ ] Is the spam filter blocked by your CMP for non-consenting users? If not, you are processing data without a legal basis. If yes, your form is unprotected for those users.
[ ] Do you have a DPA with the spam filter provider? If data is transferred to a third party, you need one. Review it for subprocessor obligations and international transfer clauses.
[ ] Is the processing documented in your ROPA? GDPR Article 30 requires it.
[ ] Does your privacy policy disclose the processing? If your spam filter sends data to Google and your privacy policy does not mention it, you are in violation of Article 13.

If any of these boxes are unchecked, your spam filter is a compliance gap.

Key Takeaways

Not all spam filters are “strictly necessary” under GDPR. The exemption applies only to processing that is essential, minimal, and limited to the specific service the user requested. Third-party tracking scripts that load on every page and transmit behavioral data to US servers do not qualify.
The consent paradox makes consent-dependent spam filters architecturally broken. If your spam protection only works for users who consent to tracking, it does not work at all — because bots bypass consent mechanisms entirely.
Server-side, cookie-less spam filtering eliminates the GDPR compliance burden entirely. No cookies means no ePrivacy consent requirement. No third-party transfers means no Schrems II risk. No behavioral tracking means data minimization is satisfied by default.
European enforcement is real and increasing. Austrian, French, and German authorities have already fined organizations for data transfers to US-based services. The legal reasoning applies to reCAPTCHA and similar services with full force.
The safest compliance strategy is to avoid the problem. Do not build your security on a foundation that requires ongoing legal analysis, adequacy decisions, and consent management. Build it on architecture that has nothing to consent to.

← All Columns