Websitebeveiliging controleren: passieve checks zonder hacken

Passieve beveiligingschecks voor je webshop: TLS-vervaldatum, HSTS, CSP, nosniff, cookie-flags, mixed content, oud jQuery, security.txt en DMARC.

FixReports-redactie11 min. leestijd

Je kunt veel van de beveiligingsinstellingen van een webshop van buitenaf controleren door te lezen wat de site al naar elke bezoeker stuurt: het TLS-certificaat, redirects, HTTP-responseheaders, cookies, de scripts die worden geladen en de openbare DNS-records. Deze passieve controles versturen geen aanvalsverkeer en vereisen geen login, dus ze belasten een webshop niet meer dan een gewoon bezoek. Ze brengen gaten in de configuratie aan het licht, zoals een certificaat dat bijna verloopt, ontbrekende HSTS, onveilige cookies, mixed content of een jQuery-versie met bekende kwetsbaarheden. Ze zijn geen penetratietest en kunnen niet bewijzen dat een webshop veilig is.

De belangrijkste punten

Wat telt als een passieve beveiligingscheck?

Een passieve check leest alleen wat de site of de DNS teruggeeft op een gewoon verzoek.

Dat betekent: openbare pagina’s laden, het certificaat en de responseheaders lezen, de cookies en scripts opsommen die een pagina instelt en laadt, en openbare DNS-records opvragen. Een passieve check raadt geen wachtwoorden, verstuurt geen injectiepayloads, tast geen beheer-URL’s af en scant geen poorten. Alles hieronder kan met een browser, curl, openssl en dig.

Hoe controleer je je TLS-certificaat en de vervaldatum?

Lees de data en namen van het certificaat rechtstreeks uit, en zorg dat de verlenging geautomatiseerd is.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Controleer of notAfter ruim in de toekomst ligt, of het certificaat zowel example.com als www.example.com dekt als je beide gebruikt (de certificaatweergave van de browser toont de namen), en of de browser geen waarschuwingen geeft. De looptijd van certificaten wordt korter onder de Baseline Requirements van het CA/Browser Forum (sectie 6.3.2, versie 2.3.1 per oktober 2026), na Ballot SC-081v3 (opent in een nieuw tabblad), aangenomen op 11 april 2025:

Certificaat uitgegevenMaximale geldigheid
Vóór 15 maart 2026398 dagen
15 maart 2026 tot en met 14 maart 2027200 dagen
15 maart 2027 tot en met 14 maart 2029100 dagen
Vanaf 15 maart 202947 dagen

Door korte looptijden is handmatig verlengen riskant, dus controleer of je host of certificaattool automatisch verlengt. Controleer ook of gewone HTTP doorstuurt naar HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Je wilt een 301-respons (of 308) zien met een location-header die begint met https://.

Welke security headers hoort een webshop te versturen?

Een kleine set responseheaders blokkeert veelvoorkomende aanvallen in de browser, bijna zonder kosten.

HeaderWat de header doetGebruikelijke waardeBron
Strict-Transport-SecurityVertelt browsers dat ze alleen HTTPS mogen gebruiken en voorkomt dat gebruikers certificaatfouten wegklikkenmax-age=31536000; includeSubDomainsMDN (opent in een nieuw tabblad)
Content-Security-Policy: frame-ancestorsBepaalt welke sites je pagina’s mogen insluiten, wat beschermt tegen clickjackingframe-ancestors 'self'MDN (opent in een nieuw tabblad)
X-Frame-OptionsOudere manier om framing te beheren; volgens OWASP maakt frame-ancestors deze header overbodig in browsers die het ondersteunenDENY of SAMEORIGINOWASP (opent in een nieuw tabblad)
X-Content-Type-OptionsVoorkomt MIME-sniffing en blokkeert scripts en stylesheets die met het verkeerde type worden geserveerdnosniffMDN (opent in een nieuw tabblad)
Referrer-PolicyBeperkt hoeveel van je URL’s naar andere sites wordt gestuurdstrict-origin-when-cross-originOWASP
X-XSS-ProtectionHeader voor het XSS-filter van de browser; volgens OWASP kan die XSS-kwetsbaarheden veroorzaken in sites die anders veilig zijnNiet instellen, of 0OWASP

