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
- Publiek vertrouwde TLS-certificaten die sinds 15 maart 2026 zijn uitgegeven, mogen maximaal 200 dagen geldig zijn; dat wordt 100 dagen in maart 2027 en 47 dagen in maart 2029 (CA/Browser Forum (opent in een nieuw tabblad)).
- Browsers negeren de HSTS-header als die via gewone HTTP wordt verstuurd (MDN (opent in een nieuw tabblad)).
- De CSP-directive
frame-ancestorswerkt niet in een<meta>-tag; die moet als responseheader worden verstuurd (MDN (opent in een nieuw tabblad)). - jQuery-versies vóór 3.5.0 hebben last van twee XSS-kwetsbaarheden, en CISA heeft een daarvan, CVE-2020-11023, op 23 januari 2025 toegevoegd aan de catalogus Known Exploited Vulnerabilities (NVD (opent in een nieuw tabblad)).
- Een
security.txt-bestand moet de veldenContactenExpiresbevatten en op/.well-known/security.txtstaan (RFC 9116 (opent in een nieuw tabblad)).
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 uitgegeven | Maximale geldigheid |
|---|---|
| Vóór 15 maart 2026 | 398 dagen |
| 15 maart 2026 tot en met 14 maart 2027 | 200 dagen |
| 15 maart 2027 tot en met 14 maart 2029 | 100 dagen |
| Vanaf 15 maart 2029 | 47 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.
| Header | Wat de header doet | Gebruikelijke waarde | Bron |
|---|---|---|---|
Strict-Transport-Security | Vertelt browsers dat ze alleen HTTPS mogen gebruiken en voorkomt dat gebruikers certificaatfouten wegklikken | max-age=31536000; includeSubDomains | MDN (opent in een nieuw tabblad) |
Content-Security-Policy: frame-ancestors | Bepaalt welke sites je pagina’s mogen insluiten, wat beschermt tegen clickjacking | frame-ancestors 'self' | MDN (opent in een nieuw tabblad) |
X-Frame-Options | Oudere manier om framing te beheren; volgens OWASP maakt frame-ancestors deze header overbodig in browsers die het ondersteunen | DENY of SAMEORIGIN | OWASP (opent in een nieuw tabblad) |
X-Content-Type-Options | Voorkomt MIME-sniffing en blokkeert scripts en stylesheets die met het verkeerde type worden geserveerd | nosniff | MDN (opent in een nieuw tabblad) |
Referrer-Policy | Beperkt hoeveel van je URL’s naar andere sites wordt gestuurd | strict-origin-when-cross-origin | OWASP |
X-XSS-Protection | Header voor het XSS-filter van de browser; volgens OWASP kan die XSS-kwetsbaarheden veroorzaken in sites die anders veilig zijn | Niet instellen, of 0 | OWASP |
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.
| Attribuut | Effect (volgens MDN (opent in een nieuw tabblad)) | Waar het ertoe doet |
|---|---|---|
Secure | Wordt alleen via HTTPS verstuurd; sites op gewone HTTP kunnen het niet instellen | Elke cookie op een webshop met HTTPS |
HttpOnly | JavaScript kan de cookie niet lezen via document.cookie, wat helpt tegen XSS | Inlogsessies en winkelwagens |
SameSite=Lax of Strict | Beperkt wanneer de cookie bij cross-site verzoeken wordt meegestuurd | Sessies; Strict past bij authenticatie- en winkelwagencookies |
SameSite=None | Wordt bij cross-site verzoeken meegestuurd; moet worden gecombineerd met Secure | Alleen 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:
| CVE | Getroffen versies | Probleem | NVD-score (v3.1) |
|---|---|---|---|
| CVE-2020-11022 (opent in een nieuw tabblad) | 1.12.0 tot vóór 3.5.0 | Onvertrouwde HTML doorgeven aan methoden zoals .html() of .append() kan code uitvoeren | 6,1 Medium |
| CVE-2020-11023 (opent in een nieuw tabblad) | 1.0.3 tot vóór 3.5.0 | Hetzelfde, voor HTML met <option>-elementen; sinds 23 januari 2025 in de KEV-catalogus van CISA | 6,1 Medium |
| CVE-2019-11358 (opent in een nieuw tabblad) | Vóór 3.4.0 | Prototype 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.
| Controle | Shopify | WooCommerce (zelf gehost) |
|---|---|---|
| TLS-certificaat | Gratis voor alle domeinen die aan Shopify zijn toegevoegd (opent in een nieuw tabblad); kan tot 48 uur duren voor domeinen van derden | Je host of je eigen configuratie |
| Redirect van HTTP naar HTTPS | Platform | Instellingen van webserver, CDN of host |
| Security headers | Verstuurd door de servers van Shopify | Webserver, CDN of een plugin |
| Cookie-flags | De eigen cookies van Shopify worden door het platform ingesteld; cookies van apps en thema’s zijn jouw verantwoordelijkheid | WordPress-kern, plugins en server |
| Mixed content en JS-bibliotheken | Je thema, content en apps | Je thema, content en plugins |
| security.txt en DMARC | Je domein en DNS | Je 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
- Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1 (opent in een nieuw tabblad), CA/Browser Forum, 4 oktober 2026
- Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (opent in een nieuw tabblad), CA/Browser Forum, 11 april 2025
- Strict-Transport-Security (opent in een nieuw tabblad), MDN Web Docs, laatst gewijzigd op 11 september 2026
- CSP: frame-ancestors (opent in een nieuw tabblad), MDN Web Docs, laatst gewijzigd op 27 augustus 2026
- X-Content-Type-Options (opent in een nieuw tabblad), MDN Web Docs, laatst gewijzigd op 17 maart 2026
- Using HTTP cookies (opent in een nieuw tabblad), MDN Web Docs, laatst gewijzigd op 17 september 2026
- Mixed content (opent in een nieuw tabblad), MDN Web Docs, laatst gewijzigd op 15 augustus 2026
- HTTP Security Response Headers Cheat Sheet (opent in een nieuw tabblad), OWASP Cheat Sheet Series, geraadpleegd op 22 oktober 2026
- CVE-2020-11022 (opent in een nieuw tabblad), NIST National Vulnerability Database, gepubliceerd op 29 april 2020
- CVE-2020-11023 (opent in een nieuw tabblad), NIST National Vulnerability Database, gepubliceerd op 29 april 2020
- CVE-2019-11358 (opent in een nieuw tabblad), NIST National Vulnerability Database, gepubliceerd op 20 april 2019
- .jquery (opent in een nieuw tabblad), jQuery API Documentation, geraadpleegd op 22 oktober 2026
- Updating core jQuery to version 3, part 2 (opent in een nieuw tabblad), Make WordPress Core, 5 november 2020
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (opent in een nieuw tabblad), IETF, april 2022
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (opent in een nieuw tabblad), IETF, mei 2026
- Enabling secure connections to your Shopify store (opent in een nieuw tabblad), Shopify Help Center, geraadpleegd op 22 oktober 2026
- Security (opent in een nieuw tabblad), Shopify, geraadpleegd op 22 oktober 2026
- Hardening WordPress (opent in een nieuw tabblad), WordPress Developer Resources, geraadpleegd op 22 oktober 2026
- Penetration testing (glossary) (opent in een nieuw tabblad), NIST Computer Security Resource Center, met verwijzing naar NIST SP 800-115 (september 2008), geraadpleegd op 22 oktober 2026
Alle handleidingen
- ADA-sommatiebrief over je website? Dit controleer je eerstWat een ADA-sommatiebrief stelt, de rol van WCAG, wat je verzamelt, waarom overlays niet helpen en wanneer je een advocaat belt. Geen juridisch advies.
- Checklist voor productpagina’s: waarom klanten afhakenChecklist voor productpagina’s volgens Baymard en WebAIM: prijs, verzending en retour, foto’s, reviews, knop op mobiel, pop-ups, zoeken en toetsenbord.
- Core Web Vitals voor webshops: LCP, INP en CLS uitgelegdWat LCP, INP en CLS meten, de drempels bij het 75e percentiel, labdata versus velddata en de gangbare oplossingen voor Shopify- en WooCommerce-webshops.