Website beveiligen: een praktische gids

Een website beveiligen is geen eenmalige actie. Het is een doorlopend proces van laagjes: technische maatregelen, configuratie, monitoring en onderhoud. Veel organisaties denken dat een SSL-certificaat voldoende is. Dat is het beginpunt, niet het eindpunt.

In deze gids behandelen we de maatregelen die er daadwerkelijk toe doen. Geen academische opsomming, maar wat je concreet moet regelen om je website te beschermen tegen de meest voorkomende aanvallen.

Het basisniveau: wat elke website moet hebben

HTTPS overal

HTTPS is niet optioneel meer. Zonder SSL/TLS-certificaat markeren browsers je site als onveilig, vertrouwen zoekmachines je minder en is elk datapunt dat via je formulieren binnenkomt kwetsbaar voor onderschepping.

Een certificaat is niet duur – Let's Encrypt geeft ze gratis weg en goede hostingproviders zetten dit standaard op. Maar er zijn twee dingen die regelmatig misgaan: certificaten verlopen zonder dat iemand het merkt (resultaat: foutpagina voor alle bezoekers), en mixed content (een HTTPS-pagina met HTTP-bronnen) die de beveiliging ondergraaft.

Zorg voor automatische verlenging en scan periodiek op mixed content. En gebruik HTTP Strict Transport Security (HSTS) om browsers te dwingen altijd HTTPS te gebruiken, ook als een gebruiker http:// intypt.

Beveiligde headers

HTTP-headers zijn een laag beveiliging die veel websites missen, terwijl ze goedkoop te implementeren zijn. De belangrijkste:

• Content-Security-Policy (CSP) – bepaalt welke scripts, stylesheets en andere bronnen je pagina mag laden. Blokkeert cross-site scripting (XSS) aanvallen effectief als goed geconfigureerd.
• X-Frame-Options – voorkomt dat je site in een iframe op een andere site geladen wordt (clickjacking-bescherming).
• X-Content-Type-Options – voorkomt dat browsers MIME-sniffing toepassen op je bestanden.
• Referrer-Policy – regelt welke informatie je browser meestuurt als een gebruiker van je site naar een andere site navigeert.

Check je huidige headers via securityheaders.com. Een C of D is normaal voor een ongeoptimaliseerde site – dat geeft direct inzicht in wat er nog ontbreekt.

Toegang en authenticatie

Sterk wachtwoordbeleid en MFA

Brute-force aanvallen op inlogpagina's zijn dagelijkse routine. Als je WordPress draait met standaard /wp-admin, Joomla met /administrator, of een ander populair CMS, wordt je loginpagina meerdere keren per dag geprobeerd.

Minimale maatregelen: beperk het aantal inlogpogingen (brute-force beperking), gebruik lange, unieke wachtwoorden en activeer multi-factor authenticatie voor alle beheeraccounts. Dat laatste haalt de meeste geautomatiseerde aanvallen er al direct uit.

Minimaal rechtenbeheer

Geef accounts alleen de rechten die ze nodig hebben. Redacteuren hoeven geen volledige administratortoegang. FTP-accounts voor specifieke mappen hoeven geen schrijftoegang tot de hele server. Dit klinkt vanzelfsprekend, maar in de praktijk zien we dikwijls setups waarbij iedereen beheerdersrechten heeft "voor het gemak".

Verwijder ook oude accounts. Medewerkers die weg zijn, agencies die het project hebben afgerond, testers die toegang kregen – die accounts moeten weg. Ze zijn een open deur voor aanvallers die gestolen credentials proberen.

Web Application Firewall (WAF)

Een WAF filtert inkomend verkeer op applicatieniveau. Waar een gewone firewall kijkt naar IP-adressen en poorten, kijkt een WAF naar de inhoud van het verkeer. SQL injection, cross-site scripting, directory traversal – een WAF herkent deze aanvalspatronen en blokkeert ze voordat ze je applicatie bereiken.

Voor de meeste websites is een cloudgebaseerde WAF de praktische keuze. Cloudflare, Sucuri en vergelijkbare diensten zitten tussen de gebruiker en jouw server in. Ze verwerken het verkeer, filteren kwaadaardige verzoeken en sturen alleen legitiem verkeer door. Bijkomend voordeel: ze fungeren ook als CDN, wat je laadtijden verbetert.

