Securityscans onder de loep: wat ze meten en waar hun grenzen liggen

Veel website‑eigenaren laten met enige regelmaat een securityscan uitvoeren op hun website. Dat kan via de hostingprovider, via een externe dienst of via een beveiligingsmodule binnen het CMS. De uitkomst is vaak overzichtelijk: een rapport met waarschuwingen, aanbevelingen of juist de geruststellende melding dat er geen problemen zijn gevonden.

Afgebakend gebied

Dat rapport wordt in de praktijk regelmatig gezien als een soort gezondheidscheck van de website. En in zekere zin is dat ook zo. Securityscans kunnen namelijk veel nuttige informatie opleveren over de technische staat van een website.

Maar er zit een nuance in die vaak onderbelicht blijft. Een securityscan controleert namelijk een aantal specifieke technische aspecten, niet de volledige veiligheid van een website. Dat verschil is belangrijk om te begrijpen. Niet omdat scans onbetrouwbaar zouden zijn, maar omdat hun kracht juist ligt in een vrij duidelijk afgebakend gebied.

Of anders gezegd: een scanner meet wat technisch zichtbaar en herkenbaar is. Alles wat afhankelijk is van context, inrichting of gebruik van een website, ligt meestal buiten het bereik van automatisering.

In dit artikel kijken we daarom naar twee vragen: wat kan een securityscan doorgaans wél ontdekken, en waar liggen de grenzen van zo’n scan?

Wat een securityscan doorgaans wél ontdekt

De meeste securityscanners werken volgens een vrij herkenbaar principe. Dat is meteen ook een interessante eigenschap van automatisering in beveiliging: wat goed te herkennen is, laat zich vaak goed scannen; wat afhankelijk is van context of bedoeling, een stuk minder.

Scanners analyseren een website vanaf de buitenkant en vergelijken wat ze aantreffen met bekende patronen van kwetsbaarheden of onveilige configuraties. Dat klinkt misschien abstract, maar in de praktijk gaat het vaak om vrij concrete controles.

Bekende kwetsbaarheden in software

Een belangrijk onderscheid in beveiliging is dat tussen bekende en onbekende kwetsbaarheden. Bekende kwetsbaarheden laten zich relatief goed automatiseren: ze zijn gepubliceerd, gedocumenteerd en vaak voorzien van een herkenbare technische vingerafdruk. Juist daardoor kunnen scanners ze efficiënt opsporen.

Een belangrijk deel van securityscans bestaat daarom uit het controleren van softwareversies. Veel kwetsbaarheden in websites ontstaan doordat een CMS, module of bibliotheek verouderd is.

Securityscanners vergelijken aangetroffen softwareversies met publieke databases van kwetsbaarheden, zoals de National Vulnerability Database (NVD) of advisories van softwareprojecten zelf. Drupal publiceert bijvoorbeeld beveiligingsadviezen via het Drupal Security Team.

Wanneer een scanner vaststelt dat een website een versie gebruikt waarvoor een bekende kwetsbaarheid bestaat, kan dat vrij betrouwbaar worden gerapporteerd. Voorbeelden van bevindingen die regelmatig in scanrapporten voorkomen zijn:

  • een verouderde Drupal core‑versie
  • een module met een bekende beveiligingsupdate
  • een JavaScript‑bibliotheek met een publiek gemelde kwetsbaarheid

Dit soort controles zijn goed te automatiseren, omdat de informatie over deze kwetsbaarheden openbaar beschikbaar is.

Basisconfiguratie van de website

Veel scanners controleren ook de technische configuratie van een website of server. Daarbij kijken ze bijvoorbeeld naar instellingen die via het web zichtbaar zijn.

Denk aan zaken zoals:

  • de aanwezigheid van HTTPS
  • HTTP‑securityheaders
  • TLS‑configuratie
  • directory listing

Dit soort controles zijn relatief eenvoudig uit te voeren, omdat een scanner deze informatie rechtstreeks kan opvragen bij de webserver.

Wanneer hier afwijkingen worden gevonden, kan dat waardevolle aanwijzingen opleveren voor verbeteringen in de configuratie.

Bekende patronen van malware

Sommige securityscans bevatten ook een analyse van bestanden of pagina’s op zoek naar bekende malwarepatronen. Dat werkt vergelijkbaar met antivirussoftware. De scanner zoekt naar codefragmenten die overeenkomen met bekende webshells, backdoors of geïnfecteerde scripts.

Wanneer zulke patronen worden herkend, kan dat een aanwijzing zijn dat een website op een manier is aangepast die nader onderzoek verdient. Ook hier geldt dat automatisering goed mogelijk is zolang het gaat om patronen die eerder zijn geïdentificeerd.

Waar een securityscan meestal geen zicht op heeft

De grenzen van securityscans worden duidelijk zodra een probleem minder technisch herkenbaar wordt. Een scanner kan bijvoorbeeld uitstekend controleren of een server een bepaalde header gebruikt, maar hij kan niet beoordelen of een website logisch of organisatorisch veilig is ingericht.

