Websitebeveiliging: de praktijkgids
De meeste websites worden niet doelgericht aangevallen. Ze worden gevonden door geautomatiseerde scanners die het hele internet aftasten op bekende kwetsbaarheden en zwakke wachtwoorden. Dat is goed nieuws, want het betekent dat basismaatregelen het merendeel van de aanvallen tegenhouden.
Deze gids behandelt die maatregelen, ruwweg op volgorde van hoeveel risico ze wegnemen per bestede inspanning.
Toegang: waar de meeste inbraken beginnen#
Gestolen of geraden inloggegevens zijn de meest voorkomende manier waarop kleine sites vallen — vaker dan enige technische kwetsbaarheid.
- Tweefactorauthenticatie op elk beheerdersaccount, zonder uitzondering.
- Unieke wachtwoorden uit een wachtwoordbeheerder; hergebruikte wachtwoorden lekken elders en worden hier getest.
- Verwijder accounts van vertrokken medewerkers en oude bureaus — dit wordt vrijwel altijd vergeten.
- Geef de minimale rechten die iemand nodig heeft; een redacteur hoeft geen beheerder te zijn.
- Beperk aanmeldpogingen en blokkeer bij herhaalde mislukkingen.
- Bescherm ook de omliggende toegang: hosting, DNS, domeinregistrar en e-mail. Verlies van DNS is erger dan verlies van de site.
- Gebruik SFTP of SSH-sleutels, nooit gewone FTP met een wachtwoord.
De domeinregistrar is het account dat het vaakst zonder tweefactor blijft en de meeste schade aanricht als hij valt.
Updates en het aanvalsoppervlak#
Elk stuk software dat je installeert is een stuk dat bijgewerkt moet blijven. Het goedkoopste beveiligingswerk is verwijderen wat je niet gebruikt.
| Maatregel | Waarom het telt |
|---|---|
| CMS-kern actueel | Bekende lekken worden binnen dagen na publicatie gescand |
| Plug-ins actueel | De meest voorkomende toegangsweg op WordPress-sites |
| Ongebruikte plug-ins verwijderen | Gedeactiveerd is niet veilig; de code staat er nog |
| Ongebruikte thema's verwijderen | Zelfde reden, wordt nog vaker vergeten |
| Ondersteunde PHP-versie | Verouderde versies krijgen geen beveiligingspatches meer |
| Serverpakketten actueel | Hoort bij de host bij beheerde hosting — controleer dat |
| Afhankelijkheden in maatwerk | Bibliotheken verouderen ook; controleer ze in de build |
Voer updates uit op een testomgeving en test daarna de formulieren en, bij een shop, het afrekenpad. Een update die stilletjes een formulier breekt is een eigen soort storing.
Applicatie- en serverbescherming#
De maatregelen die technische kwetsbaarheden afdekken in plaats van toegang.
- Valideer en ontsmet alle invoer aan de serverzijde. Controle in de browser is gebruiksgemak, geen beveiliging.
- Gebruik voorbereide query's voor elke databasetoegang — dit sluit SQL-injectie af.
- Ontsnap uitvoer bij weergave om cross-site scripting te voorkomen.
- HTTPS overal, met HSTS, en een automatisch verlengend certificaat.
- Zet beveiligingskopteksten: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy.
- Beperk bestandsuploads op type en grootte, en sla ze op buiten de webmap.
- Schakel het weergeven van fouten uit op productie; foutmeldingen vertellen aanvallers wat er draait.
- Overweeg een webapplicatiefirewall bij een CMS met veel uitbreidingen.
Back-ups en herstel na een inbraak#
Beveiliging faalt soms. Wat er dan gebeurt hangt volledig af van wat je vooraf hebt voorbereid.
- Bewaar back-ups buiten de server. Een back-up op dezelfde machine wordt mee versleuteld of verwijderd.
- Bewaar meerdere generaties. Wordt een inbraak pas na twee weken ontdekt, dan is de back-up van gisteren ook besmet.
- Test het terugzetten elk kwartaal. Dit is de stap die het vaakst ontbreekt.
- Bij een inbraak: haal de site offline of zet hem in onderhoudsmodus voordat je iets anders doet.
- Wijzig elk wachtwoord — CMS, hosting, database, FTP, DNS — voordat je terugzet.
- Zet terug vanuit een back-up van vóór de inbraak, en werk daarna alles bij vóór je weer online gaat.
- Zoek uit hoe ze binnenkwamen. Terugzetten zonder de oorzaak te vinden betekent dat het opnieuw gebeurt.
Bij een datalek met persoonsgegevens gelden meldplichten met korte termijnen. Weet vooraf wie dat beoordeelt, niet tijdens de storing.
Veelgestelde vragen
Is WordPress onveilig?
De kern is redelijk goed onderhouden; het risico zit vrijwel altijd in plug-ins, thema's en zwakke beheerderswachtwoorden. Een WordPress-site met tweefactor, weinig plug-ins en actuele updates is prima. Een site met veertig plug-ins waarvan de helft twee jaar niet is bijgewerkt is een kwestie van tijd.
Heb ik een beveiligingsplug-in nodig?
Ze zijn nuttig voor aanmeldbeperking, bestandsbewaking en meldingen, maar ze vervangen niets uit de lijst hierboven. Een beveiligingsplug-in op een site met verouderde plug-ins en een gedeeld beheerderswachtwoord lost het werkelijke probleem niet op. Zie het als een rookmelder, niet als brandwerende bouw.
Wat doe ik als mijn site gehackt is?
Haal hem offline, wijzig elk wachtwoord inclusief hosting en DNS, en zet dan terug vanuit een schone back-up van vóór de inbraak. Werk alles bij voordat je weer online gaat, en zoek uit hoe ze binnenkwamen — anders herhaalt het zich binnen weken. Zijn er persoonsgegevens geraakt, dan gelden meldingsverplichtingen met korte termijnen.
Beschermt HTTPS mijn site tegen hackers?
Nee, en dat misverstand komt vaak voor. HTTPS versleutelt het verkeer tussen bezoeker en server, wat afluisteren en manipulatie onderweg voorkomt. Het doet niets tegen zwakke wachtwoorden, verouderde plug-ins of SQL-injectie. Het is noodzakelijk en volstrekt onvoldoende.
website beveiligingwebsite hack voorkomenwordpress beveiligingssl certificaatbeveiligingskoptekstenwebsite gehackt
