Beveiliging voelt vaak "te technisch", en juist daarom slaan veel kleine organisaties het over. Toch is een veilig gepubliceerde website inmiddels basishygiëne: browsers markeren gewone HTTP-sites als onveilig, en zoekmachines waarderen ze lager. Je hoeft geen beveiligingsexpert te worden — je moet vooral begrijpen wat er onder de motorkap gebeurt. Dat is, net als in de eerste twee lessen, vooral een kwestie van de juiste manier van denken: welke schakel in de keten kan een aanvaller misbruiken, en hoe sluit je die af.

HTTPS en TLS: versleuteling en vertrouwen

De basis is HTTPS, dat alle data tussen browser en server versleutelt met TLS (Transport Layer Security, de opvolger van het oudere SSL — vandaar dat mensen vaak nog "SSL-certificaat" zeggen terwijl technisch TLS wordt gebruikt). Dit voorkomt dat iemand die het netwerkverkeer afluistert — bijvoorbeeld op een openbaar wifi-netwerk — de inhoud ongemerkt kan lezen of manipuleren. Zonder HTTPS zou een aanvaller op hetzelfde wifi-netwerk in theorie kunnen meelezen wanneer een klant een bestelling plaatst of inloggegevens invoert.

TLS steunt op een vertrouwensketen (chain of trust): een root-certificaatautoriteit (CA) ondertekent een tussenliggende CA, die op haar beurt jouw certificaat ondertekent. De browser vertrouwt de keten als die terug te herleiden is tot een bekende root-autoriteit die standaard in elke browser is ingebouwd. Zodra één schakel in die keten ontbreekt of niet klopt, toont de browser een waarschuwing — een signaal dat bezoekers serieus moeten nemen, en dat jij als beheerder nooit moet negeren of wegklikken op je eigen site.

Certificaten in de praktijk: automatisering met Let's Encrypt

Dit hoeft in de praktijk niet ingewikkeld te zijn. Een reverse proxy zoals Caddy regelt HTTPS automatisch via gratis certificaten van Let's Encrypt, inclusief HTTP/2, met minimale configuratie (de Caddyfile). Een werkbare workflow: schrijf een Caddyfile met je domeinnaam, draai deze in een container (zie de vorige les), en je site is binnen enkele minuten versleuteld en online — inclusief automatische vernieuwing van het certificaat, zodat je er niet handmatig aan hoeft te denken.

Een kleine, praktische Caddyfile ziet er bijvoorbeeld zo uit:

voorbeeldbedrijf.nl {
    reverse_proxy localhost:8080
}

Meer hoeft er in veel gevallen niet bij — Caddy vraagt zelf een geldig certificaat aan zodra het domein bereikbaar is, en vernieuwt dat automatisch voordat het verloopt.

HTTPS bij Nederlandse hostingpartijen

Werk je liever niet met een eigen Caddy-container, dan regelen de meeste Nederlandse hostingpartijen dit ook automatisch. Partijen als TransIP, Antagonist en Vimexx bieden op vrijwel elk hostingpakket gratis Let's Encrypt-certificaten aan die automatisch worden aangevraagd en vernieuwd via het klantenpaneel — vaak met één schakelaar, zonder dat je zelf configuratie hoeft te schrijven. Vraag bij een managed platform (bijvoorbeeld WooCommerce- of Odoo-hosting bij een Nederlandse partij) expliciet na of HTTPS standaard actief is op élk domein en subdomein, inclusief zowel de www- als de niet-www-variant — een vergeten variant is een veelvoorkomende oorzaak van een waarschuwingsicoon dat toch nog verschijnt.

Meer dan versleuteling: de OWASP Top 10

Versleuteling alleen is niet genoeg. De OWASP Top 10 is een door de internationale beveiligingsgemeenschap onderhouden lijst van de tien meest kritieke webrisico's. Voor kleinere sites zijn met name injectie (zoals SQL-injectie en XSS, waarbij een aanvaller kwaadaardige code invoert via een formulierveld), gebroken authenticatie (zwakke wachtwoordregels, geen tweestapsverificatie) en verkeerd ingestelde beveiliging (standaardwachtwoorden nooit gewijzigd, onnodige poorten open) relevant. Je hoeft de hele lijst niet uit je hoofd te kennen; het is genoeg om te weten dat ze bestaat en om bij twijfel de actuele lijst op owasp.org te raadplegen.

HTTP-beveiligingsheaders: extra lagen bescherming

Je versterkt elke site verder met HTTP-beveiligingsheaders — kleine instructies die de server meestuurt en die de browser vertellen hoe hij zich moet gedragen:

• Content-Security-Policy (CSP) — bepaalt welke scripts, stijlen en afbeeldingen mogen laden; de sterkste verdediging tegen XSS-aanvallen.
• Strict-Transport-Security (HSTS) — dwingt browsers altijd via HTTPS te verbinden en voorkomt zogeheten downgrade-aanvallen naar onversleuteld HTTP.
• X-Frame-Options en X-Content-Type-Options — beschermen respectievelijk tegen clickjacking (je site verstopt tonen in een onzichtbaar frame op een andere site) en tegen het verkeerd interpreteren van bestandstypen.

Wat betekent dit voor een MKB-website of webshop?

Concreet, voor een Nederlandse ondernemer met een eigen website of webshop: zorg dat HTTPS overal actief is (geen enkele pagina meer op onversleuteld http://), controleer of je hostingpartij of CMS de beveiligingsheaders standaard meestuurt, en wees extra alert bij formulieren waar klantgegevens binnenkomen — denk aan een bestelformulier met adresgegevens, wat onder de AVG als persoonsgegevens geldt en dus zorgvuldig en versleuteld verwerkt moet worden. Bij twijfel over wat de AVG precies vereist voor jouw specifieke situatie is het verstandig een adviseur te raadplegen die gespecialiseerd is in privacywetgeving.

Ook bij iDEAL-betalingen in een webshop speelt vertrouwen een rol: de betaaldienstverlener (bijvoorbeeld Mollie of een vergelijkbare partij) regelt de daadwerkelijke betaalverwerking, maar de pagina waarop de klant zijn bestelling plaatst en zijn gegevens invoert, moet zelf ook altijd via HTTPS lopen. Een webshop die op één pagina nog onversleuteld http:// toont — al is het maar een productpagina — ondermijnt het vertrouwen dat de rest van de site zorgvuldig heeft opgebouwd, en browsers laten dat inmiddels ook expliciet zien met een waarschuwingsicoon in de adresbalk.

Samenvatting en verder lezen

HTTPS/TLS versleutelt het verkeer tussen browser en server en steunt op een vertrouwensketen van certificaatautoriteiten; tools als Caddy maken het automatiseren van certificaten laagdrempelig. Daarnaast bestaan er bekende risicocategorieën (OWASP Top 10) en extra beveiligingsheaders die je site verder versterken. In de volgende les bouwen we hierop voort met cloud-basisconcepten, waar dezelfde vragen over vertrouwen en configuratie terugkomen op een grotere schaal.

Verder lezen: owasp.org voor de actuele Top 10, en de documentatie op caddyserver.com voor meer voorbeelden van Caddyfiles.