Kunder ser hinandens kurv eller forkert navn – cache af personligt indhold

Kort svar: Når kunder ser en andens kurv, navn eller adresse, er personligt indhold havnet i page cache – en cache-konfigurationsfejl, ikke en WooCommerce-bug og ikke et hack. Ryd al cache med det samme, og find derefter hullet: kurv, checkout og Min konto skal være undtaget, WooCommerce-cookies skal udløse bypass, og CDN-regler må aldrig cache “alt” eller ignorere originens no-cache-headere. Verificér bagefter med cache-headerne som udlogget kunde og med varer i kurven.

Fagligt gennemgået: 2. oktober 2026

Det er en meget alarmerende henvendelse for en webshop: “Jeg står som Louise, og det er ikke mig” – eller en kurv fyldt med varer, kunden aldrig har lagt i. Første indskydelse er ofte hacking. Den rigtige forklaring er næsten altid mere banal og hurtigere at rette: en side med persondata er blevet gemt i cachen og serveret til den næste besøgende.

Guiden viser, hvordan du lukker hullet akut, finder det cache-lag, der gemmer de personlige sider, og sætter undtagelserne op, så shoppen både er hurtig og viser hver kunde sine egne data.

Før du ændrer noget: Ryd cachen først – det stopper lækagen med det samme. Gem derefter skærmbilleder af de berørte cache-regler og notér tidspunkter, før du retter noget. Du skal bruge dokumentationen både til at finde hullet og til at vurdere hændelsen efter GDPR.

Sådan opstår fejlen

Page cache gemmer den færdige HTML af en side og serverer den til alle. Det er præcis meningen for produktsider og artikler – og præcis katastrofen for sider med persondata. Bliver kurven, checkout eller en side med “Hej Louise” i headeren gemt, får de næste besøgende Louises udgave:

Alle store cache-løsninger undtager som udgangspunkt WooCommerce-siderne automatisk, og WooCommerce sender selv headere, der fortæller cachen, at kurv, checkout og Min konto ikke må gemmes. Fejlen opstår, når der bygges ovenpå: håndlavede “cache everything”-regler i CDN’et, regler der overstyrer originens cache-headere, omdøbte side-slugs som undtagelserne ikke kender, eller et nyt cache-lag, der ikke respekterer de gamle regler.

1. Luk hullet nu

1. Ryd al cache – både cache-plugin, serverens cache og CDN. Det fjerner de personlige sider fra cachen med det samme.
2. Har du håndbyggede “cache alt”-regler i CDN’et, så slå dem fra, indtil undtagelserne er på plads.
3. Notér tidspunkt og de ramte sider – det skal bruges til at finde hullet bagefter.
4. Notér også, hvornår den seneste ændring i cache-opsætningen blev lavet. Perioden fra ændringen til rettelsen er det tidsrum, hvor data kan have været synlige for andre.

2. Find det cache-lag, der gemmer siden

En webshop har ofte flere cache-lag oven på hinanden: et cache-plugin, serverens egen cache og et CDN. Du skal finde det lag, der svarer med en gemt udgave af den personlige side. Det kan du se i svarets headere – i browserens Netværk-fane eller med curl:

curl -sI https://dinshop.dk/kurv/ | grep -iE "cache|age|set-cookie"
curl -sI -H "Cookie: woocommerce_items_in_cart=1" https://dinshop.dk/produkt/eksempel/ | grep -iE "cache|age"

Header	Lag	Hvad du skal se på kurv, checkout og Min konto
cf-cache-status	Cloudflare	DYNAMIC eller BYPASS – aldrig HIT
x-litespeed-cache	LiteSpeed-serverens cache	miss, eller hit,private for en privat udgave – aldrig et offentligt hit
x-cache / x-proxy-cache	Varnish, nginx eller anden proxy	MISS eller BYPASS
age	Alle delte cache-lag	Ingen header, eller 0 – en høj værdi betyder, at svaret er gemt
cache-control	Origin (WordPress)	no-cache, no-store eller private – det er WooCommerces signal til cachen

Sender origin korrekt no-cache, men et lag længere ude svarer alligevel HIT, er det det lag, der ignorerer signalet. Header-guiden forklarer værdierne i detaljer.

3. Ret hullet: de typiske steder

