# HTTP-only cookies: risikoen din scanner ikke ser > HttpOnly-flaget holder JavaScript ude — og dermed også de fleste cookie-scannere. Sådan finder du cookies, der aldrig når din cookie-politik. - URL: https://privaci.io/artikler/http-only-cookies-gdpr/ - Dato: 2026-09-23 - Kategori: Teknisk compliance - Emner: HTTP-only cookies, cookie scanning, GDPR, ePrivacy, Datatilsynet --- De fleste virksomheder kender historien nu: du skal have et cookie-banner, du skal indhente samtykke, og du skal dokumentere hvad dine cookies gør. Men der er en hel kategori af cookies, som går fuldstændig ubemærket forbi de fleste compliance-værktøjer — og som potentielt kan gøre din cookie-politik direkte vildledende. Det handler om HTTP-only cookies. Cookies med `HttpOnly`-flaget er usynlige for JavaScript. Det betyder, at ethvert scannerværktøj der kører `document.cookie` i en browser — og det gør langt de fleste — simpelthen ikke kan se dem. De er der, de sættes på brugernes enheder, de sendes frem og tilbage med hvert eneste HTTP-request. Men standard cookie-scannere finder dem ikke. Det er et problem, fordi ePrivacy-direktivets artikel 5(3) og GDPR ikke skelner mellem cookies med og uden HttpOnly-flag. Loven gælder for alle cookies der opbevares på eller tilgår en brugers terminal-udstyr — uanset om de er tilgængelige for JavaScript eller ej. Denne artikel er til dig, hvad enten du er udvikler der skal forstå det tekniske, eller compliance-ansvarlig der skal sikre at dokumentationen holder vand. Vi gennemgår hvad HTTP-only cookies er, hvorfor de udgør en overset juridisk risiko, hvilke konkrete cookies der typisk mangler, og — vigtigst — hvordan du finder dem. --- ## 1. Hvad er HTTP-Only cookies? ### Den tekniske forklaring En cookie sættes af en server via en `Set-Cookie`-header i et HTTP-svar. Normalt kan den cookie efterfølgende læses af JavaScript i browseren via `document.cookie`. Udviklere bruger dette til alt fra at tjekke login-status til at vise personaliseret indhold. HttpOnly-flaget ændrer på det. Når en server sender denne header: ```http Set-Cookie: session=a3f8b2c9d1e4; HttpOnly; Secure; SameSite=Strict; Path=/ ``` ...fortæller serveren browseren: "Denne cookie må aldrig eksponeres via JavaScript." Browseren gemmer cookien, sender den med ved alle efterfølgende requests til det pågældende domæne, men returnerer en tom streng hvis JavaScript forsøger at læse den. Forsøger du dette i browserens konsol: ```javascript document.cookie // Returnerer: "præference=dark_mode; analytics_id=xyz" // HttpOnly-cookies vises IKKE her ``` De er simpelthen usynlige for alt JavaScript-baseret kode. ### Hvorfor de eksisterer HttpOnly-flaget er en sikkerhedsforanstaltning mod Cross-Site Scripting (XSS)-angreb. Hvis en angriber formår at injicere ondsindet JavaScript på din side, kan de normalt stjæle session-cookies via `document.cookie` og dermed overtage brugerens session. Med HttpOnly-flaget er den cookie utilgængelig for det ondsindede script. Det er en god og anbefalet sikkerhedspraksis. CNIL (den franske DPA) anbefaler eksplicit brugen af HttpOnly-flaget som del af god cookie-hygiejne. Det ændrer dog ikke på de juridiske forpligtelser. ### Hvad det betyder for automatisk scanning De fleste cookie-scannere fungerer ved at åbne en hjemmeside i en browser (eller et headless browser-miljø), lade siden indlæse, og derefter køre `document.cookie` for at hente en liste over cookies. Denne tilgang er hurtig og fungerer fint for langt de fleste cookies. Men den er fundamental blindt over for HttpOnly-cookies. En scanner, der kun bruger JavaScript-baseret cookie-opsamling, vil konsekvent misse alle cookies med HttpOnly-flaget. Hvor mange det er, afhænger helt af din stak — men de er sjældent få: en typisk opsætning bag Cloudflare med en session i PHP, Java eller .NET sætter flere HttpOnly-cookies, før din applikationskode overhovedet kører. De seks navngivne eksempler nedenfor er alle HttpOnly som standard. --- ## 2. GDPR og HTTP-Only cookies ### ePrivacy-direktivet artikel 5(3): teknologineutral formulering ePrivacy-direktivet (2002/58/EC), specifikt artikel 5(3), er det juridiske fundament for cookie-samtykke i EU. Bestemmelsen kræver forudgående samtykke til "lagring af oplysninger eller opnåelse af adgang til oplysninger, der allerede er lagret, i en abonnents eller brugers terminaludstyr." Bemærk formuleringen: "lagring af oplysninger" eller "adgang til oplysninger." Der står ikke noget om cookies der er tilgængelige via JavaScript, cookies sat af servere, eller cookies med specifikke sikkerhedsattributter. Bestemmelsen er bevidst teknologineutral. EDPB (European Data Protection Board) bekræftede dette i Guidelines 2/2023 om det tekniske scope af artikel 5(3). EDPB fastslår, at direktivet anvender "en bred, teknologineutral tilgang" og eksplicit dækker cookies og andre teknikker uanset implementeringsdetaljer. Der er ingen undtagelse for HttpOnly-cookies, server-satte cookies eller script-utilgængelige cookies. Konsekvensen er klar: **HttpOnly-flaget er et sikkerheds-flag, ikke et compliance-flag.** ### GDPR artikel 6 og artikel 7: juridisk grundlag og samtykke Når ePrivacy-direktivet kræver samtykke, skal det samtykke også opfylde GDPR's standarder (jf. CJEU-dommen i Planet49-sagen fra 2019). Det betyder: - Aktivt tilvalg — ingen afkrydsede bokse på forhånd - Specifikt — separat samtykke per formål - Informeret — brugeren skal kende cookie-navn, formål, varighed og eventuelle tredjeparter - Utvetydigt — ingen passiv accept via fortsat brug For HttpOnly-cookies har dette praktisk betydning: du kan ikke dokumentere samtykke til en cookie, du ikke ved eksisterer. Hvis din scanner aldrig finder `__cf_bm` eller `JSESSIONID`, kan du ikke beskrive dem i din cookie-politik, og du kan ikke styre hvornår de sættes i relation til brugerens samtykke. ### Er session-cookies undtaget? Dette er det spørgsmål mange compliance-folk stiller, og svaret er: det afhænger af formålet, ikke af cookie-typen. ePrivacy-direktivet har en undtagelse for cookies der er "strengt nødvendige" for at levere en bruger-anmodet tjeneste (strictly necessary). Denne undtagelse gælder for eksempel session-management cookies der holder en bruger logget ind mens de handler i en webshop, eller en indkøbskurv-cookie der husker hvad brugeren har lagt i kurven. Men "session-cookie" og "strengt nødvendig" er ikke synonymer. Det er formålet og nødvendigheden der er afgørende, ikke det tekniske label. En session-cookie der bruges til bot-detection (som Cloudflares `__cf_bm`) er ikke automatisk undtaget — og slet ikke en session-cookie der bruges til analytics eller personalisering. EDPB's vejledning understreger, at "strengt nødvendig"-undtagelsen skal fortolkes snævert og dokumenteres konkret. Det er ikke nok at påstå at en cookie er nødvendig — du skal kunne demonstrere det. ### Datatilsynets fokus i 2026 Det danske Datatilsynet har udpeget sporingsteknologier på danske hjemmesider, herunder tracking-cookies og profilerings-teknologier, som et eksplicit tilsynsfokusområde for 2026. Tilsynet koordinerer indsatsen med Digitaliseringsstyrelsen, hvilket øger både omfanget og sandsynligheden for aktive tilsynssager. Datatilsynet vil kigge på: - Om tracking-scripts indlæses inden brugerens samtykke - Om brugere har reel mulighed for at afvise tracking - Om der er transparens omkring databehandlingen - Om den tekniske implementering stemmer overens med cookie-politikken Et scenarie hvor din cookie-politik siger "vi sætter disse 12 cookies" mens din server faktisk sætter 18 — fordi de 6 er HttpOnly og din scanner aldrig fandt dem — er præcis det mønster tilsynet leder efter. --- ## 3. Hvad din scanner IKKE ser ### Problemet illustreret Forestil dig et typisk scenarie: En virksomhed bruger CookieBot, OneTrust eller et tilsvarende populært scannerværktøj til at scanne deres hjemmeside. Scanneren finder 14 cookies, virksomheden kategoriserer dem, opdaterer cookie-politikken, og sætter et consent-banner op. Alt ser tilforladelig ud. Men serveren sætter faktisk 20 cookies. De 6 der mangler er alle HttpOnly. De er fra Cloudflare, AWS, og applikations-frameworket. De er aldrig dukket op i scannerens rapport, fordi scanneren kun kan se hvad JavaScript kan se. Her er en gennemgang af de cookies der hyppigst går tabt: ### __cf_bm (Cloudflare Bot Management) ```http Set-Cookie: __cf_bm=HxM4xGq...; Max-Age=1800; path=/; expires=Fri, 07-Mar-26 12:30:00 GMT; domain=.example.com; HttpOnly; Secure; SameSite=None ``` **Hvad den gør:** Cloudflare sætter denne cookie på alle sites der bruger Cloudflares Bot Management eller Bot Fight Mode. Den indeholder en krypteret bot-score og bruges til at skelne menneskelige brugere fra automatiserede bots. **Hvorfor den er problematisk fra compliance-perspektiv:** Den er sat af Cloudflare, ikke af websitets ejer. Den sendes til Cloudflares servere ved hvert request. Cookien udløber efter 30 minutter ved inaktivitet, men den eksisterer og behandles af en tredjepart. Cloudflares egen dokumentation bekræfter at cookien indeholder "information related to the calculation of Cloudflare's proprietary bot score." **Er den strengt nødvendig?** Cloudflare argumenterer for at den er nødvendig for bot-beskyttelse. Men bot-beskyttelse er ikke en service brugeren har anmodet om — det er en sikkerhedsforanstaltning websitet har valgt at implementere. Den juridiske vurdering er ikke entydig, og den bør som minimum dokumenteres i cookie-politikken. **Ses af standard scannere:** Nej. ### AWSALB og AWSALBCORS (Amazon Web Services Load Balancer) ```http Set-Cookie: AWSALB=Rg4f...; Expires=Fri, 14 Mar 2026 10:00:00 GMT; Path=/ Set-Cookie: AWSALBCORS=Rg4f...; Expires=Fri, 14 Mar 2026 10:00:00 GMT; Path=/; SameSite=None; Secure ``` **Hvad de gør:** AWS Elastic Load Balancer sætter disse cookies for at sikre "session stickiness" — at en brugers requests konsekvent rutes til den samme backend-server. Det sikrer en sammenhængende brugeroplevelse på sider der kører bag AWS load balancers. **Varighed:** Typisk 7 dage — langt fra en "session-cookie" i praksis. **Særligt bemærkelsesværdigt:** AWS's dokumentation siger eksplicit, at du ikke kan sætte `Secure` eller `HttpOnly`-flaget på AWSALB-cookies. AWSALB er dermed faktisk synlig for JavaScript. AWSALBCORS (den CORS-kompatible version) kan have `Secure`-flaget. Ingen af dem er traditionelt behandlet som særligt problematiske, men begge repræsenterer tredjepartsbehandling der skal dokumenteres. **Ses af standard scannere:** AWSALB ofte ja, AWSALBCORS afhænger af scanner-implementeringen. ### JSESSIONID (Java/Apache Tomcat/Jakarta EE) ```http Set-Cookie: JSESSIONID=A3F8B2C9D1E47F3A; Path=/app; HttpOnly; Secure; SameSite=Strict ``` **Hvad den gør:** JSESSIONID er Java-platformen og Apache Tomcats standard session-identifier. Den bruges til at knytte serverens session-objekt til en specifik browser-session. Den sættes automatisk af Java-frameworket og er som standard HttpOnly i moderne versioner. **Compliance-vurdering:** JSESSIONID er i mange tilfælde legitimt strengt nødvendig for at levere den service brugeren har anmodet om — eksempelvis at holde en bruger logget ind, eller huske trin i en checkout-flow. Men det kræver en konkret vurdering og dokumentation. Brugen af JSESSIONID alene siger intet om formålet. **Ses af standard scannere:** Nej — HttpOnly-flaget gør den usynlig. ### .AspNetCore.Session (Microsoft ASP.NET Core) ```http Set-Cookie: .AspNetCore.Session=CfDJ8...; path=/; httponly; samesite=lax ``` **Hvad den gør:** ASP.NET Core's built-in session middleware sætter denne cookie automatisk som en HttpOnly session-cookie. Den indeholder en krypteret reference til serverens session-data. **Compliance-vurdering:** Som med JSESSIONID kan den være strengt nødvendig, men det afhænger helt af hvad session-data bruges til. Bruges sessionen kun til at holde brugeren logget ind? Sandsynligvis strengt nødvendig. Bruges den til at gemme analytics-data eller personaliserings-præferencer? Potentielt ikke undtaget. **Ses af standard scannere:** Nej. ### PHPSESSID (PHP når HttpOnly er aktiveret) ```http Set-Cookie: PHPSESSID=d41d8cd98f00b204e9800998ecf8427e; path=/; HttpOnly; Secure ``` **Hvad den gør:** PHP's standard session-cookie. Bemærk: PHP sætter ikke HttpOnly som standard — det skal konfigureres eksplicit via `session.cookie_httponly = 1` i php.ini, eller `session_set_cookie_params()`. Mange PHP-sites har det aktiveret som sikkerhedsbest-practice. **Ses af standard scannere:** Nej, når HttpOnly er sat. ### connect.sid (Node.js/Express med express-session) ```http Set-Cookie: connect.sid=s%3A...; Path=/; HttpOnly; Secure; SameSite=Lax ``` **Hvad den gør:** Express.js's `express-session`-middleware sætter som standard denne HttpOnly-signerede session-cookie. Den er signeret med en secret-key og identificerer serverens session-objekt. **Ses af standard scannere:** Nej. --- ## 4. Teknisk deep-dive: Sådan finder man HTTP-Only cookies ### Problemet med document.cookie Lad os gøre det konkret. Åbn en hjemmeside, og skriv dette i browserkonsolens: ```javascript document.cookie ``` Du får en kommasepareret liste over cookies. Men alle cookies med HttpOnly-flaget er usynlige. Det er ikke en fejl — det er præcis designet. Selv den nyere `cookieStore` API (tilgængelig i moderne browsers) returnerer ikke HttpOnly-cookies: ```javascript // Dette returnerer heller IKKE HttpOnly-cookies const cookies = await cookieStore.getAll(); console.log(cookies); ``` ### Chrome DevTools: Network-fanen Den mest tilgængelige manuelle metode er at inspicere HTTP-trafik direkte i browserens Network-fane: 1. Åbn Chrome DevTools (F12) 2. Gå til fanen "Network" 3. Genindlæs siden 4. Klik på det første request (HTML-dokumentet) 5. Se under "Response Headers" — kig efter `Set-Cookie`-linjer Her vil du se alle cookies som serveren faktisk sætter, inklusiv HttpOnly-cookies. Eksempel på hvad du måske finder: ``` Set-Cookie: __cf_bm=abc123; Max-Age=1800; HttpOnly; Secure; SameSite=None Set-Cookie: JSESSIONID=XYZ789; Path=/; HttpOnly; Secure Set-Cookie: _ga=GA1.1.1234567890; Max-Age=63072000; SameSite=Lax ``` Bemærk `HttpOnly`-annotationen — den afslører præcis hvilke cookies der er usynlige for JavaScript. ### Chrome DevTools: Application-fanen Under Application > Cookies i DevTools vises faktisk ALLE cookies, inklusive HttpOnly-cookies, med en tydelig markering: - Cookies med HttpOnly-flaget har en markering i "HttpOnly"-kolonnen - Du kan se navn, værdi, domæne, sti, udløb, og alle flags Dette er den hurtigste manuelle måde at få et komplet overblik. ### Chrome DevTools Protocol (CDP): Den programmatiske løsning For automatiseret scanning er Chrome DevTools Protocol (CDP) nøglen. CDP er den underliggende protokol som Chrome DevTools selv bruger, og den giver programmatisk adgang til browseren på et langt dybere niveau end JavaScript. CDP-kommandoen `Network.getAllCookies` returnerer samtlige cookies browseren kender til — uanset HttpOnly-flag. Her er en komplet implementering med Playwright (den tilgang Privaci.io bruger): ```javascript const { chromium } = require('playwright'); async function scanAllCookies(url) { const browser = await chromium.launch(); const context = await browser.newContext(); const page = await context.newPage(); // Naviger til siden og vent på at netværket er idle await page.goto(url, { waitUntil: 'networkidle' }); // Hent ALLE cookies via context.cookies() // Playwright bruger CDP under motorhjelmen og returnerer HttpOnly-cookies const allCookies = await context.cookies(); const httpOnlyCookies = allCookies.filter(c => c.httpOnly); const regularCookies = allCookies.filter(c => !c.httpOnly); console.log(`Fundet ${allCookies.length} cookies i alt`); console.log(`- ${regularCookies.length} regulære cookies (synlige for JavaScript)`); console.log(`- ${httpOnlyCookies.length} HttpOnly cookies (usynlige for JavaScript)`); console.log('\nHttpOnly cookies:'); httpOnlyCookies.forEach(cookie => { console.log(` ${cookie.name}`); console.log(` Domain: ${cookie.domain}`); console.log(` Path: ${cookie.path}`); console.log(` Expires: ${cookie.expires === -1 ? 'Session' : new Date(cookie.expires * 1000).toISOString()}`); console.log(` Secure: ${cookie.secure}`); console.log(` SameSite: ${cookie.sameSite}`); }); await browser.close(); return allCookies; } scanAllCookies('https://example.com'); ``` Alternativt kan du bruge CDP direkte via Puppeteer: ```javascript const puppeteer = require('puppeteer'); async function getAllCookiesViaCDP(url) { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto(url, { waitUntil: 'networkidle2' }); // Brug CDP direkte — returnerer ALLE cookies inkl. HttpOnly const client = await page.target().createCDPSession(); const { cookies } = await client.send('Network.getAllCookies'); const httpOnlyCookies = cookies.filter(c => c.httpOnly); console.log(`HttpOnly cookies fundet: ${httpOnlyCookies.length}`); httpOnlyCookies.forEach(c => console.log(` - ${c.name} (${c.domain})`)); await browser.close(); return cookies; } ``` ### Hvad der gør Privaci.io anderledes Standard cookie-scannere — selv mange kommercielle løsninger — bruger én af to tilgange: 1. **JavaScript-baseret**: Kører `document.cookie` eller `document.querySelectorAll('script')` for at finde cookies og scripts. Blindt over for HttpOnly-cookies. 2. **Simpel HTTP-request**: Parser `Set-Cookie`-headers i det første response, men følger ikke JavaScript-eksekveringen og finder ikke cookies sat dynamisk ved bruger-interaktion. Privaci.io by bon.do bruger en CDP-baseret scanner der: - Launcher en rigtig Chromium-browser (headless) - Venter på at al JavaScript er eksekveret og netværkstrafik er settled - Bruger CDP's `Network.getAllCookies` til at hente samtlige cookies - Overvåger `Set-Cookie`-headers i alle netværksresponses under scanning - Klassificerer cookies baseret på navn, domæne og kendte cookie-databaser - Markerer HttpOnly-cookies eksplicit i rapporten Resultatet er en komplet oversigt der inkluderer de cookies andre scannere ikke ser. --- ## 5. Risiko-vurdering ### Det regulatoriske landskab i 2026 De samlede GDPR-bøder i Europa er passeret 7,1 mia. euro fordelt på over 3.200 registrerede afgørelser ([CMS Enforcement Tracker](https://www.enforcementtracker.com/), opgjort september 2026). Cookie-sager er sjældent de største enkeltbeløb, men de er blandt de hyppigste, og de rammer virksomheder i alle størrelser. Konkrete eksempler fra håndhævelsespraksis: - **CNIL vs. Google og Facebook (2022):** 150 mio. euro og 60 mio. euro for vildledende cookie-samtykke — bla. for at gøre det sværere at afvise cookies end at acceptere dem. Cookie-bannere og manglende transparens var kernen i sagerne. - **CNIL vs. CRITEO (2023):** 40 mio. euro for behandling af brugerdata uden gyldigt samtykke og brud på GDPR. - **OLG Frankfurt (11. december 2025, sag 6 U 81/23):** enhver, der medvirker til at sætte en cookie, er "Anbieter" efter § 25 TDDDG og kan hæfte for både forbud og erstatning — også en tredjepart, der blot leverer koden. Retten tilkendte 100 euro i godtgørelse. Dommen flytter ansvaret ud over websitets ejer alene ([dejure.org](https://dejure.org/dienste/vernetzung/rechtsprechung?Gericht=OLG+Frankfurt&Datum=11.12.2025&Aktenzeichen=6+U+81%2F23)). ### Det specifikke scenario: udokumenterede cookies En virksomheds cookie-politik lister 12 cookies. Under et tilsynsbesøg scanner Datatilsynet siden og finder 18 cookies — de 6 ekstra er HttpOnly-cookies fra Cloudflare og applikationsframeworket. Dette skaber følgende problemer: 1. **Vildledende cookie-politik:** Artikel 13/14 GDPR kræver at du informerer om al databehandling. En cookie-politik der er ukomplet er per definition mangelfuld. 2. **Ugyldigt samtykke:** Hvis brugere har givet samtykke baseret på en ufuldstændig liste, er samtykket potentielt ugyldigt — det var ikke informeret. 3. **Manglende dokumentation:** Du kan ikke demonstrere compliance for cookies du ikke kendte til. 4. **Potentiel tredjepartsproblematik:** HttpOnly-cookies fra Cloudflare eller AWS indebærer behandling hos tredjeparter — noget der kræver særlig oplysning og potentielt databehandleraftaler. ### Datatilsynet og dansk håndhævelse Datatilsynet har udpeget **danske hjemmesiders sporing af borgere** som et af fokusområderne for tilsynet i 2026. Af tilsynsplanen fremgår det, at der fortsat offentliggøres undersøgelser, der viser "omfattende indhentning af personoplysninger på danske hjemmesider, og hvor borgerne ikke har en reel mulighed for at sige nej til sporingsteknologier". Indsatsen koordineres med Digitaliseringsstyrelsen ([Datatilsynet, fokusområder 2026](https://www.datatilsynet.dk/afgoerelser/generelt-om-tilsyn/saerlige-fokusomraader-for-datatilsynets-tilsynsaktiviteter-i-2026)). Cookie Informations compliance-rapport for Danmark 2024, der scannede de 1.000 mest besøgte danske websites, fandt: - **94 %** har et cookie-banner (op fra 91 % i 2023) - **84 %** har alligevel compliance-problemer (op fra 79 %) - **70 %** sætter ikke-nødvendige cookies, før brugeren har taget stilling Kilde: [Cookie Information, Compliance Report Denmark 2024](https://cookieinformation.com/newsroom). Tallene er konkurrentens egne — de er medtaget, fordi de er den bedst dokumenterede måling af det danske marked, ikke fordi de er vores. En virksomhed der aktivt har investeret i et cookie-banner, men hvis scanner aldrig har fundet alle cookies, kan befinde sig i den situation at de tror de er compliant, mens de faktisk ikke er. --- ## 6. Løsningen: CDP-baseret scanning ### Privaci.io by bon.do: fuld cookie-synlighed Privaci.io er bygget fra grunden med CDP som teknisk fundament, netop for at løse det blinde punkt som JavaScript-baserede scannere har. Når du scanner en hjemmeside med Privaci.io: **Hvad sker der teknisk:** 1. En Chromium-instans lanceres i et isoleret sandkasse-miljø 2. Siden indlæses med realistisk bruger-agent og normal browser-profil 3. CDP-forbindelsen etableres og `Network`-domænet aktiveres 4. Alle `Set-Cookie`-events fanges i real-time under indlæsningen 5. Siden ventes på at netværket er settled (networkidle) 6. `Network.getAllCookies` kaldes — returnerer samtlige cookies inklusive HttpOnly 7. Cookies beriges med klassifikationsdata fra vores cookie-database 8. Rapporten skelner tydeligt mellem HttpOnly og ikke-HttpOnly cookies **Hvad du får i rapporten:** - Komplet cookie-liste inklusiv HttpOnly-cookies - Tydelig markering af hvilke der er HttpOnly - Klassifikation: nødvendig / funktionel / analytics / marketing - Anbefaling til om cookien kræver samtykke - Konkrete beskrivelser der kan kopieres direkte ind i cookie-politikken ### DIY alternativ: manuel audit-guide Har du brug for at lave en komplet manuel audit her og nu? Følg disse trin: **Trin 1: Network-fane audit** 1. Åbn Chrome DevTools (F12) > Network 2. Slet al cache og cookies (Ctrl+Shift+Delete) 3. Genindlæs siden 4. For hvert request: se Response Headers > Set-Cookie 5. Notér alle cookies med HttpOnly-annotation **Trin 2: Application-fane audit** 1. Gå til Application > Cookies i DevTools 2. Klik på dit domæne 3. Se kolonnen "HttpOnly" — markerede cookies er usynlige for JavaScript 4. Gør det samme for hvert tredjeparts-domæne der er listet **Trin 3: Verificer med simpelt Node.js-script** ```javascript const { chromium } = require('playwright'); (async () => { const browser = await chromium.launch(); const context = await browser.newContext(); const page = await context.newPage(); await page.goto(process.argv[2] || 'https://example.com', { waitUntil: 'networkidle' }); const cookies = await context.cookies(); console.log('\n=== ALLE COOKIES ==='); console.log(`Total: ${cookies.length}`); console.log('\n--- HttpOnly cookies (usynlige for standard scannere) ---'); cookies .filter(c => c.httpOnly) .forEach(c => { const expires = c.expires === -1 ? 'Session' : new Date(c.expires * 1000).toLocaleDateString('da-DK'); console.log(`${c.name}`); console.log(` Domain: ${c.domain}`); console.log(` Expires: ${expires}`); console.log(` Secure: ${c.secure}`); }); console.log('\n--- Standard cookies (synlige for JavaScript) ---'); cookies .filter(c => !c.httpOnly) .forEach(c => console.log(`${c.name} (${c.domain})`)); await browser.close(); })(); ``` Kør med: `node scan-cookies.js https://dinhjemmeside.dk` **Trin 4: Klassificer og dokumenter** For hver HttpOnly-cookie du finder, stil disse spørgsmål: - Hvem sætter den? (Identificer via domæne og cookie-navn) - Hvad er formålet? (Slå op i cookiens dokumentation) - Er den strengt nødvendig for en service brugeren har anmodet om? - Hvis ikke: kræver den samtykke, og hvornår sættes den relativt til samtykke? - Er den dokumenteret i din cookie-politik? --- ## 7. Gratis HTTP-Only Cookie Scanner Privaci.io by bon.do tilbyder en gratis cookie-scanner der bruger CDP-teknologien beskrevet i denne artikel. I modsætning til scannere der udelukkende baserer sig på JavaScript, vil Privaci.io finde alle cookies på din hjemmeside — inklusiv de HttpOnly-cookies der er usynlige for standard-scannere. **Scan din hjemmeside gratis på [privaci.io](https://privaci.io)** Du får: - Komplet cookie-oversigt inkl. HttpOnly-cookies - Automatisk klassifikation og kategorisering - Ét fund pr. tracker med angivelse af, om den satte data før samtykke - Månedlig scanning, så listen ikke er et øjebliksbillede --- ## 8. FAQ **Q: Er alle HttpOnly-cookies GDPR-problematiske?** Ikke nødvendigvis. Mange HttpOnly-cookies er legitime og strengt nødvendige — eksempelvis session-cookies der holder en bruger logget ind. Problemet opstår ikke af at de er HttpOnly, men af at de er udokumenterede. Alle cookies skal dokumenteres, selv de strengt nødvendige. **Q: Kan jeg bare undlade at nævne HttpOnly session-cookies i min cookie-politik?** Nej. Også "strictly necessary" cookies bør nævnes i cookie-politikken for at opfylde GDPR's transparenskrav (artikel 13/14). Selv hvis du ikke behøver samtykke for dem, skal brugere informeres om at de eksisterer, hvad de gør, og hvem der behandler dataene. **Q: Min hjemmeside bruger Cloudflare — skal jeg nævne __cf_bm?** Ja. `__cf_bm` sættes på brugerens enhed og behandles af Cloudflare. Den bør dokumenteres i din cookie-politik med en beskrivelse af formålet (bot-detection). Hvorvidt den kræver samtykke er til diskussion — Cloudflare argumenterer for at den er nødvendig for sikker levering af tjenesten. Men den bør som minimum nævnes. **Q: Hvad med cookies sat af CDN'er og infrastruktur-udbydere?** Disse er dit ansvar som dataansvarlig. Det er dig der har valgt at bruge Cloudflare, AWS eller anden infrastruktur, og det er derfor din forpligtelse at dokumentere de cookies de sætter på dine brugeres enheder. **Q: Min scanner finder 10 cookies, men din artikel siger der kan være flere. Hvad gør jeg?** Brug en CDP-baseret scanner (som Privaci.io) til at lave en komplet audit. Alternativt kan du bruge den manuelle fremgangsmåde beskrevet i sektion 6. Sammenlign resultaterne — forskellen er sandsynligvis præcis dine HttpOnly-cookies. **Q: JSESSIONID og .AspNetCore.Session er jo session-cookies — de forsvinder jo bare?** De er session-cookies i den forstand at de udløber når browseren lukkes. Men de eksisterer og behandles som identifikatorer så længe browseren er åben. ePrivacy-direktivet skelner ikke baseret på varighed, men baseret på formål og nødvendighed. **Q: Hvad koster det at ignorere dette?** Det er svært at sætte et konkret tal på, fordi håndhævelsen afhænger af mange faktorer. Men som dataansvarlig risikerer du kritik, påbud og bøder fra Datatilsynet. Det tyske eksempel fra december 2025, hvor en domstol holdt cookie-udbydere direkte ansvarlige, viser at ansvaret ikke kun rammer de store. --- ## Opsummering HTTP-only cookies er ikke et edge-case problem. Enhver moderne webapplikation der bruger et standard framework — Java, PHP, .NET, Node.js — sætter sandsynligvis HttpOnly-cookies. Enhver hjemmeside bag Cloudflare får `__cf_bm`. Mange sites på AWS har AWSALB. Disse cookies er reelle. De sættes på brugernes enheder. De er underlagt ePrivacy-direktivets artikel 5(3). Og de fleste cookie-scannere finder dem simpelthen ikke. Løsningen er ikke kompliceret: brug en scanner der bruger Chrome DevTools Protocol til at hente cookies, frem for at stole udelukkende på JavaScript. Dokumenter alle cookies du finder, inklusive de HttpOnly. Vurdér konkret hvilke der er strengt nødvendige og hvilke der kræver samtykke. Det er den eneste måde at have en cookie-politik der faktisk er komplet — og den eneste måde at forberede sig ordentligt på Datatilsynets øgede fokus på tracking-teknologier i 2026. --- *Artikel af bon.do — virksomheden bag Privaci.io cookie compliance platform.* *Juridisk ansvarsfraskrivelse: Denne artikel er skrevet til informationsformål og udgør ikke juridisk rådgivning. Kontakt en juridisk rådgiver for specifik compliance-vejledning til din virksomhed.*