When you contest a GAS fine or parking retribution, PVResponse often cites technical security shortcomings of the public site that issued the fine — things like “no HSTS header” or “Google Tag Manager loads before consent”. For many users, these terms sound abstract. This page concretely explains what’s wrong, how an attacker exploits it, and why this strengthens your contestation.

1. HTTPS and HSTS — why all traffic must be encrypted

When you fill in a contestation form on a municipal website, your data (licence plate, name, case number) travels across dozens of intermediary networks before reaching the municipality’s server. Without HTTPS (TLS encryption), every hop — the café Wi-Fi, an ISP’s router, or an attacker on the same network — can literally read or alter the data.

HTTPS alone isn’t enough: an attacker can intercept the first connection and force the user back to http:// (the SSL-stripping attack). HSTS (Strict-Transport-Security) fixes this: the server tells the browser “only come back via HTTPS for the next 1–2 years”.

User browser Attacker open Wi-Fi Server gemeente http:// https:// Without HSTS the attacker can strip the HTTPS layer
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
What can go wrong? Without HSTS, an attacker on shared Wi-Fi can intercept your plate, PV reference and contestation text before they ever reach the municipality.
For your contestation Article 32 GDPR obliges a public platform to take “appropriate technical measures”. The HSTS header has existed since 2012 (RFC 6797) and is free to configure. Its absence is a demonstrable breach of the state of the art.

2. Content-Security-Policy — barrier against script injection

A Content-Security-Policy (CSP) tells the browser which scripts, stylesheets and images may be loaded from which sources. Without CSP, any script from any server can execute — an attacker who exploits a cross-site scripting flaw can freely load scripts from their own server.

A good CSP uses default-deny: anything not explicitly allowed is blocked.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-RaNd0m'; style-src 'self'; img-src 'self' data:; frame-ancestors 'self'; object-src 'none'; base-uri 'self'
What can go wrong? Without CSP, a single XSS flaw is enough to compromise the entire contestation form. An attacker can silently rewrite your contestation text before sending, or redirect you to a fake payment page.
For your contestation The DPA expects public platforms that receive contestations to take “appropriate technical measures” (art. 32 GDPR). CSP has been a web standard since 2012, is built into every modern web server, and is purely a configuration effort.

3. Referrer-Policy — leak of case data via URLs

By default, your browser sends the full URL of the previous page as the Referer header. Problematic when the URL carries sensitive data — PV reference, token, licence plate. municipality.be/contest?pv=20241234&plate=1-ABC-123 is then forwarded in plain text to every external script.

// Only send the domain, never the path or parameters Referrer-Policy: strict-origin-when-cross-origin
What can go wrong? With the default no-referrer-when-downgrade, your PV number and plate become visible to every third party loaded on the page. Direct transfer of personal data to (usually) US processors.
For your contestation This breaches both article 5(1)(c) GDPR (data minimisation) and article 32 GDPR (inadequate technical measures).

4. Permissions-Policy — control over camera, microphone, location

The Permissions-Policy header (formerly Feature-Policy) lets the server decide which sensor permissions (camera, microphone, GPS) the page may even request. For a contestation form there’s no legitimate reason to ask.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
What can go wrong? If a third-party script is compromised, it can request camera or microphone access that the user may accidentally grant.
For your contestation Art. 32 GDPR requires a proactive security stance; explicitly restricting sensor access has been a standard defence since 2018.

5. X-Frame-Options — clickjacking protection

Clickjacking is an attack where the legitimate municipal page is loaded into an invisible iframe on an attacker site. The user clicks on what looks like a game, but the click is actually passed to the hidden iframe — e.g. onto a “Withdraw my contestation” button.

X-Frame-Options: SAMEORIGIN // modern alternative, inside CSP Content-Security-Policy: frame-ancestors 'self'
For your contestation If the municipality offers a withdrawal button with no frame protection, an attacker can via a phishing page trigger contestation withdrawals or unintended payments.

6. X-Content-Type-Options — MIME-sniffing abuse

Browsers sometimes try to “guess” a file’s type. Attackers exploit that: they upload an apparently innocent image which is then interpreted as JavaScript. The one-line header X-Content-Type-Options: nosniff turns that guessing off.

X-Content-Type-Options: nosniff
For your contestation If this header is missing on a site with upload functionality (attachments, photos), that is a demonstrable gap. No cost barrier can explain its absence.

7. Third-party trackers — Google Analytics, GTM, Facebook Pixel

