Vem läser mer med? Skript från tredje part på formulärsidor

När någon fyller i ditt kontaktformulär utgår de från att meddelandet går till dig. På många webbplatser kör formulärsidan dock också skript från analysleverantörer, annonsnätverk, chattleverantörer och allt som en tagghanterare har samlat på sig genom åren. Vart och ett av dessa skript körs med samma rättigheter som din egen kod: det kan läsa sidan, bevaka inmatningsfält och skicka data till sina egna servrar. Det betyder inte att alla gör det. Men på den sida där besökarna skriver sitt namn, sin e-postadress och ibland uppgifter om sin hälsa, sina pengar eller juridiska problem bör du veta vem som läser med.

De vanliga misstänkta

• Verktyg för sessionsinspelning registrerar klick, rullning och ofta tangenttryckningar så att ett besök kan spelas upp i efterhand. Om fälten inte maskeras kan det inkludera det som folk skriver i formuläret.
• Annons- och analyspixlar rapporterar sidvisningar och konverteringar till tredje part – på själva formulärsidan och mycket ofta på tacksidan.
• Chattwidgetar laddar en komplett applikation från en annan domän, oftast på varje sida, inklusive den med formuläret.
• Tagghanterare gör det möjligt för marknadsavdelningen att lägga till skript utan en driftsättning. Bekvämt, men det innebär också att kod kan nå formulärsidan utan att någon granskar den.
• Mindre hjälpverktyg – A/B-tester, värmekartor, inbäddningar från sociala medier, typsnitt, kartor – lägger vart och ett till en värd som tar emot åtminstone besökarens IP-adress och oftast adressen till din webbplats; skript bland dem kan också läsa sidans fullständiga URL.

Sessionsinspelning: en inspelare bredvid inmatningsfältet

De flesta inspelningsverktyg har inställningar för att maskera inmatningsfält eller undanta hela områden, och vissa maskerar vissa fält som standard. De svaga punkterna är undantagen: ett fritextfält för meddelanden som standardinställningen inte täcker, ett formulär byggt av komponenter som maskeringsreglerna inte känner igen, eller en inställning som någon stängde av vid felsökning och aldrig slog på igen. En inspelning som lagras hos en tredje part kan då innehålla exakt det som besökaren skrev till dig – något som hen inte förväntade sig och som din integritetspolicy, som enligt Art. 13 GDPR ska ange mottagarna eller kategorierna av mottagare av personuppgifter, kanske inte nämner alls.

Pixlar och tacksidan

Konverteringsspårning behöver en signal om att ett formulär har skickats, och tacksidan är det självklara stället att utlösa den. De flesta pixlar skickar sidans fullständiga adress med varje händelse. Om formuläret skickas via GET, eller om omdirigeringen efter inskicket lägger till värden som ?name=…&email=… i URL:en, går dessa värden direkt till annons- eller analysleverantören. Vissa pixlar har också funktioner som automatiskt plockar upp e-postadresser eller telefonnummer från formulär för att förbättra matchningen. Och om pixeln utlöses innan besökaren har svarat på cookiebannern – eller efter att hen har avvisat den – är problemet inte längre bara tekniskt.

Tagghanterare, samtycke och leveranskedjan

Det är ofta i tagghanterare som överblicken går förlorad. En kampanjtagg för en mässa för två år sedan, ett test av ett värmekartsverktyg, en pixel för ett nätverk som ingen längre använder – allt detta kan fortfarande laddas på varje sida, inklusive formuläret. Utlösare är ofta inställda på ”alla sidor”, och samtyckesregler konfigureras tagg för tagg, så det räcker med en tagg med ett saknat villkor för att ett skript ska laddas innan besökaren har samtyckt.

Sedan finns leveranskedjan. När du bäddar in ett skript från en annan värd litar du på den som kontrollerar värden i dag och i framtiden. En leverantör kan ändra vad dess skript gör, säljas eller få sin leveransinfrastruktur komprometterad. Webbläsaren kan inte skilja ett legitimt skript från ett manipulerat, så injicerad kod på en formulärsida kan läsa varje fält och skicka det vart som helst – samma mönster som används för skimning på kassasidor.

Vad du kan göra

1. 1Inventera. Öppna varje formulärsida och dess tacksida med webbläsarens utvecklarverktyg, kontrollera fliken Nätverk och lista varje extern värd. Gör det en gång utan samtycke och en gång efter att du har godkänt bannern.
2. 2Ta bort det som ingen behöver. Taggar utan tydlig ägare och tydligt syfte är kandidater för radering. Begränsa tagghanterarens utlösare så att bara de taggar som måste köras på formulärsidor gör det.
3. 3Maskera inmatningar i inspelningsverktyg. Maskera alla inmatningsfält, inte bara lösenord, och undanta formulärområdet helt om du kan. Titta sedan på en inspelning för att se vad som faktiskt lagrades.
4. 4Skicka konverteringar utan personuppgifter. Skicka via POST, håll formulärvärden borta från omdirigerings-URL:er och utlös en neutral händelse som ”contact_form_sent”. Stäng av automatisk insamling av formulärfält i pixlar.
5. 5Ladda först efter samtycke. Skript som kräver samtycke får inte laddas innan besökaren samtycker – och måste förbli avstängda om hen avvisar. Testa båda vägarna.
6. 6Lås fast och begränsa där det är möjligt. Subresource Integrity (en hash i skripttaggen) får webbläsaren att vägra en statisk fil som har ändrats; det passar inte skript som ändras av naturen, som tagghanterare. En Content Security Policy begränsar vilka värdar som får köra skript – börja i report-only-läge för att se vad som skulle gå sönder.
7. 7Håll koll på ändringar. En ny skriptvärd på en formulärsida bör vara ett medvetet beslut, inte en överraskning. Se till att du får en avisering när en sådan dyker upp.

formexposed kontrollerar vilka spårningspixlar som utlöses på dina formulärsidor, om ett verktyg för sessionsinspelning kan spela in formulärinmatningar och om ett avvisande av cookiebannern verkligen stoppar spårningen – passivt, ingenting skickas. En gratisgranskning visar den övergripande nivån; dessa fynd finns i den fullständiga rapporten. Med övervakning av en verifierad domän larmar formexposed dig också när en ny skriptvärd dyker upp på en formulärsida.