Cookie scanning — sådan virker det, og hvorfor de fleste scannere er utilstrækkelige

Hvis du har slået “cookie scanner” op og spurgt din marketingchef om hjælp til GDPR-compliance, er chancen stor for, at I endte med et JavaScript-snippet der gennemgår document.cookie og laver en pæn liste. Det ser professionelt ud. Det ser komplet ud.

Det er det ikke.

Langt de fleste cookie scannere på markedet er fundamentalt begrænsede af den teknologi, de bygger på. De ser den del af din hjemmesides tracking, der er synlig for JavaScript — og misser alt det, der bevidst er designet til ikke at være synligt. I 2026, hvor tilsynsmyndighederne i EU aktivt auditerer hjemmesider og samkører fund med indberettede compliance-profiler, er det ikke nok.

Denne guide forklarer, hvad en cookie scanner er, hvordan de fungerer, og hvad du bør kræve — teknisk og funktionsmæssigt — af den scanner, der beskytter dig mod bøder.

1. Hvad er en cookie scanner?

En cookie scanner er et automatiseret værktøj, der besøger dine websider og registrerer alle cookies, tracking-pixels og andre sporingsmekanismer, der aktiveres under besøget.

Outputtet bruges til at:

• Populere cookie-bannere med en korrekt og opdateret liste over teknologier
• Verificere compliance — stemmer de faktisk fundne cookies overens med dem, I har erklæret i jeres privacy policy og CMP-konfiguration?
• Opdage uautoriserede trackers — tredjepartskode der sættes af scripts I har inkluderet, men ikke selv kontrollerer
• Dokumentere compliance over for tilsynsmyndigheder og potentielle revisioner

En cookie scanner er ikke et juridisk instrument i sig selv. Den er en teknisk audit-funktion. Men en scan der misser vigtige cookies er langt farligere end ingen scan — den giver en falsk tryghed.

2. Sådan fungerer en simpel cookie scanner

De fleste cookie scannere på markedet fungerer ved at injicere JavaScript i browserens udførelseskontekst og aflæse de cookies, der er tilgængelige for JavaScript.

Hvad den ser

En JavaScript-baseret scanner kan aflæse:

• Cookies sat via document.cookie (client-side cookies)
• Cookies med SameSite-attributter der ikke er HttpOnly
• LocalStorage og SessionStorage nøgler (afhænger af implementering)
• Synlige netværksanmodninger til tredjepartsdomæner i nogle implementeringer

Når scanneren har gennemgået en side, klassificerer den fundne cookies mod kendte databaser — Google Analytics, Facebook Pixel, Hotjar osv. — og kategoriserer dem som nødvendige, præference-, statistik- eller marketingcookies.

Hvad den IKKE ser

Her er det kritiske: JavaScript har ingen adgang til:

HttpOnly cookies Cookies med HttpOnly-attributten er af sikkerhedsmæssige årsager ikke tilgængelige via document.cookie. De er designet til at beskytte mod XSS-angreb — men de bruges også af tracking-scripts til at skjule sig for netop JavaScript-baserede cookie-scannere. En tracker sat som HttpOnly-cookie via en HTTP-respons er 100% usynlig for al JavaScript-baseret scanning.

Cookies sat i HTTP-responsen En simpel JavaScript-scanner besøger en side og aflæser cookies efter rendering. Men mange trackers sættes som HTTP Set-Cookie-headers allerede i serverrespons-trinnet — inden JavaScript overhovedet eksekveres. Disse cookies registreres i browseren, men en scanner der udelukkende aflæser document.cookie på klientsiden vil ikke nødvendigvis fange dem.

Dynamiske og betingede cookies En stor kategori af tracking-cookies sættes ikke ved sideindlæsning. De sættes når:

• Brugeren klikker på en specifik knap
• Brugeren scroller til en bestemt position
• En video afspilles
• Brugeren udfylder og indsender en formular
• Betingede scripts aktiveres baseret på brugersegment, geolokation eller A/B-test

En scanner der kun indlæser en side og aflæser startcookies vil misse disse dynamiske cookies fuldstændigt.

