Een website die al twee jaar probleemloos draait, geeft je een vals gevoel van veiligheid. Geen meldingen, geen klachten, geen downtime: het lijkt allemaal in orde. Maar onder die rustige oppervlakte stapelen zich kwetsbaarheden op die niets met jouw gedrag te maken hebben. Een CMS-update die uitgesteld is, een verouderde PHP-versie op de server, ontbrekende HTTP-headers, een formulier zonder goede invoervalidatie: geen van die dingen schreeuwt om aandacht totdat iemand er misbruik van maakt. Dat moment is niet altijd spektakel. Soms is het een server die weken lang malware verstuurt zonder dat je het doorhebt, of klantdata die zachtjes weglekt via een onbeveiligde endpoint.
Wat een beveiligingsscan daadwerkelijk controleert
Zo'n scan is geen magische knop die alles oplost. Het is een gestructureerde analyse van de technische staat van jouw digitale omgeving, opgedeeld in meerdere lagen. Op serverniveau kijk ik naar de PHP-versie, open poorten, SSH-configuratie en of er onnodige diensten actief zijn. Op applicatieniveau test ik formulieren op invoervalidatie, controleer ik of sessies veilig worden afgehandeld en kijk ik of bestandsuploads beperkt zijn tot wat strikt noodzakelijk is.
Daarboven zit de laag van HTTP-headers. Dit zijn kleine instructies die een webserver meestuurt bij elke paginalading, en die de browser vertellen wat hij wel en niet mag doen. Een Content-Security-Policy bepaalt bijvoorbeeld van welke domeinen scripts geladen mogen worden. Een X-Frame-Options header voorkomt dat jouw pagina in een iframe op een vreemde website wordt geladen, wat phishingaanvallen een stuk moeilijker maakt. Een Strict-Transport-Security header dwingt de browser om altijd via HTTPS te communiceren, ook als iemand per ongeluk http:// intikt. Al die headers zijn gratis in te stellen, maar ze ontbreken op een opvallend groot deel van de websites die ik onder ogen krijg.
Dan is er nog de afhankelijkheden: third-party scripts, externe fonts, analysepixels, marketingtools. Al die externe bronnen draaien met het vertrouwen van jouw domeinnaam. Als zo'n externe partij gecompromitteerd raakt, heeft jouw bezoeker daar last van zonder dat jij ook maar iets hebt aangepast. Subresource Integrity (SRI) is een techniek die hierop een rem zet: de browser controleert of het externe bestand nog exact overeenkomt met een eerder vastgelegde hash. Wordt het bestand aangepast door een kwaadwillende derde, dan weigert de browser het te laden.
Wat het je kost als je het negeert
De directe schade is het makkelijkst te begrijpen: downtime, herstelkosten, reputatieschade. Maar er zijn ook indirecte gevolgen die minder zichtbaar zijn en daardoor onderschat worden. Google indexeert malware. Als jouw website geïnfecteerd raakt met kwaadaardige code of doorverwijzingen naar dubieuze pagina's, kan Google je site markeren als onveilig. Bezoekers krijgen dan een rode waarschuwingspagina te zien nog vóórdat ze jouw website hebben gezien. Het herstel van zo'n Google-melding duurt weken, en de SEO-schade die je oploopt tijdens die periode verdwijnt niet vanzelf wanneer de melding wordt opgeheven.
Financieel gezien geldt er voor bedrijven die persoonsgegevens verwerken ook een wettelijke verantwoordelijkheid. De AVG verplicht je tot passende technische en organisatorische maatregelen. Een datalek zonder aantoonbare inspanning om dat te voorkomen kan leiden tot een boete of een aansprakelijkstelling van gedupeerde klanten. Dat is geen theorie: de Autoriteit Persoonsgegevens heeft ook MKB-bedrijven aangesproken op het ontbreken van basisbeveiliging. Een beveiligingsscan is daarmee geen luxe, maar documentatie dat je serieus omgaat met je verantwoordelijkheid als gegevensbeheerder.
Het meest onderschatte risico is de stille aanval. Niet iedere aanvaller wil jouw website platleggen: dat zou opvallen. Een server die jarenlang onderdeel is van een botnetwerk en spam verstuurt of cryptovaluta mineert, doet dat juist zo onopvallend mogelijk. Jij betaalt de serverrekening, de aanvaller plukt de vruchten. Pas wanneer jouw IP-adres op een blacklist terechtkomt en je mailserver niet meer aankomt bij klanten, merk je dat er iets structureel mis is.
Hardening: meer dan een vinkje zetten
Na een scan volgt altijd een fase die ik "hardening" noem: het daadwerkelijk dichten van de gaten. Dat is iets anders dan een rapport ontvangen en de PDF wegklikken. Hardening is het aanpassen van serverconfiguraties, het instellen van de juiste headers, het verwijderen van software die niet actief wordt ingezet, het beperken van bestandspermissies en het inrichten van een monitoring die je waarschuwt als er verdachte activiteit is.
Neem fail2ban als voorbeeld. Dat is een stukje serversoftware dat inlogpogingen bijhoudt en IP-adressen tijdelijk blokkeert na een reeks mislukte pogingen. Het kost weinig om in te richten, maar voorkomt dat brute-force aanvallen op jouw adminpanel uren ongestoord door kunnen gaan. Combineer dat met twee-factor authenticatie op het beheergedeelte van je applicatie, en je hebt al een aanzienlijk hogere drempel opgeworpen zonder dat het jou of je medewerkers in het dagelijkse werk hindert.
Cloudflare speelt in mijn aanpak ook een rol. Als DNS-proxy zit het tussen jouw bezoekers en jouw server in, en filtert het verkeer voordat het jouw infrastructuur raakt. DDoS-bescherming, botdetectie, WAF-regels (Web Application Firewall) en automatische HTTPS-omleiding zijn slechts een deel van wat Cloudflare op het gratis of betaalde niveau levert. Voor MKB-bedrijven is dit een van de meest kosteneffectieve beveiligingslagen die er bestaat: geen eigen hardware, geen beheerteam, gewoon een DNS-instelling die een wereld van verschil maakt.
Wanneer is een scan verstandig en hoe vaak herhaal je dat?
Niet wachten tot na een incident is het kortste antwoord. Verstandige momenten zijn: vlak vóór de livegang van een nieuwe website of applicatie, na een grote update of migratie, na het toevoegen van een externe betaalprovider of koppeling, en minimaal één keer per jaar als periodieke check. Dat laatste klinkt als een kostenpost, maar vergelijk het met een APK-keuring: je doet het ook niet één keer en vergeet het daarna voor de volgende tien jaar.
Voor webshops met betalingsverkeer is de frequentie hoger. PCI DSS, de standaard die geldt voor het verwerken van kaartbetalingen, schrijft kwartaalscans voor bij bepaalde typen installaties. Doe je dat niet en er vindt een fraude-incident plaats, dan loop je het risico dat jouw betaalprovider de samenwerking opzegt. Dat betekent niet alleen herstelkosten: het betekent dat je tijdelijk geen online betalingen kunt verwerken, wat voor een webshop een kritiek bedrijfsrisico is.
Portalen en ledenomgevingen verdienen extra aandacht vanwege de aard van de data die ze bewaren. Achter een loginscherm zit doorgaans informatie die meer waard is voor aanvallers dan een publieke pagina: factuurgeschiedenissen, persoonlijke documenten, communicatiehistorie. Het loginmechanisme zelf moet getest worden op zwaktes zoals account enumeration (kan een aanvaller raden of een e-mailadres bestaat in jouw systeem?), sessievervaldatum en het gedrag bij vergeten wachtwoordherstel. Dat zijn geen hypothetische aanvallen: ze staan standaard in de OWASP Top 10, de meest gebruikte referentie voor webapplicatiebeveiliging wereldwijd.
Wat ik merk in mijn eigen werk is dat beveiliging pas echt serieus genomen wordt wanneer iemand in de directe omgeving is geraakt. Dat is jammer, want het moment waaróp je investeert in beveiliging bepaalt grotendeels hoe duur het wordt. Proactief een scan laten uitvoeren en een paar daagdelen besteden aan hardening is een fractie van wat je kwijt bent aan crisisbeheer, reputatieherstel en juridisch advies na een incident. Dat is geen dramatisering: dat is gewoon hoe de cijfers in de praktijk uitpakken.
Dit soort werk doe ik voor websites, webapplicaties, portalen en webshops van MKB-bedrijven die hun digitale omgeving serieus nemen. Meer over wat een beveiligingsscan of hardening-traject inhoudt, vind je op https://pimvdmolen.nl/diensten/beveiliging. Wil je direct weten wat er bij jou speelt, neem dan contact op via https://pimvdmolen.nl/contact.