Cache nooit een persoonlijke winkelwagen alsof het een openbare productpagina is. Sluit cart-, checkout- en accountcontext gericht uit van paginacache en CDN-opslag, terwijl statische bestanden en publieke cataloguspagina’s wel snel geleverd kunnen worden. Zo voorkom je dat bezoekers verouderde aantallen of zelfs gegevens uit een andere sessie zien.
“Cache uitzetten” voor de hele webshop is ook geen goed antwoord. Dat maakt veilige pagina’s onnodig traag en maskeert welke onderdelen werkelijk sessiegebonden zijn. De juiste aanpak begint met een kaart van routes, cookies, AJAX-acties en fragmenten die persoonlijke staat lezen of schrijven.
Breng de persoonlijke grenzen in kaart
De winkelwagenpagina en checkout zijn duidelijke uitzonderingen, maar er zijn meer randen. Denk aan een link waarmee een cart wordt hersteld, een opgeslagen-winkelwagenspagina in Mijn account, dynamische aantallen in de header en een endpoint dat een selectie deelt. Ook een lege HTML-shell kan persoonlijke informatie krijgen via een later request. Documenteer daarom niet alleen URL’s, maar ook welke bron de zichtbare staat bepaalt.
| Onderdeel | Gewenste cachehouding | Controle |
|---|---|---|
| Publieke productpagina | Cachebaar, met zorgvuldig dynamisch cartfragment | Prijs- en voorraadregels passen bij de bron |
| Winkelwagen en checkout | Geen gedeelde paginacache | Sessie en gebruiker blijven gescheiden |
| Mijn-accountlijsten | Privé en niet gedeeld cachen | Uitloggen wist zichtbare persoonlijke staat |
| Deel- of herstelactie | No-store voor de actie-uitkomst | Terugknop toont geen oude gevoelige pagina |
| Statische CSS en JavaScript | Lang cachen met bestandsversie | Nieuwe release krijgt een nieuwe URL |
Gebruik meerdere verdedigingslagen
Stuur op persoonlijke antwoorden expliciete cacheheaders mee, sluit relevante paden uit in de hostinglaag en respecteer cookies die een actieve winkelwagen of ingelogde sessie aangeven. Geen enkele laag is voldoende op zichzelf. Een reverse proxy kan applicatieheaders anders interpreteren; een CDN-regel kan later veranderen; een plugin kan een nieuw pad toevoegen.
Let ook op cachekeys. Alleen de URL gebruiken is onveilig wanneer taal, valuta, klantgroep of sessie het antwoord beïnvloedt. Alles in de key stoppen kan juist een explosie van varianten veroorzaken. Kies daarom per component: publieke varianten mogen gecontroleerd in de cache, persoonlijke inhoud hoort via een privérequest of helemaal ongecached te komen. Bij een bredere integratiearchitectuur helpt Yindle Connect om verantwoordelijkheden tussen webshop en achterliggende systemen helder te houden.
Browsercache verdient een eigen controle. Een no-store-respons voorkomt dat een gevoelige herstel- of checkoutpagina via terugnavigatie opnieuw zichtbaar wordt, maar kan de gebruikerservaring beïnvloeden. Test dat bewust. Gebruik bij muterende requests geen GET-link die een actie stil uitvoert; laat de link eerst een overzicht openen en voer vervangen of opslaan pas uit met een beveiligde POST-actie. Daarmee scheid je deelbaarheid van de persoonlijke wijziging.
Fictief voorbeeld: een herstellink toont de verkeerde header
Groothandel Kade deelt projectcarts met zakelijke klanten. Na een optimalisatieronde wordt de herstelpagina gecachet. De productregels worden wel opnieuw geladen, maar de header bevat het carttotaal van een eerdere bezoeker. Er lekken geen namen, toch ontstaat direct wantrouwen: de ontvanger ziet een bedrag dat niet bij zijn selectie hoort.
Kade splitst de pagina op. De publieke uitleg en styling zijn cachebaar; cartinhoud, aantallen en acties worden vanuit de eigen sessie opgehaald. De herstelrespons krijgt no-store, accountpaden worden in hosting en applicatie uitgesloten en statische assets krijgen een versie in de bestandsnaam. Daarna testen twee medewerkers gelijktijdig met verschillende browsers en incognitovensters.
Na iedere release voert Kade een kleine rooktest uit vanaf een koude cache. Dat is belangrijk: een ontwikkelaar met een ingelogde beheerdercookie omzeilt vaak de cache en ziet het probleem niet. De test wordt daarom uitgevoerd als gast, als klant en via de publieke hostnaam. Ook na een wijziging van CDN, cookiebanner of optimalisatieplugin wordt de routekaart opnieuw gecontroleerd.
Een praktische cache-veiligheidstest
- Maak twee accounts met duidelijk verschillende winkelwagens.
- Open cart, checkout, Mijn account en een gedeelde herstellink afwisselend.
- Herhaal via normaal venster, incognito en een tweede apparaat.
- Controleer responseheaders én het gedrag van CDN of hostcache.
- Gebruik terug- en vooruitknoppen na inloggen, uitloggen en herstellen.
- Test headeraantallen, mini-cart, coupons, taal en klantgroep.
- Wis alleen de centrale cache en controleer of het probleem terugkomt.
- Neem nieuwe persoonlijke routes op in de releasechecklist.
Maak één eigenaar verantwoordelijk voor de routekaart. Performancewerk, checkoutontwikkeling en marketingplugins kunnen allemaal nieuwe cachegrenzen introduceren. Voor complexe webshops is een periodieke technische review vaak goedkoper dan een onverklaarbare sessiefout achteraf. Op maatwerksoftware lees je hoe proces en techniek samen kunnen worden ontworpen.
Laat Yindle de cachegrenzen van jouw WooCommerce-stroom controleren.