CNAME-cloaking trackers CNAME-cloaking er en teknik, hvor en tredjeparts tracking-service konfigureres som et underdomæne af publishers eget domæne via DNS. Eksempel: analytics.dinhjemmeside.dk er i virkeligheden via DNS CNAME-record en reference til data.tracking-vendor.com. Fra browserens perspektiv er det en first-party cookie. Fra en simpel scanners perspektiv ser det ud som din egen teknologi.

CNAME-cloaking er udbredt — brugt af Adobe Analytics, certaine versioner af Meta Pixel, og adskillige adtech-vendors — og er designet specifikt til at omgå tredjepartsblokering og forfladige synlighed.

Server-side tracking Moderne tag management systemer og server-side GTM-implementeringer sender tracking-data fra din webserver til analytics- og annonce-platforme uden at passere browseren. Dette efterlader ingen cookies overhovedet — og er fuldstændigt usynligt for enhver browser-baseret scanner.

3. Hvad en avanceret scanner gør anderledes

En professionel cookie scanner skal ikke blot aflæse JavaScript-konteksten. Den skal emulere en rigtig browser, interceptere al netværkstrafik og analysere alle datastrømme på samtlige protokolniveauer.

Chrome DevTools Protocol (CDP)

Chrome DevTools Protocol er den API, Chrome-browseren eksponerer til debugging og automation-formål. Via CDP kan en scanner:

• Interceptere alle netværksanmodninger — ikke kun dem, der er synlige for JavaScript, men alle HTTP/HTTPS-anmodninger inkl. XHR, Fetch, billedpixels og WebSocket-forbindelser
• Aflæse alle Set-Cookie-headers i netværksresponser — herunder HttpOnly cookies der aldrig er tilgængelige via document.cookie
• Monitorere storage events — LocalStorage, SessionStorage, IndexedDB og Cache API
• Analysere cookie-attributter præcist: SameSite, Secure, Expires, Path, HttpOnly-flag
• Udføre JavaScript-eksekvering i browserkonteksten og observere sideeffekter

CDP giver adgang til det komplette billede af, hvad der sker i browseren — det billede DevTools viser en udvikler, men automatiseret og skaleret.

Playwright browser automation

Playwright er et open source browser-automatiseringsframework, der driver Chromium, Firefox og WebKit. I modsætning til et simpelt JavaScript-script kan Playwright:

• Simulere reelle brugerinteraktioner: Klik, scroll, formularudfyldning, hover — og dermed aktivere dynamiske cookies der kun sættes ved brugerhandlinger
• Køre scanning med og uden samtykke: Simuler et besøg uden samtykke, accepter alle cookies, og sammenlign — hvad sættes pre-consent vs. post-consent?
• Navigere igennem brugerflows: Checkout-sider, kontaktsider, login — ikke kun forsiden
• Emulere mobile enheder: Cookies og trackers kan variere mellem desktop og mobil

Kombinationen af CDP og Playwright muliggør det, der reelt ligner et rigtigt brugerbesøg — med fuld netværksinterception.

DNS-baseret CNAME-detektion

For at opdage CNAME-cloaking skal en scanner udføre DNS-opslag på alle domæner, der kontaktes under et sidesøg, og sammenligne CNAME-kæder med kendte tracking-leverandørers IP-ranges og hostnames.

Processen ser sådan ud:

1. Scanner besøger siden og identificerer alle domæner der kontaktes
2. For hvert domæne udføres rekursive DNS-opslag
3. Resulterende CNAME-kæder sammenlignes med en database af kendte tracking-vendors
4. Matches flagges som potentiel CNAME-cloaking

Denne analyse kan ikke udføres fra browseren — den kræver server-side DNS-opslag, fordi browsere ikke eksponerer fuld DNS-information til JavaScript.

Dynamisk scanning vs. statisk scanning

En god scanner bruger dynamisk scanning som standard og supplerer med statisk analyse til hurtige, hyppige monitors.

4. Hvad du bør kræve af en cookie scanner

Ikke alle scannere er skabt ens. Brug denne checkliste, når du evaluerer løsninger:

Tekniske minimumskrav

• Netværksniveau-interception — ikke kun document.cookie-aflæsning
• HttpOnly cookie-detektion — via Set-Cookie header monitoring
• Pre-consent vs. post-consent scanning — kan scanneren sammenligne begge states?
• Dynamisk scanning — simulerer brugerinteraktioner (klik, scroll, formular)
• Multi-page scanning — ikke kun forsiden, men produktsider, kontaktsider, checkout
• CNAME-detektion — DNS-opslag med sammenligning mod vendor-databaser

