9 min lezen

Website beveiliging controleren met een praktische checklist

Website beveiliging controleren hoeft niet vaag of overweldigend te zijn. Met een vaste checklist zie je snel waar belangrijke publieke beveiligingssignalen ontbreken, zonder dat je meteen een dure pentest nodig hebt. Dit artikel loopt langs HTTPS, security headers en e-mailbeveiliging en geeft per onderdeel concrete controles die je vandaag al kunt uitvoeren. Wil je liever niet handmatig beginnen? Met een gratis CheckBorg-scan zie je in een paar minuten welke punten op jouw domein aandacht verdienen.

Wat je met deze checklist wel en niet controleert

Het is goed om eerst de scope eerlijk vast te leggen. Deze checklist richt zich op publiek zichtbare beveiligingssignalen: dingen die iedereen aan de buitenkant van je website en domein kan meten. Denk aan een geldig SSL-certificaat, een correcte HTTPS-doorverwijzing, security headers in je serverantwoorden en de DNS-records die bepalen wie namens jouw domein e-mail mag versturen. Dit zijn precies de onderdelen die klanten, Google en geautomatiseerde scanners als eerste tegenkomen.

Wat je hiermee niet controleert, is minstens zo belangrijk om te benoemen. Een goede score op deze checklist zegt niets over verouderde plugins, zwakke wachtwoorden, SQL-injecties, lekken in je CMS of misconfiguraties in je serverbeheer. Die vragen om een diepere, vaak handmatige beoordeling of een echte penetratietest. Zie deze checklist daarom als de basishygiëne: noodzakelijk, maar niet voldoende als enige maatregel.

Voor mkb-ondernemers is dit onderscheid praktisch. Je kunt met deze controles zelfstandig de meest voorkomende en zichtbare zwakke plekken afvangen, en pas een specialist inschakelen voor het diepere werk. Voor webbureaus is het een handige standaard om bij elke oplevering en bij periodiek onderhoud langs te lopen, zodat je niets vergeet en het richting de klant aantoonbaar maakt.

Begin met HTTPS en je SSL-certificaat

De eerste stap bij website beveiliging controleren is altijd de verbinding zelf. Controleer of je website over HTTPS draait, of het SSL-certificaat geldig is en of het van een vertrouwde uitgever komt. Een verlopen of verkeerd geïnstalleerd certificaat zorgt voor browserwaarschuwingen die bezoekers direct afschrikken, ongeacht hoe goed de rest van je site is.

Kijk daarnaast naar de doorverwijzingen. Alle varianten van je domein, dus met en zonder www en de http-versie, horen automatisch en zonder omwegen op één HTTPS-adres uit te komen. Een veelgemaakte fout is dat de homepage netjes naar HTTPS gaat, maar dat oude links of een specifiek subdomein nog op een onversleutelde verbinding blijven hangen. Dat is precies het soort gat dat je bij een snelle handmatige test makkelijk over het hoofd ziet.

Let ook op de geldigheidsduur. Veel certificaten, zeker gratis varianten via Let's Encrypt, lopen elke 90 dagen af en horen automatisch te vernieuwen. Controleer of die vernieuwing daadwerkelijk werkt, want een mislukte auto-renew is een klassieke oorzaak van een plotseling onbereikbare of als onveilig gemarkeerde site. Noteer de vervaldatum of laat monitoring je hierop attenderen, zodat je nooit verrast wordt.

Controleer je security headers

Security headers zijn instructies die je server meestuurt en die de browser vertellen hoe hij veiliger met jouw pagina moet omgaan. Ze kosten niets, maar worden op heel veel websites simpelweg vergeten. De belangrijkste om te controleren zijn HSTS (dwingt HTTPS af), Content-Security-Policy (beperkt welke scripts en bronnen mogen laden), X-Frame-Options (voorkomt clickjacking via iframes), Referrer-Policy en Permissions-Policy.

De waarde van headers zit in de details, dus controleer niet alleen of ze aanwezig zijn maar ook of ze zinnig zijn ingesteld. Een Content-Security-Policy die alles toestaat biedt nauwelijks bescherming, en een HSTS-header met een hele korte geldigheidsduur stelt weinig voor. Tegelijk is voorzichtigheid geboden: vooral CSP kan formulieren, betaalflows, analytics of chatwidgets breken als externe bronnen niet correct zijn opgenomen.