Een WAF is geen vervanging voor veilige code. Als je applicatie een SQL injection-kwetsbaarheid heeft, wil je die repareren, niet alleen de aanvallen eromheen filteren. Maar een WAF geeft je wel een extra verdedigingslaag en koopt je tijd als er een zero-day-kwetsbaarheid ontdekt wordt in software die je gebruikt.

Patching en updates

De meeste succesvolle aanvallen op websites maken gebruik van bekende kwetsbaarheden in verouderde software. WordPress-plugins, Joomla-componenten, PHP-versies, server-software – het aanvalsoppervlak is groot als je achterloopt met updates.

Stel automatische updates in voor je CMS-core en plugins waar dat mogelijk is. Houd je PHP-versie bij: PHP 8.1 en ouder ontvangen geen beveiligingsupdates meer. Test updates eerst in een staging-omgeving voor kritieke productiesites, maar stel ze niet weken uit.

Voor server-software: Ubuntu LTS en RHEL/CentOS hebben beveiligingsupdates voor meerdere jaren. Gebruik unattended-upgrades of vergelijkbare tools voor automatische beveiligingspatches. Zorg dat je weet welke softwareversies er draaien en wanneer de support eindigt.

Back-ups die ook werken

Back-ups zijn de meest onderschatte beveiligingsmaatregel. Ze helpen niet tegen een actieve aanval, maar ze zijn de reden waarom je na een aanval binnen uren online bent in plaats van dagen.

Drie principes voor back-ups die daadwerkelijk helpen:

Offsite opslag. Als je back-up op dezelfde server staat als je site, is die back-up weg als de server gecompromitteerd wordt. Sla back-ups op een ander systeem op, bij voorkeur op een andere locatie.

Testen. Een back-up die je nog nooit hebt teruggezet is een back-up waarvan je niet weet of die werkt. Doe periodiek een hersteltest. Niet eens per jaar, maar minimaal ieder kwartaal.

Bewaarperiode. Ransomware kan wekenlang slapend aanwezig zijn voordat het toeslaat. Als je alleen dagelijkse back-ups hebt van de afgelopen week, zijn al die back-ups al geïnfecteerd. Bewaar back-ups minstens 30 dagen, voor kritieke systemen langer.

Monitoring en detectie

Beveiliging zonder monitoring is hopen dat er niks gebeurt. Monitoring geeft je de signalen om te reageren voordat een incident uitloopt op een crisis.

Minimaal wil je:

• Uptime-monitoring met alerts als je site onbereikbaar is
• Loginmonitoring met meldingen bij mislukte pogingen of ongebruikelijke tijden
• Bestandsintegriteitschecks die je waarschuwen als er iets in je applicatiebestanden is gewijzigd
• SSL-certificaatmonitoring zodat je op tijd vernieuwt of gewaarschuwd wordt bij problemen

Voor organisaties die onder NIS2 vallen of met gevoelige data werken, is een Security Information and Event Management (SIEM)-systeem de volgende stap. Dat centraliseert logs en geeft je correlatie tussen events – zodat je een patroon ziet dat je met losse tools zou missen.

Waar beginnen?

Als je een prioriteitenlijst wilt, begin hier:

1. HTTPS op alle pagina's, met automatische certificaatverlenging en HSTS
2. MFA op alle beheeraccounts
3. Automatische updates voor CMS en plugins
4. Offsite back-ups met bewaarperiode van minimaal 30 dagen
5. Beveiligde HTTP-headers (CSP, X-Frame-Options, HSTS)
6. WAF als je budget en risicoprofiel dat rechtvaardigen
7. Monitoring op beschikbaarheid, logins en bestandswijzigingen

Dat is geen lijst die je in een middag afrkt, maar het zijn maatregelen met een hoge risicoreductie per geïnvesteerd uur. De organisaties die dit op orde hebben, zijn significant moeilijker te compromitteren dan de gemiddelde website die alleen een SSL-certificaat heeft.

Beveiliging is nooit af. Maar een goed basisniveau scheidt de organisaties die een incident overleven van de organisaties die ermee op het nieuws komen.

Hulp nodig bij het beveiligen van je website? Bekijk onze compliance-oplossingen.