Funktionelle krav

• Automatisk klassifikation — cookies kategoriseres mod opdaterede databaser (IAB GVL, open-source tracker-lister)
• CMP-verifikation — scanner kontrollerer om cookies sættes inden samtykke
• Ændringshistorik — hvornår dukkede en ny tracker op? Hvilke er forsvundet?
• Scheduled scans — automatisk periodisk scanning uden manuel initiering
• Rapporteksport — PDF/CSV til intern dokumentation eller DPA-anmodninger
• API-adgang — integration med CI/CD pipelines for automatisk compliance-check ved deployer

Compliance-specifikke krav

• IAB TCF 2.3 verifikation — er disclosedVendors korrekt populeret?
• Google Consent Mode v2 check — sendes korrekte consent-signaler til Google?
• Vendor-mapping — matches fundne cookies mod GVL-registrerede vendors?
• Legitim interesse-detektion — bruger vendors LI til formål, der kræver samtykke?

5. Sammenligning: Simpel vs. avanceret scanning

For at illustrere forskellen — her er hvad de to tilgange typisk finder på en gennemsnitlig publisher-hjemmeside med Google Ad Manager, Meta Pixel og Hotjar:

Forskellen er ikke marginal. En simpel scanner kan typisk identificere 60-70% af de reelt aktive trackingmekanismer på en moderne hjemmeside. En avanceret aktiv browser-scanner nærmer sig 95%+.

6. Scan-frekvens: Hvor ofte skal du scanne?

Et enkelt scan er et øjebliksbillede. Din hjemmeside er ikke statisk — third-party scripts opdateres, tag management-konfigurationer ændres, og nye trackers introduceres uden varsel, hver gang en leverandør opdaterer sit script.

Anbefalede minimumsfrekvenser:

Hvad sker der, hvis du ikke scanner regelmæssigt?

En af de hyppigste årsager til GDPR-overtrædelser er ikke bevidste beslutninger, men uopmærksomhed: Et marketing-team tilføjer et nyt pixel i Google Tag Manager. En CMS-opdatering inkluderer et nyt analytics-script. En A/B-testing-platform sættes op med standardindstillinger. Ingen af disse ændringer gennemgår en juridisk review — de sker bare.

Regelmæssig scanning fungerer som en teknisk tripwire: Den registrerer nye trackers automatisk og alerter, inden det er et compliance-problem.

7. Sådan fungerer Privaci.io’s scanning

Privaci.io ser det samme som en erfaren udvikler der sidder med DevTools åben og gennemgår hvert netværkskald — men automatiseret, skaleret og med fuld compliance-kontekst.

Tre-faset scanning

Vores scanning-engine fungerer i tre faser:

Fase 1: Pre-consent scanning Vi besøger din hjemmeside som en ny bruger uden cookie-historik. Vi opsnapper alle netværksanmodninger og registrerer præcis hvilke cookies og trackers der aktiveres inden din CMP har vist sig — og inden brugeren har haft mulighed for at give eller afvise samtykke.

Dette er den mest kritiske fase: Hvis der sættes trackers her, er det en overtrædelse uanset hvor god din CMP ellers er.

Fase 2: Post-consent scanning (alle kategorier) Vi simulerer “Accepter alle” og kører en komplet scanning med brugerinteraktioner: scroll, klik på navigationselementer, hover over interaktive komponenter. Dette aktiverer dynamiske cookies og event-baserede trackers.

Fase 3: Differentieret post-consent scanning (delvist samtykke) Vi simulerer et realistisk scenario: brugeren accepterer nødvendige og statistikken, men afviser marketing. Sættes der stadig marketing-cookies? Det bør de ikke.

Hvad vi finder som andre ikke finder

HttpOnly session trackers: Vi fanger cookies der aldrig er synlige via document.cookie ved at observere Set-Cookie headers i netværksresponser. En simpel scanner ser dem aldrig.

CNAME-cloakede trackers: Vores DNS-analyselag udfører rekursive DNS-opslag for alle kontaktede domæner og sammenligner resulterende CNAME-kæder mod vores database af kendte tracker-infrastrukturer. Vi identificerer, om din cdn.dinhjemmeside.dk i virkeligheden er tracking.vendor.com.