Voer headerwijzigingen daarom altijd gefaseerd door. Begin met de veilige, onschuldige headers zoals X-Frame-Options en Referrer-Policy, en bewaar CSP voor het laatst, eventueel eerst in report-only modus zodat je ziet wat er geblokkeerd zou worden zonder dat er echt iets stukgaat. Test na elke wijziging de belangrijke functionaliteit. Een CheckBorg-scan laat in één oogopslag zien welke headers ontbreken of zwak zijn ingesteld, zodat je gericht kunt prioriteren.

Vergeet je e-mailbeveiliging niet

E-mailbeveiliging valt buiten de website zelf, maar hoort wel bij het controleren van je domein, want misbruik raakt direct je merk en je klanten. Drie DNS-records doen hier het werk: SPF bepaalt welke servers namens jouw domein mogen verzenden, DKIM zet een digitale handtekening op je berichten, en DMARC vertelt ontvangende mailservers wat ze moeten doen met berichten die niet door SPF of DKIM komen.

Zonder deze records is je domein een aantrekkelijk doelwit voor spoofing: kwaadwillenden sturen dan phishingmails die lijken te komen van jouw bedrijf. Klanten die zo'n nepmail ontvangen, geven jou de schuld, ook al heb je er technisch niets mee te maken. Goed ingestelde SPF, DKIM en DMARC maken dat veel moeilijker en verbeteren bovendien de afleverbaarheid van je échte e-mail.

Wees voorzichtig met de strengheid van DMARC. Een DMARC-beleid op reject is het sterkst, maar pas zodra je zeker weet dat alle legitieme verzenders, denk aan je nieuwsbrieftool, CRM, facturatiesysteem en eventuele externe leveranciers, correct zijn opgenomen in SPF en DKIM. Begin daarom met een beleid op none en monitor de rapporten, schakel daarna naar quarantine en pas als laatste naar reject. Zo voorkom je dat je per ongeluk je eigen post tegenhoudt.

Maak controleren een terugkerende gewoonte

Website beveiliging controleren is geen eenmalige actie maar een terugkerend onderdeel van onderhoud. Beveiligingssignalen veranderen: certificaten lopen af, een nieuwe marketingtool wijzigt onbedoeld je DNS, een plugin-update overschrijft serverinstellingen, of een collega zet een testsubdomein online zonder HTTPS. Wat vandaag in orde is, kan over twee maanden een gat hebben.

Leg daarom vast wie waarvoor verantwoordelijk is. Vaak zijn er meerdere partijen betrokken: een hostingpartij, een webbureau en intern iemand voor marketing of tooling. Documenteer welke partij welke onderdelen opvolgt, en leg DNS- en securitywijzigingen vast inclusief datum, zodat je bij problemen snel kunt terugrollen. Een simpel logboek voorkomt urenlang zoekwerk wanneer er iets misgaat.

Voor mkb-bedrijven werkt een vaste maand- of kwartaalcontrole goed: loop de checklist langs, controleer certificaatdata, headers en DNS-records, en bewaar de uitkomst. Voor webbureaus is een herhaalbare scan bovendien een manier om onderhoudswaarde aantoonbaar te maken richting klanten. Een terugkerende CheckBorg-scan levert telkens een vergelijkbaar rapport, zodat je verbetering of achteruitgang over de tijd zichtbaar kunt maken zonder dat het handwerk wordt.

Praktische checklist

Controleer eerst of alle varianten van je domein (met en zonder www, en http) automatisch en zonder omwegen doorverwijzen naar één HTTPS-versie.

Controleer de geldigheid en vervaldatum van je SSL-certificaat en verifieer dat automatische vernieuwing daadwerkelijk werkt.

Inventariseer je aanwezige security headers en kijk niet alleen of ze er zijn, maar ook of ze zinnig zijn ingesteld.

Voeg ontbrekende headers gefaseerd toe: eerst de veilige basis, daarna pas CSP, eventueel eerst in report-only modus.

Test na elke headerwijziging je formulieren, betaalflows, embedded content, analytics en externe scripts.

Inventariseer alle diensten die namens je domein e-mail verzenden voordat je SPF, DKIM en DMARC strenger maakt.

Documenteer elke DNS- en securitywijziging met datum, zodat je bij problemen snel kunt terugrollen.

Plan een terugkerende controle (maandelijks of per kwartaal) en bewaar de rapporten om verandering over tijd te volgen.

