Heeft u uw website gecontroleerd op beveiligingslekken?

Websites worden zelden gekraakt door genieën — geautomatiseerde systemen scannen het openbare web voortdurend op bekende, vermijdbare zwakke plekken, en veel inbraken misbruiken precies die. Het probleem met de vraag „hebt u gecontroleerd op beveiligingslekken?” is dat ze te vaag is om iets mee te doen. Daarom hier een concrete lijst van wat u controleert, en een ritme om dat te blijven doen.

Waar de lekken echt zitten

• Blootgestelde of verouderde software. De CMS-kern, plug-ins, thema’s en bibliotheken met gepubliceerde kwetsbaarheden — plus beheerpanelen, phpinfo-pagina’s, .git-mappen of back-ups die bereikbaar bleven in de webroot.
• Server- en applicatieconfiguratie. HTTPS dat niet wordt afgedwongen of gemengde inhoud; beveiligingsheaders en cookie-attributen die ontbreken waar ze gelden (een Content-Security-Policy beschermt weergegeven pagina’s, niet een JSON-API — stel elke maatregel in voor de antwoorden waarvoor hij relevant is); breedsprakige foutmeldingen die paden lekken; onbedoelde mapweergaven.
• Identiteiten en machtigingen. Standaard- of hergebruikte beheerderswachtwoorden, ontbrekende multifactorauthenticatie (MFA), zwakke afremming bij inloggen, wachtwoordherstel en andere gevoelige handelingen — en, apart daarvan, te ruime rechten: bestandsrechten, serviceaccounts en databasegebruikers met meer dan ze nodig hebben.
• Elk invoerpad — niet alleen zichtbare formulieren. Invoer komt ook binnen via URL’s, cookies, headers, API’s, webhooks, imports en eerder opgeslagen gegevens. De klassiekers: injectie door slecht verwerkte invoer, te soepel aanvaarde uploads, formulieren zonder validatie op de server, en wijzigingen achter een cookie-login zonder CSRF-bescherming.
• Externe afhankelijkheden. Composer-/npm-pakketten, ingebedde scripts, externe widgets en buildtools — of ze nu draaien op uw server, in de browser van bezoekers of in uw deploy-pijplijn: elk ervan kan fouten of risico’s in de toeleveringsketen meebrengen.

Deze vijf gebieden zijn een startkader, niet het hele oppervlak: reken ook elke hostnaam en API mee, de controle over domein en DNS, deployaccounts en geheimen, sessies, en de plekken waar gevoelige gegevens worden opgeslagen of gelogd.

Herstel in een ritme, niet één keer

1. Vinden — een geautoriseerde, niet-destructieve scan plus een handmatige blik. Scan alleen wat van u is of wat u mag testen, en zie scannerresultaten als aanwijzingen, niet als bewijs: verwacht valse positieven, en weet dat niet-ingelogde scans beveiligde routes, logicafouten en fouten op broncodeniveau missen. Achter een reverse proxy beoordeelt een openbare TLS-test alleen de rand — controleer de sprong van proxy naar origin en de directe blootstelling van de origin apart.
2. Prioriteren — op uitbuitbaarheid, blootstelling, vereiste rechten, geraakte gegevens en zakelijke impact. Publiek bereik verhoogt de urgentie, maar een fout met grote impact achter een login kan nog altijd eerst komen.
3. Herstellen — pak de belangrijkste punten aan, niet alleen de makkelijke. Voor uploads betekent dat: sta alleen vereiste types en groottes toe, vertrouw nooit de opgegeven bestandsnaam of het MIME-type, genereer zelf opslagnamen, sla op buiten de webroot of op een geïsoleerde host, en serveer als niet-uitvoerbare inhoud. Voor acties achter een cookie-login: de CSRF-bescherming van het framework, gevalideerd op de server, zonder statuswijzigingen via GET.
4. Hercontroleren — bevestig dat elke fix werkte en dat niets terugviel, en plan dan de volgende ronde.

Dagelijks patchen en accounthygiëne zijn een discipline op zich (apart behandeld) — hier gaat het erom het hele oppervlak volgens een herhaalbaar schema te controleren, en na elke release, elk advies of elk incident, in plaats van op routine te vertrouwen.

Kern: controleer het echte aanvalsoppervlak — software, configuratie, identiteiten, invoer, afhankelijkheden en alles wat eraan vasthangt — en draai het als een cyclus van vinden, prioriteren, herstellen en hercontroleren, aangestuurd door de kalender én door gebeurtenissen, niet als een eenmalige scan.

Wat u moet doen

1. Inventariseer uw oppervlak — de vijf gebieden plus elke hostnaam, API, elk deploysysteem en elke gegevensopslag. Wat niet op de lijst staat, kunt u niet beveiligen.
2. Draai een geautoriseerde scan en header-/TLS-controles; controleer bevindingen met de hand, en controleer de origin apart als er een proxy voor de site staat.
3. Ga veilig om met invoer: geparametriseerde query’s voor gegevenswaarden, toelatingslijsten voor dynamische identifiers, uitvoercodering per context, CSRF-bescherming op wijzigingen achter een cookie-login, en robuuste uploads.
4. Bescherm accounts en pas minimale rechten toe — unieke wachtwoorden en MFA op accounts met extra rechten; daarnaast minimale rechten voor rollen, bestanden, diensten en databasegebruikers.
5. Prioriteer, herstel en hercontroleer — volgens de kalender, na grote wijzigingen en telkens wanneer een beveiligingsadvies iets noemt dat u gebruikt.
6. Bewaar beschermde, geversioneerde back-ups buiten de productieomgeving, met aparte toegang en geteste herstelprocedures, zodat u kunt herstellen als er toch iets doorheen glipt.