Controleer wat je webshop verstuurt:

curl -sI https://example.com/
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Let op twee dingen. includeSubDomains blokkeert elk subdomein dat alleen via HTTP werkt, dus controleer eerst je subdomeinen. HSTS-preloading vereist een max-age van minstens 31536000 en includeSubDomains, dus voeg preload pas toe als elk subdomein klaar is voor HTTPS. Een volledige CSP die scripts beperkt, is de moeite waard, maar OWASP merkt op dat die complex is om in te stellen en te onderhouden, en webshops met veel apps moeten zo’n CSP zorgvuldig testen.

Zijn je cookies ingesteld met Secure, HttpOnly en SameSite?

Sessie- en winkelwagencookies horen alle drie de attributen te hebben, en je ziet ze in de Set-Cookie-responseheaders.

AttribuutEffect (volgens MDN (opent in een nieuw tabblad))Waar het ertoe doet
SecureWordt alleen via HTTPS verstuurd; sites op gewone HTTP kunnen het niet instellenElke cookie op een webshop met HTTPS
HttpOnlyJavaScript kan de cookie niet lezen via document.cookie, wat helpt tegen XSSInlogsessies en winkelwagens
SameSite=Lax of StrictBeperkt wanneer de cookie bij cross-site verzoeken wordt meegestuurdSessies; Strict past bij authenticatie- en winkelwagencookies
SameSite=NoneWordt bij cross-site verzoeken meegestuurd; moet worden gecombineerd met SecureAlleen ingesloten functies van derden die het nodig hebben

Is er geen SameSite-attribuut ingesteld, dan behandelen browsers de cookie als Lax. Cookies die je eigen scripts moeten kunnen lezen, kunnen niet HttpOnly zijn, dus richt je op de cookies die een ingelogde klant of een beheerder identificeren.

curl -sI https://example.com/ | grep -i "^set-cookie"

De ontwikkelaarstools van de browser tonen dezelfde informatie, inclusief cookies die scripts instellen nadat de pagina is geladen.

Hoe vind je mixed content?

Mixed content is elke bron die via HTTP wordt geladen op een pagina die via HTTPS wordt geserveerd, en de browserconsole geeft die weer.

MDN (opent in een nieuw tabblad) verdeelt het in twee groepen. Afbeeldingen, audio en video zijn “upgradable”: browsers vragen ze automatisch via HTTPS op. Scripts, stylesheets, iframes, lettertypen en fetch()-verzoeken zijn “blockable”: browsers blokkeren ze, waardoor alles wat ervan afhing niet meer werkt. Geüpgradede verzoeken naar een kaal IP-adres worden ook geblokkeerd.

Open om het te vinden de console op je belangrijkste templates (homepage, collectie, product, winkelwagen) en doorzoek je themacode, pagina-inhoud en app-instellingen op http://. Volgens het helpcentrum van Shopify wordt elke pagina van een webshop met een asset die niet via HTTPS wordt geleverd als onveilig beschouwd (opent in een nieuw tabblad), en Shopify raadt aan assets op Shopify te hosten of via HTTPS te leveren. Controleer bij WooCommerce oude berichtinhoud en thema-opties als de site ooit op http:// draaide.

Hoe spoor je verouderde JavaScript-bibliotheken met bekende CVE’s op?

Maak een lijst van de bibliotheken die elke pagina laadt, lees hun versies uit en vergelijk die met de National Vulnerability Database.

Begin met jQuery. In de browserconsole geeft $.fn.jquery de geladen versie terug (jQuery API (opent in een nieuw tabblad)). Versies die je moet markeren:

CVEGetroffen versiesProbleemNVD-score (v3.1)
CVE-2020-11022 (opent in een nieuw tabblad)1.12.0 tot vóór 3.5.0Onvertrouwde HTML doorgeven aan methoden zoals .html() of .append() kan code uitvoeren6,1 Medium
CVE-2020-11023 (opent in een nieuw tabblad)1.0.3 tot vóór 3.5.0Hetzelfde, voor HTML met <option>-elementen; sinds 23 januari 2025 in de KEV-catalogus van CISA6,1 Medium
CVE-2019-11358 (opent in een nieuw tabblad)Vóór 3.4.0Prototype pollution via jQuery.extend(true, ...)6,1 Medium

Beide problemen uit 2020 zijn opgelost in jQuery 3.5.0. Een kwetsbare versie betekent dat de gebrekkige code aanwezig is; of die misbruikt kan worden, hangt af van hoe de site er data aan doorgeeft. WordPress levert sinds versie 5.6 (opent in een nieuw tabblad) jQuery 3.5.1 mee, dus een oude jQuery op een WooCommerce-webshop wijst op een verouderde WordPress-installatie of op een thema of plugin die een eigen kopie laadt. Controleer bij Shopify je themabestanden en de apps die scripts injecteren.

Wat is security.txt en heeft je webshop er een nodig?

Het is een tekstbestand dat beveiligingsonderzoekers vertelt hoe ze een kwetsbaarheid aan je kunnen melden.

RFC 9116 (opent in een nieuw tabblad) (april 2022, een Informational RFC, dus het volgen ervan is vrijwillig) zegt dat het bestand via HTTPS moet worden geserveerd op /.well-known/security.txt als text/plain. Contact en Expires zijn verplicht, en de RFC raadt een Expires-datum aan die minder dan een jaar vooruit ligt.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

Bij WooCommerce kun je het bestand op je server zetten. Controleer op een gehost platform of je een bestand op dat pad kunt publiceren; kan dat niet, dan helpt een duidelijk vermeld beveiligingscontact op je contactpagina nog steeds.

Hoe beschermt DMARC je webshop tegen e-mailspoofing?

Met DMARC kun je mailboxproviders vragen om mail die jouw domein in het From-adres gebruikt zonder te slagen voor afgestemde SPF of DKIM, in quarantaine te plaatsen of te weigeren.

Een record op p=none verzamelt alleen rapporten; het houdt gespoofte mail niet tegen. Klanten verwachten orderbevestigingen en wachtwoordresets van jouw domein, dus een phishingbericht dat precies jouw domein toont, is het blokkeren waard. Controleer je beleid met dig +short TXT _dmarc.example.com, en zie RFC 9989 (opent in een nieuw tabblad) voor de specificatie. DMARC dekt geen domeinen die op het jouwe lijken, alleen het domein dat het record publiceert.

Wat beheert Shopify, en wat bepaal je zelf bij WooCommerce?

Shopify beheert de servers achter zijn webwinkels, terwijl bij een zelf gehoste WooCommerce-webshop de serverinstellingen bij jou en je host liggen.

ControleShopifyWooCommerce (zelf gehost)
TLS-certificaatGratis voor alle domeinen die aan Shopify zijn toegevoegd (opent in een nieuw tabblad); kan tot 48 uur duren voor domeinen van derdenJe host of je eigen configuratie
Redirect van HTTP naar HTTPSPlatformInstellingen van webserver, CDN of host
Security headersVerstuurd door de servers van ShopifyWebserver, CDN of een plugin
Cookie-flagsDe eigen cookies van Shopify worden door het platform ingesteld; cookies van apps en thema’s zijn jouw verantwoordelijkheidWordPress-kern, plugins en server
Mixed content en JS-bibliothekenJe thema, content en appsJe thema, content en plugins
security.txt en DMARCJe domein en DNSJe domein en DNS