Veelgemaakte fouten

  • - Een geldig SSL-certificaat zien als bewijs dat de hele website veilig is, terwijl het alleen de verbinding versleutelt.
  • - Aannemen dat de hele site op HTTPS draait omdat de homepage doorverwijst, terwijl oude links of een subdomein nog onversleuteld zijn.
  • - Content-Security-Policy te streng live zetten zonder report-only of testfase, waardoor formulieren of betaalflows breken.
  • - Headers uit een willekeurig voorbeeld kopiëren zonder rekening te houden met je eigen hosting, CDN en applicatie.
  • - DMARC direct op reject zetten terwijl nieuwsbrieftool, CRM of facturatie nog niet correct in SPF en DKIM staan, waardoor legitieme mail wordt geblokkeerd.
  • - Beveiliging eenmalig controleren en daarna nooit meer, waardoor verlopen certificaten of gewijzigde DNS-records onopgemerkt blijven.

Veelgestelde vragen

Is een automatische scan genoeg om mijn website beveiliging te controleren?

Voor de basiscontrole van publieke signalen zoals HTTPS, security headers en e-mailrecords is een geautomatiseerde scan prima. Het is alleen geen vervanging van een volledige penetratietest, die ook naar verouderde software, wachtwoorden en applicatielekken kijkt. Zie de scan als noodzakelijke basishygiëne, niet als eindpunt.

Hoe vaak moet ik mijn website beveiliging controleren?

Controleer in elk geval na elke grote wijziging, zoals een migratie, redesign of nieuwe tool. Daarnaast is een periodieke controle per maand of kwartaal verstandig, omdat certificaten verlopen en DNS-records ongemerkt kunnen wijzigen. Monitoring helpt om problemen te zien voordat bezoekers of klanten ze melden.

Wat is het verschil tussen een SSL-certificaat en echte website beveiliging?

Een SSL-certificaat versleutelt alleen de verbinding tussen browser en server, zodat meelezen lastig wordt. Het zegt niets over de veiligheid van je CMS, plugins, wachtwoorden of formulieren. Een geldig certificaat is dus een noodzakelijke basis, maar geen bewijs dat je hele website veilig is.

Kan ik security headers zelf instellen of heb ik een specialist nodig?

De veilige basisheaders zoals X-Frame-Options en Referrer-Policy kun je vaak zelf via hosting, webserver of CDN instellen. Wees voorzichtiger met Content-Security-Policy, want die kan functionaliteit breken; test die eerst in report-only modus of laat hem door iemand met ervaring instellen.

Is e-mailbeveiliging echt onderdeel van mijn website beveiliging?

E-mailbeveiliging staat los van de website, maar hoort wel bij het beveiligen van je domein. Zonder correcte SPF, DKIM en DMARC kunnen anderen phishingmails versturen die van jouw bedrijf lijken te komen. Dat raakt direct je merk en je klanten, dus het hoort bij elke serieuze controle.

Hoe begin ik snel als ik niet technisch ben?

Start met een gratis CheckBorg-scan: die meet in een paar minuten de publieke beveiligingssignalen van je domein en laat zien welke punten aandacht verdienen. Daarna kun je per onderdeel beslissen wat je zelf oppakt en waarvoor je je hoster of webbureau inschakelt.

Verder lezen

Gerelateerde gidsen

Verdiep je verder in websitekwaliteit, vindbaarheid en conversie voordat je de volgende scan draait.

7 min lezen

Structured data voor AI: welke schema-markup helpt ChatGPT je begrijpen

Schema.org-markup vertelt zoekmachines en AI wat je content betekent. Welke types tellen voor AI-vindbaarheid, en hoe pak je het aan zonder developer?

Lees verder

6 min lezen

In Google AI Overviews komen: wat het is en hoe je je kans vergroot

Google toont steeds vaker een AI-samenvatting boven de zoekresultaten. Wat zijn AI Overviews, hoe kiest Google de bronnen, en hoe vergroot je de kans dat jij wordt aangehaald?

Lees verder

6 min lezen

E-E-A-T uitgelegd: waarom Google en AI vertrouwen meewegen

E-E-A-T (ervaring, expertise, autoriteit, betrouwbaarheid) bepaalt mede of Google en AI je content vertrouwen. Wat is het, en hoe maak je het zichtbaar op je site?

Lees verder

Wil je direct zien waar jouw website staat?

Start een veilige CheckBorg scan en vertaal technische signalen naar duidelijke prioriteiten.

Start gratis scan