Pre-consent violations: Vi tidsstempler alle cookie-sætninger og netværksanmodninger og kan dokumentere præcis, hvilke trackers der fyrede inden din CMP-popup var synlig for brugeren — med millisekund-præcision.

Dynamiske event-cookies: Ved at simulere brugerinteraktioner fanger vi cookies, der kun sættes ved klik, scroll eller formularindsendelse — den kategori af trackers, der er mest undervurderet i standard compliance-audits.

Uoverensstemmelser mellem deklaration og virkelighed: Vi sammenligner fundne vendors og cookies mod din CMP-konfiguration og IAB GVL og rapporterer gaps: Trackers der er aktive men ikke deklareret. Vendors der er deklareret i CMP men faktisk ikke aktive. Formål der bruges i strid med TCF 2.3-krav.

8. Klar til at se, hvad der faktisk sker på din hjemmeside?

De fleste hjemmesider vi scanner indeholder mindst én overraskelse — en tracker der fyrer for tidligt, en HttpOnly cookie fra et script marketing-teamet tilføjede for seks måneder siden, eller et CNAME-cloaket analytics-script fra en platform der er integreret via en tredjepartsleverandør.

Det er ikke tegn på ondsindet adfærd. Det er tegn på kompleksitet — og det er præcis, hvad en rigtig cookie scanner er til for at afdække.

Kør en gratis scan af din hjemmeside med Privaci.io og se hvad vores aktive browser-scanning finder, som din nuværende løsning overser.

FAQ

Hvad er forskellen på en cookie scanner og et cookie consent tool (CMP)? En CMP (Consent Management Platform) håndterer brugernes samtykkevalg og serverer cookie-banneret. En cookie scanner auditerer, hvad der faktisk sker teknisk — om CMPen fungerer korrekt, om der sættes trackers inden samtykke, og om fundne cookies stemmer overens med deklarerede. De er komplementære; den ene erstatter ikke den anden.

Kan jeg ikke bare bruge Chrome DevTools manuelt? Du kan se meget med DevTools — og det er et godt supplement til forståelse. Men en manuel audit skalerer ikke: Du kan ikke konsekvent gennemgå alle sider, alle interaktioner, simulere pre-consent state korrekt, og gøre det på tværs af alle dine hjemmesider med regelmæssige intervaller. En automatiseret scanner løser netop dette.

Hvor mange sider bør scannes? Som minimum bør du scanne din forside, en typisk produktside eller indholdside, din kontaktside, og din checkout- eller konverteringsside (hvis relevant). Trackers varierer ofte per sidetype — særligt betingede marketing-scripts der kun aktiveres på specifikke sidetyper.

Hvad er HttpOnly cookies, og er de et problem? HttpOnly er en cookie-attribut der forhindrer JavaScript-adgang til cookien — primært en sikkerhedsfunktion. De er ikke per definition et problem, men de kan indeholde tracking-identifikatorer der falder under GDPR. Hvis din scanner ikke opdager dem, ved du ikke, om de kræver samtykke.

Hvad er CNAME-cloaking, og er det ulovligt? CNAME-cloaking er en teknisk konfiguration, ikke i sig selv ulovlig. Men brugen af CNAME-cloaking til at omgå tredjepartsblokering og sætte first-party lignende tracking-cookies er problematisk i et GDPR-perspektiv, særligt hvis disse cookies indsamler persondata uden eksplicit samtykke og uden korrekt deklaration.

Hvad er server-side tracking, og kan det scannes? Server-side tracking sender data direkte fra din webserver til analytics/annonce-platforme — ingen browser-cookies involveret. Det er i princippet usynligt for browser-baserede scannere. Privaci.io kan delvist identificere server-side tracking via netværksmønsteranalyse og kendte endpoint-mønstre, men fuld server-side audit kræver adgang til server-logfiler og tag management konfiguration.

Hvad sker der, hvis min scan finder pre-consent trackers? Det er en direkte GDPR-overtrædelse i de fleste tilfælde. Løsningen er at konfigurere din CMP til at blokere de pågældende scripts, indtil samtykke er givet — enten via tag blocking i Google Tag Manager, script-blokering i CMP’ens native funktion, eller ved at flytte trackeren til en server-side implementering med korrekt consent-tjek.