• CDN-regler: en Cache Rule, der cacher alle URL’er, overtrumfer pluginets undtagelser. Kurv, checkout og konto skal have bypass – og WooCommerce-cookies (woocommerce_items_in_cart, woocommerce_cart_hash, sessionscookien wp_woocommerce_session_ samt login-cookien wordpress_logged_in_) skal udløse bypass på alle sider. Opsætningen for Cloudflare står i Cache Rules-guiden til WooCommerce.
• Overstyret cache-levetid: en CDN-regel med en fast edge-levetid, der ignorerer originens Cache-Control, gemmer også de sider, WooCommerce har markeret som private. Lad reglen respektere originens headere på HTML.
• Omdøbte sider: hedder kurven /kurv/ i stedet for /cart/, skal håndbyggede undtagelser kende den danske slug. Pluginernes automatik følger sidetildelingen i WooCommerce – håndbyggede regler gør ikke.
• Cachede API-kald: blokbaseret kurv og checkout henter data via WooCommerces Store API under /wp-json/wc/store/, og ældre temaer bruger ?wc-ajax=. Cacher en regel /wp-json/ eller AJAX-kald, kan kurvdata lække, selvom selve kurvsiden er undtaget.
• Dynamiske elementer i cachede sider: viser headeren navn eller kurvantal på alle sider, skal den del hentes dynamisk (AJAX/ESI) – ellers følger persondata med i den cachede HTML, selv når selve siden gerne må caches. Har du slået WooCommerces cart fragments fra af hensyn til hastigheden, skal minikurven hentes på anden vis – se guiden om cart fragments.
• Cache for indloggede brugere: nogle cache-plugins kan cache sider for indloggede brugere pr. rolle. Det er kun sikkert, hvis siderne ikke indeholder navn, adresse eller kurv – ellers ser alle kunder med rollen “Kunde” den samme udgave.

4. Sådan bør opsætningen se ud

Målet er ikke mindre cache – en webshop skal cache aggressivt for at være hurtig. Målet er præcise undtagelser: alle produkt- og indholdssider caches; kurv, checkout og Min konto bypasses altid; og en besøgende med varer i kurven eller aktivt login får bypass overalt via cookie-reglerne. På LiteSpeed-hosting håndterer LiteSpeed Cache det med privat cache og ESI – se guiden om LiteSpeed Cache til WooCommerce – og kører du FlyingPress eller WP Rocket, er undtagelserne indbygget. Jo længere væk fra standardopsætningen du bevæger dig, jo større er risikoen.

Hold også antallet af cache-lag nede. To lag, der begge cacher HTML – fx et cache-plugin og en CDN-regel – skal have præcis de samme undtagelser, og det er netop dér, de glider fra hinanden over tid. Lad ét lag eje HTML-cachen, og lad de andre nøjes med statiske filer, hvis du kan.

5. Håndtér hændelsen efter GDPR

Har andre kunder kunnet se navne, adresser, mails eller ordreindhold, er det et brud på persondatasikkerheden, selvom det skyldes en fejlopsætning og ikke et angreb. Afklar, hvilke sider der har været cachet, hvor længe, og hvilke oplysninger de viste. Vurdér derefter sammen med jeres rådgiver, om hændelsen skal anmeldes til Datatilsynet – det skal i givet fald ske uden unødig forsinkelse og så vidt muligt inden 72 timer efter, at I er blevet opmærksomme på bruddet. Selv hvis I vurderer, at den ikke skal anmeldes, skal hændelsen registreres internt. Læs mere i guiden om kundedata i WooCommerce.

6. Verificér at opsætningen er tæt

Opsætningen er tæt, når du som udlogget kunde i inkognito kan se:

• cache-HIT på en produktside, men BYPASS/MISS på kurv, checkout og Min konto – ved hvert eneste besøg;
• at kurvantal og navn i headeren altid er dine egne, også lige efter en anden testbruger har handlet;
• at en side besøgt med varer i kurven ikke får HIT;
• at kald til /wp-json/wc/store/ og ?wc-ajax= ikke caches.

Test med to forskellige browsere eller enheder på samme tid: læg varer i kurven og log ind i den ene, og tjek, at den anden aldrig ser noget af det. Gentag testen efter hver ændring i cache- eller CDN-opsætningen. Er du i tvivl om, hvorvidt jeres samlede opsætning er tæt, kigger Hostious gerne cache-lagene igennem.

Læs også

• Hub: WooCommerce fejl og fejlfinding
• Cloudflare Cache Rules til WooCommerce
• Kurven bliver tom mellem sider
• Min konto-siden fejler
• WooCommerce hosting hos Hostious – LiteSpeed, daglig backup og dansk support døgnet rundt

Ofte stillede spørgsmål om cache og kurv i WooCommerce

Er kundernes data lækket – skal det anmeldes?

Andre kunder har kunnet se navne, adresser eller kurvindhold, så behandl det som en datahændelse: afklar omfang og varighed, og vurdér anmeldelsespligten efter GDPR sammen med jeres rådgiver. Betalingskortdata vises ikke på de cachede sider – de håndteres af betalingsgatewayen.

Hvorfor sker det kun en gang imellem?

Fordi den personlige side kun bliver cachet, når den første besøgende efter en cache-rydning rammer i en særlig tilstand – fx med varer i kurven. Derfor kommer klagerne i bursts efter cache-rydninger eller regelændringer.

Kan jeg bare slå cachen fra?

Det lukker hullet, men gør shoppen mærkbart langsommere – og det er unødvendigt. Rigtigt konfigureret cache med undtagelser og cookie-bypass giver både fart og korrekt indhold.

Hvilke WooCommerce-cookies skal udløse cache-bypass?

Som minimum woocommerce_items_in_cart, woocommerce_cart_hash, sessionscookien wp_woocommerce_session_ og login-cookien wordpress_logged_in_. Findes én af dem i requesten, skal siden hentes frisk fra serveren i stedet for fra cachen.