Autorisatie en rechtenstructuren

In de praktijk groeien rechtenstructuren in organisaties vaak geleidelijk. Nieuwe rollen worden toegevoegd, tijdelijke toegang blijft soms langer bestaan dan bedoeld en configuraties worden aangepast terwijl de website evolueert. Dat maakt beheer werkbaar, maar zorgt er ook voor dat de uiteindelijke rechtenstructuur niet altijd meer precies weerspiegelt wat oorspronkelijk de bedoeling was.

Een groot deel van beveiligingsvraagstukken in websites heeft te maken met toegangsrechten. Wie mag wat zien, wijzigen of downloaden? In systemen zoals Drupal worden deze rechten vaak geregeld via rollen, permissies en configuratie. Of een combinatie daarvan logisch en veilig is ingericht, hangt sterk af van de context van een website.

Een geautomatiseerde scanner kan meestal niet beoordelen of een bepaalde gebruiker eigenlijk te veel rechten heeft gekregen. Daarvoor is inzicht nodig in de bedoeling van het systeem en de werkprocessen van de organisatie.

Logische kwetsbaarheden in functionaliteit

Ook kwetsbaarheden die voortkomen uit de manier waarop functionaliteit is ontworpen blijven vaak buiten beeld.

Voorbeelden uit de praktijk zijn:

  • formulieren die onbeperkt e‑mails kunnen versturen
  • uploadfuncties zonder duidelijke bestandsbeperkingen
  • zoekpagina’s die zeer grote hoeveelheden data teruggeven

Technisch gezien kan zo’n functie correct werken. Vanuit beveiligingsperspectief kan het echter wel degelijk een risico vormen.

Dit soort situaties worden doorgaans ontdekt tijdens handmatige analyse of tijdens gebruik van de website, niet via een automatische scan.

Wijzigingen die geen herkenbaar patroon hebben

Securityscanners herkennen vooral bekende patronen. Wanneer een wijziging subtiel is en niet overeenkomt met bekende malware, kan deze buiten beeld blijven.

Denk bijvoorbeeld aan:

  • een extra gebruikersaccount
  • kleine aanpassingen in templates
  • redirects die alleen onder specifieke omstandigheden actief zijn

Voor een scanner ziet de website er in zulke gevallen technisch gezien normaal uit.

Het herkennen van dit soort veranderingen vraagt vaak om monitoring van wijzigingen in bestanden, logbestanden of gebruikersaccounts.

De bredere omgeving rond een website

Tot slot richten veel scans zich uitsluitend op de website zelf.

In de praktijk maakt een website echter deel uit van een bredere digitale omgeving. Daarin spelen bijvoorbeeld ook zaken mee zoals:

  • accountbeheer
  • toegang tot servers
  • integraties met externe systemen
  • back‑upbeheer

Deze aspecten vallen meestal buiten het bereik van een standaard securityscan.

Waarom securityscans toch waardevol blijven

Een praktische manier om naar securityscans te kijken is als een vorm van technische automatisering binnen het beheerproces. Ze nemen een deel van het controlewerk over dat anders handmatig en tijdrovend zou zijn. Dat betekent niet dat ze alles kunnen beoordelen, maar wel dat ze snel en consequent bepaalde categorieën problemen kunnen signaleren.

In die zin functioneren scanners vooral als één instrument binnen een bredere gereedschapskist voor websitebeheer. Ze leveren regelmatig meetpunten op over de technische staat van een website, waarna andere vormen van analyse en beheer daar verder op kunnen bouwen.

Het feit dat securityscans een afgebakend werkgebied hebben betekent dus niet dat ze weinig waarde hebben. Integendeel: juist voor het signaleren van technische basisproblemen zijn ze bijzonder efficiënt.

Scans kunnen bijvoorbeeld helpen om:

  • bekende kwetsbaarheden snel te signaleren
  • configuratiefouten zichtbaar te maken
  • veranderingen in de technische staat van een website op te merken

In professioneel websitebeheer worden securityscans daarom vaak ingezet als één van de instrumenten om de technische gezondheid van een website te volgen. Het belangrijkste is dat de resultaten van een scan worden gezien als één informatiebron binnen een bredere beoordeling van de website.

Tenslotte

Securityscans spelen een nuttige rol bij het bewaken van de technische veiligheid van websites. Ze zijn efficiënt in het opsporen van bekende kwetsbaarheden, configuratieproblemen en herkenbare malwarepatronen. Tegelijkertijd is hun blikveld per definitie beperkt tot wat automatisch te detecteren is.

Beveiliging van websites bestaat daarom meestal uit een combinatie van automatische controles, updates van software, monitoring en periodieke handmatige beoordeling van configuraties en gebruikersrechten.

Securityscans passen goed in dat geheel. Ze geven regelmatig inzicht in de technische basis van een website. In die zin lijken ze inderdaad op een gezondheidscheck. Niet een volledige diagnose van de website, maar wel een instrument dat meetbare signalen zichtbaar maakt, waarna een bredere beoordeling kan volgen.