HTTP-Only Cookies: Den skjulte GDPR-risiko din scanner ikke ser

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:

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:

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. Afhængigt af din tech-stack kan det betyde, at 20-40% af de cookies dit site sætter, aldrig dukker op i din compliance-rapport.

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)

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)

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)

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)

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)

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)

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:

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:

// 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 et eksempel på en komplet implementering med Playwright:

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()
  // context.cookies() returnerer alle cookies inkl. HttpOnly
  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:

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 bruger en aktiv browser-scanner der:

• Renderer siden som en rigtig besøgende i et isoleret browsermiljø
• Venter på at al JavaScript er eksekveret og netværkstrafik er settled
• Opsnapper alle cookies på netværksniveau — inkl. dem med HttpOnly-flag
• 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

Det samlede beløb i GDPR-bøder har pr. januar 2025 passeret 5,88 milliarder euro. Cookie-relaterede overtrædelser er ikke de støste enkelt-sager, men de er ekstremt hyppige og dækker et bredt spektrum af virksomhedsstø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.
• Tysk domstol (december 2025): Frankfurt Higher Regional Court fandt tredjeparts cookie-udbydere medansvarlige, da cookies var placeret uden samtykke. Dommen udvider ansvaret ud over websitets ejer.

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

Som nævnt har Datatilsynet eksplicit udpeget tracking-teknologier som fokusområde for 2026-tilsynet. Cookie Information’s compliance-rapport for Danmark fra 2024 viste:

• 84% af analyserede websites har compliance-problemer (op fra 79% i 2023)
• 70% sætter ikke-nødvendige cookies inden samtykke

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: Aktiv browser-scanning

Privaci.io: fuld cookie-synlighed

Privaci.io er bygget til at løse det blinde punkt som JavaScript-baserede scannere har. Når du scanner en hjemmeside med Privaci.io:

Hvad sker der:

1. Siden indlæses i et isoleret browsermiljø med realistisk bruger-agent
2. Al JavaScript eksekveres og brugerinteraktioner simuleres
3. Alle cookies opfanges på netværksniveau — herunder HttpOnly
4. Set-Cookie-headers i alle netværksresponses overvåges i realtid
5. Siden ventes på at netværket er settled
6. Samtlige cookies hentes — uanset HttpOnly-flag
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

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 tilbyder en gratis cookie-scanner med aktiv browser-scanning som beskrevet i denne artikel. I modsætning til scannere der udelukkende baserer sig på JavaScript, finder Privaci.io alle cookies på din hjemmeside — inklusiv de HttpOnly-cookies der er usynlige for standard-scannere.

Scan din hjemmeside gratis på privaci.io

Du får:

• Komplet cookie-oversigt inkl. HttpOnly-cookies
• Automatisk klassifikation og kategorisering
• GDPR-klar cookie-politik klar til publicering
• Løbende monitoring der opdager nye cookies

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.

FAQ

Hvad er en HTTP-only cookie, og hvorfor er den svær at opdage?

En HTTP-only cookie sættes via HTTP-headeren Set-Cookie og er ikke tilgængelig via JavaScript. Det betyder at standard browser-baserede scannere, der kun analyserer document.cookie, ikke kan se dem – og dermed er de usynlige for de fleste compliance-værktøjer.

Kræver HTTP-only cookies stadig samtykke under GDPR?

Ja. GDPR og ePrivacy-direktivet skelner ikke mellem cookietyper baseret på, om de er HTTP-only eller ej. Hvis en cookie bruges til sporing eller profilering, kræver den samtykke uanset implementering.

Hvilke scannere kan opdage HTTP-only cookies?

Kun scannere der opererer på netværksniveau og analyserer de rå HTTP-headers kan opdage HTTP-only cookies. En aktiv browser-scanner som Privaci opfanger alle netværksresponser og registrerer Set-Cookie-headers direkte.

Er session-cookies undtaget fra samtykkekravet?

Strengt nødvendige session-cookies, f.eks. til indkøbskurv eller login, er undtaget. Men session-cookies der bruges til at tracke brugeradfærd på tværs af sider er ikke undtaget og kræver samtykke.

Hvordan ved jeg, om min hjemmeside sætter HTTP-only cookies uden samtykke?

Brug et scanner-værktøj der opererer på netværksniveau. Gratis browserbaserede scannere viser typisk kun cookies tilgængelige via JavaScript. Privaci scanner din side i et fuldt browsermiljø og rapporterer alle cookies inkl. HTTP-only.

Hvad bør jeg gøre, hvis jeg opdager HTTP-only tracking-cookies?

Identificér hvilken tjeneste der sætter dem, og sørg for at din CMP blokerer dem indtil samtykke er givet. Det kan kræve server-side integration eller brug af CMP’ens script-blokeringsmekanisme.