Een SSL-scan en een controle van Google Safe Browsing dekken slechts een fractie van het werkelijke aanvalsvlak van een site. We zien regelmatig sites die een A+-score op hun HTTP-headers hebben, terwijl ze trackers plaatsen vóór toestemming of gedeelde accounts zonder traceerbaarheid blootstellen. Om de beveiliging van een website te testen op een werkelijk nuttige manier, moet men verder gaan dan alleen een technische diagnose en de naleving van regelgeving, het beheer van cookies en de authenticatiebeleid integreren.
Cookies en trackers naleving: de test die scanners negeren
De meeste gratis beveiligingsanalysetools richten zich op het TLS-certificaat, de HTTP-headers en de eventuele aanwezigheid van het domein op een zwarte lijst. Geen van hen controleert het werkelijke gedrag van de cookie-toestemmingsbanner.
Dit is een kostbare blinde vlek. De CNIL heeft in 2025 haar sancties voortgezet tegen sites die trackers plaatsen vóór toestemming, geen eenvoudige weigering mogelijk maken zoals acceptatie, of doorgaan met het lezen van cookies na intrekking van de toestemming. We raden aan om na elke productie een test in drie afzonderlijke stappen uit te voeren:
- Laad de pagina in de incognitomodus en vang de netwerkverzoeken op voordat er enige interactie met de banner plaatsvindt. Elke derde partij cookie die op dit moment wordt geplaatst, is een niet-naleving.
- Weiger de trackers, ga verder met browsen op verschillende pagina’s en controleer vervolgens via de ontwikkelaarstools of de weigering daadwerkelijk wordt gerespecteerd gedurende de hele sessie.
- Accepteer de cookies, trek de toestemming in via de daarvoor bestemde link, en controleer of het lezen van de trackers daadwerkelijk stopt. Een test die beperkt is tot de startpagina is niet voldoende.
Dit protocol duurt minder dan tien minuten. Het dekt echter een gebied dat geautomatiseerde scanners niet aanpakken, en dat de belangrijkste bron van CNIL-sancties op Franse websites vertegenwoordigt.
Voordat u een klassieke technische audit start, is het relevant om de beveiliging van een website te testen door kwetsbaarheden te analyseren en het gedrag van trackers te controleren.
Web kwetsbaarheidsscans: wat een geautomatiseerd hulpmiddel echt detecteert
Een online beveiligingsscanner (type analyse van HTTP-headers, SSL/TLS-controle, malware-detectie via Google Safe Browsing) produceert een nuttige, maar gedeeltelijke diagnose. Deze tools identificeren bekende kwetsbaarheden: afwezigheid van Content-Security-Policy, verouderde TLS-versie, geblacklist domein.
Logische kwetsbaarheden blijven onzichtbaar voor geautomatiseerde scanners. Een privilegeverhoging via een slecht gecontroleerde URL-parameter, een contactformulier zonder CSRF-bescherming, of een API die gebruikersgegevens blootstelt zonder authenticatie, genereert geen waarschuwing in een passieve scan.
Voor een e-commerce site of een applicatie met een klantenportaal raden we aan de geautomatiseerde scan aan te vullen met een handmatige test gericht op drie punten:
- Pogingen om toegang te krijgen tot beschermde bronnen door de identificatiegegevens in de URL te manipuleren (IDOR). Als de server gegevens retourneert zonder de identiteit van de aanvrager te verifiëren, is de kwetsbaarheid kritiek.
- Injecteer test XSS-strings in alle zichtbare invoervelden. Een formulier dat de inhoud retourneert zonder HTML-escaping stelt bezoekers bloot aan sessiediefstal.
- Controleer de antwoordheaders op elk API-eindpunt, niet alleen op de startpagina. Beveiligingsbeleid varieert vaak van de ene route naar de andere op hetzelfde domein.
Een scannerrapport dat een hoge score weergeeft, garandeert niets als deze handmatige controles niet zijn uitgevoerd.
Authenticatiebeleid en gedeelde accounts: een gesanctioneerde zwakte
De CNIL heeft in haar rapport 2025 gemeld dat 14 organisaties zijn gesanctioneerd voor onvoldoende beveiliging, met name vanwege te zwakke wachtwoorden of gedeelde accounts tussen meerdere gebruikers. Deze constatering geldt zowel voor de back-offices van websites als voor de toegang tot databases.
De beveiliging van een site testen zonder het wachtwoordbeleid te auditen, is als het controleren van het slot terwijl de sleutel onder de deurmat ligt. We zien nog steeds CMS-systemen waarvan het beheerdersaccount een standaardwachtwoord gebruikt, of marketingteams die een unieke identificatie delen om toegang te krijgen tot het analytische dashboard.
Elke toegang moet individueel en traceerbaar zijn. Een serieuze audit controleert of de site een minimale wachtwoordlengte oplegt, pogingen blokkeert na een gedefinieerd aantal mislukkingen, en inlogpogingen logt met tijdstempel en IP-adres. Zonder deze controles wordt het detecteren van een inbraak achteraf onmogelijk.
Tracker muren en dark patterns: een recente regelgevende valstrik
De “cookie walls” (toegang afhankelijk van de acceptatie van trackers) zijn een onderwerp dat niet wordt behandeld door algemene beveiligingsgidsen. De CNIL verduidelijkt dat een dergelijk systeem niet automatisch verboden is, maar dat de toestemming vrij, geïnformeerd en gepresenteerd moet worden met evenwichtige keuzes.
In de praktijk voldoet een felgekleurde “Accepteren”-knop en een lichtgrijze “Weigeren”-link onderaan de pagina niet aan deze eis. Een conformiteitstest moet de visuele verhouding tussen de opties, de navigatiegemak naar de weigering, en de afwezigheid van een punitieve consequentie (omleiding, verborgen inhoud) bij niet-acceptatie evalueren.
Deze controle gaat verder dan het gebruikelijke technische bereik, maar valt rechtstreeks onder de bescherming van online gegevens. Een technisch veilige site die onevenredige druk uitoefent op de toestemming van zijn bezoekers, loopt hetzelfde risico op sancties als een slecht beveiligde site.
De beveiliging van een website is niet alleen een score die door een scanner wordt weergegeven. Het wordt gemeten op drie gelijktijdige assen: technische robuustheid, naleving van de verwerking van persoonlijke gegevens en de strengheid van interne toegangsbeleid. Het negeren van één van deze assen is als het openlaten van een deur, ongeacht het slot dat op de andere twee is geplaatst.