Many municipal sites load — often without the administrator knowing — scripts from large US technology companies. Google Tag Manager isn’t a tracker itself, but a loader of other trackers; once active, it can asynchronously load Google Analytics, Facebook Pixel, LinkedIn Insight Tag and sometimes dozens of other things.

Each script gets access to your IP, browser version, OS, URL and event parameters. With Facebook Pixel, visits are linked to your Facebook account if you were ever signed in.

Browser opens page Municipal server serves HTML + scripts HTTP Google Analytics IP, URL, cookie-ID Facebook Pixel + Facebook-ID Google Tag Manager loads more trackers Google Fonts IP + font choice Four different US companies receive your visit before you type anything
What can go wrong? Your IP and browser fingerprint get linked to the fact that you visited a contestation page. Via GA and Pixel that can enrich ad-targeting profiles — a real risk for people in vulnerable situations.
For your contestation The DPA has ruled that loading GA/GTM/Pixel before consent breaches article 129 ECA. For public sites there is no valid legal basis for marketing analytics.

8. Schrems II and US transfers

The CJEU invalidated the EU-US Privacy Shield in July 2020 (Schrems II, C-311/18). US intelligence agencies have overly broad powers to intercept EU citizens’ data; EU citizens have no effective judicial remedy in the US.

Any transfer — via GA, Pixel, Google Fonts, AWS — is in principle unlawful unless supplementary safeguards exist (SCCs, Transfer Impact Assessment, encryption).

For your contestation One of the strongest arguments. When the audit finds GA/GTM/Pixel/Fonts and the privacy statement cites no SCCs, the entire processing chain is unlawful and the sanction can be voided.

9. Cookie consent — art. 129 ECA / ePrivacy

The ePrivacy directive (in Belgium via art. 129 ECA) requires prior and explicit consent for any non-essential tracker. “Prior” means: before the browser loads the tracker. In practice many sites load GA and Pixel immediately and only then show the cookie banner — the damage is already done.

For your contestation The DPA requires a “Reject all” button on equal footing with “Accept all”. A big green “Accept” button with a hidden settings link where “Reject” takes three clicks is a dark pattern (DPA 56/2026 Dilbeek).

10. Processor agreements — art. 28 GDPR

Every external service a municipality uses (ANPR camera vendor, collection agency, hosting provider) requires a written processor agreement before the first processing. The DPA is strict: a retroactively signed DPA cannot cure earlier processing (DPA 56/2026 Dilbeek).

For your contestation Expressly request the DPA with each processor. Many municipalities are missing one or more. Without a DPA, processing is unlawful regardless of the substantive correctness of the fine.

11. Outdated software — Drupal 7 is EOL

Drupal 7 reached end-of-life on 5 January 2025. No more security updates. Any vulnerability disclosed after that date stays open forever. Several Belgian public sites (April 2026) are still running Drupal 7.

For your contestation Demand proof that the site runs on a supported CMS (art. 32 GDPR). A written DPIA should record this; if missing, an art. 35 GDPR violation is added.

12. Secrets in the browser — API tokens in the HTML

Sometimes our audit discovers an API token directly in the HTML (Mapbox, Google Maps, CRM key). Everything in the HTML is visible to whoever loads the page. An attacker can take over the token and charge it against the municipality.

For your contestation This points to broader carelessness: if the municipality cannot protect its own tokens, there is little reason to believe it protects your data better.

13. How all this translates into your contestation

Each of the findings above is a single data point. We combine them into four coherent argument lines:

a. Unlawful evidence collection

If the municipality processed your data by inadequate means, the underlying evidence chain is legally flawed. The fact that you received the fine does not change the unlawful nature of the collection.

b. Absence of a legal basis

For marketing analytics on a public site there is no legal basis. Without a valid basis, processing is unlawful and the sanction can be voided.

c. Chapter V violations (US transfers)

Every GA/Pixel/Fonts integration without a Transfer Impact Assessment breaches arts. 44–49 GDPR. Sufficient for a complaint with the DPA.

d. Missing security measures

An accumulation of small gaps shows the municipality has no systematic security approach. Strengthens arguments (a) and (c).

What do we do for you? When you draft your contestation via PVResponse, we automatically add a selection of these arguments, tailored to your specific municipality. The audit data is public and verifiable via your browser’s DevTools.

Questions or feedback?

Reach us via our contact page. For legal references, see our DPA & GDPR page.