Who else reads along? Third-party scripts on form pages

When someone fills in your contact form, they assume the message goes to you. On many sites, though, the form page also runs scripts from analytics providers, ad networks, chat vendors and whatever a tag manager has collected over the years. Each of these scripts runs with the same rights as your own code: it can read the page, watch input fields and send data to its own servers. That does not mean they all do. But on the page where visitors type their name, e-mail address and sometimes details about their health, money or legal trouble, you should know who is reading along.

The usual suspects

• Session-replay tools record clicks, scrolling and often keystrokes so a visit can be played back later. Unless fields are masked, that can include what people type into the form.
• Ad and analytics pixels report page views and conversions to third parties – on the form page itself and very often on the thank-you page.
• Chat widgets load a complete application from another domain, usually on every page, including the one with the form.
• Tag managers let marketing add scripts without a deployment. Convenient, but it also means code can reach the form page without anyone reviewing it.
• Smaller helpers – A/B testing, heatmaps, social embeds, fonts, maps – each add a host that receives at least the visitor’s IP address and usually the address of your site; scripts among them can also read the full page URL.

Session replay: a recorder next to the input field

Most replay tools offer settings to mask input fields or exclude whole areas, and some mask certain fields by default. The weak spots are the exceptions: a free-text message field the default does not cover, a form built from components the masking rules do not recognise, or a setting someone switched off while debugging and never switched back on. A recording stored with a third party may then contain exactly what the visitor wrote to you – something they did not expect and that your privacy policy, which under Art. 13 GDPR has to name the recipients or categories of recipients of personal data, may not mention at all.

Pixels and the thank-you page

Conversion tracking needs a signal that a form was sent, and the thank-you page is the obvious place to fire it. Most pixels send the full page address with every event. If the form submits via GET, or the redirect after sending appends values such as ?name=…&email=… to the URL, those values go straight to the ad or analytics provider. Some pixels also offer features that automatically pick up e-mail addresses or phone numbers from forms to improve matching. And if the pixel fires before the visitor has answered the cookie banner – or after they declined – the problem is no longer only a technical one.

Tag managers, consent and the supply chain

Tag managers are often where the overview gets lost. A campaign tag for a trade fair two years ago, a trial of a heatmap tool, a pixel for a network nobody uses any more – all of it may still load on every page, including the form. Triggers are frequently set to “all pages”, and consent rules are configured tag by tag, so one tag with a missing condition is enough to load a script before the visitor has agreed.

Then there is the supply chain. When you embed a script from another host, you trust whoever controls that host today and in the future. A vendor can change what its script does, be sold, or have its delivery infrastructure compromised. The browser cannot tell a legitimate script from a manipulated one, so injected code on a form page can read every field and send it anywhere – the same pattern used for skimming on checkout pages.

What you can do

1. 1Take inventory. Open each form page and its thank-you page with the browser’s developer tools, check the Network tab and list every external host. Do it once without consent and once after accepting the banner.
2. 2Remove what nobody needs. Tags without a clear owner and purpose are candidates for deletion. Limit tag manager triggers so only the tags that must run on form pages do.
3. 3Mask inputs in replay tools. Mask all input fields, not only passwords, and exclude the form area entirely if you can. Then watch a recording to see what was actually stored.
4. 4Send conversions without personal data. Submit via POST, keep form values out of redirect URLs and fire a neutral event such as “contact_form_sent”. Switch off automatic form-field collection in pixels.
5. 5Load only after consent. Scripts that need consent must not load before the visitor agrees – and must stay off if they decline. Test both paths.
6. 6Pin and restrict where feasible. Subresource Integrity (a hash on the script tag) makes the browser refuse a static file that has changed; it does not suit scripts that change by design, like tag managers. A Content Security Policy limits which hosts may run scripts – start in report-only mode to see what would break.
7. 7Watch for changes. A new script host on a form page should be a deliberate decision, not a surprise. Make sure you get notified when one appears.

formexposed checks which tracking pixels fire on your form pages, whether a session-replay tool may record form input and whether declining the cookie banner really stops tracking – passively, nothing is submitted. A free check shows the overall level; these findings are in the full report. With monitoring for a verified domain, formexposed also alerts you when a new script host appears on a form page.