Toen we in oktober 2026 verschillende door Shopify gehoste webwinkels controleerden, bevatten hun responses HSTS met een max-age van ongeveer 91 dagen, X-Content-Type-Options: nosniff en een CSP met upgrade-insecure-requests, terwijl frame-ancestors per webshop verschilde. Shopify zegt dat het gecertificeerd is als compliant met PCI DSS Level 1 (opent in een nieuw tabblad). Je thema en geïnstalleerde apps blijven jouw verantwoordelijkheid.

Bij WooCommerce zegt de handleiding voor het beveiligen van WordPress (opent in een nieuw tabblad) dat je WordPress en plugins up-to-date moet houden, plugins die je niet gebruikt moet verwijderen en je host moet vragen welke beveiligingsmaatregelen die neemt.

Waarom is dit geen penetratietest?

Een penetratietest voert actief aanvallen uit; passieve checks observeren alleen.

NIST SP 800-115 definieert penetratietesten als beveiligingstests waarbij beoordelaars echte aanvallen nabootsen om manieren te vinden om de beveiligingsfuncties van een systeem te omzeilen (NIST-woordenlijst (opent in een nieuw tabblad)). Passieve checks zien geen fouten aan de serverkant in plugins, zwakke of hergebruikte beheerderswachtwoorden, ontbrekende tweestapsverificatie, gebrekkige toegangscontrole of kwetsbare code die nooit in de paginabron verschijnt. Gebruik ze als basislijn die je op elk moment kunt herhalen. Wil je meer zekerheid, laat dan een penetratietest uitvoeren met een schriftelijk vastgelegde scope, op systemen die van jou zijn of die je mag laten testen.

Een gratis scan doet een eerste ronde over je webshop. Het Websitebeveiligingsrapport behandelt de passieve checks uit dit artikel, van TLS en redirects tot headers, cookies, mixed content, verouderde bibliotheken, security.txt en DMARC, met oplossingen voor elke bevinding. Zoals bij elke passieve controle kan het niet garanderen dat een webshop veilig is.

Veelgestelde vragen

Brengen passieve beveiligingschecks mijn webshop in gevaar?

Niet meer dan een gewoon bezoek. Ze vragen dezelfde openbare pagina’s en DNS-records op die elke browser of mailserver zou opvragen, en ze proberen niet in te loggen of aanvalspayloads te versturen.

Kan ik security headers toevoegen bij Shopify?

De responseheaders van je webwinkel komen van de servers van Shopify, dus neem contact op met Shopify Support als een header die je nodig hebt ontbreekt. Een CSP-<meta>-tag in je thema kan sommige directives toevoegen, maar MDN merkt op dat frame-ancestors niet wordt ondersteund in <meta>.

Betekent een oude jQuery-versie dat mijn webshop is gehackt?

Nee. Het betekent dat er code met bekende kwetsbaarheden wordt geladen, wat het risico verhoogt als de site onvertrouwde HTML aan de getroffen methoden doorgeeft. Werk jQuery bij, of verwijder het thema of de plugin die de oude versie laadt.

Hoe lang mag een TLS-certificaat nu geldig zijn?

Publiek vertrouwde certificaten die vanaf 15 maart 2026 zijn uitgegeven, mogen maximaal 200 dagen geldig zijn. De limiet daalt naar 100 dagen vanaf 15 maart 2027 en naar 47 dagen vanaf 15 maart 2029.

Is een security.txt-bestand verplicht?

RFC 9116 is een Informational RFC, dus het publiceren van het bestand is volgens de standaard vrijwillig. Het kost weinig moeite en geeft onderzoekers een duidelijke manier om je te bereiken.

Betekent een schone passieve scan dat mijn webshop veilig is?

Nee. Het laat zien dat de openbare configuratie er goed uitziet. Kwetsbaarheden aan de serverkant, accountbeveiliging en fouten in de bedrijfslogica vereisen andere tests.

Bronnen