Een groene hangslot in de adresbalk garandeert niet veel. Gratis SSL-certificaten, elke site kan er een krijgen, inclusief phishingpagina’s. De veiligheid van een website controleren vereist meer dan deze eenvoudige visuele indicator, door lagen te onderzoeken die noch de browser noch de gemiddelde gebruiker ziet.
API-beveiliging: de blinde vlek van een website-audit
Je bekijkt een webpagina, je ziet tekst, afbeeldingen, een formulier. Achter de schermen vraagt deze pagina vaak verschillende API’s op om gegevens te verkrijgen of te verzenden. Deze programmeerinterfaces zijn een prioritaire doelwit geworden voor aanvallers.
De rapporten van 2024 bevestigen dat aanvallen gericht op API’s een groeiend aandeel van de incidenten op webapplicaties vertegenwoordigen. Het probleem: de meeste klassieke controles beperken zich tot de zichtbare pagina’s. De API-eindpunten blijven in de schaduw.
Een effectieve audit begint met een volledige inventarisatie van deze eindpunten. Sommige zijn gemaakt voor een eenmalige behoefte en vervolgens vergeten. Andere zijn onvolledig gedocumenteerd. Juist deze vormen een probleem, omdat niemand eraan denkt om hun authenticatie of machtigingen te controleren.
Concreet moet elk API-ingangspunt individueel worden getest. Er wordt gecontroleerd of de authenticatie object voor object werkt (gebruiker A mag geen toegang hebben tot de gegevens van gebruiker B), of er snelheidslimieten zijn ingesteld en of verouderde API’s daadwerkelijk zijn verwijderd. Verschillende tools maken het mogelijk om een deel van deze websitebeveiligingscontrole te automatiseren, maar handmatige controle blijft noodzakelijk voor autorisatiecontroles.
Prioriteren van kwetsbaarheden: waarom de CVSS-score niet voldoende is
Wanneer een scanner een lijst van kwetsbaarheden teruggeeft, wordt elke kwetsbaarheid vergezeld van een ernstscore (CVSS). De verleiding is om eerst de hoogste scores aan te pakken. Deze aanpak lijkt logisch, maar mist een cruciale gegevenspunt: aanvallers maken vooral gebruik van bekende en gedocumenteerde kwetsbaarheden, niet noodzakelijk de meest geavanceerde.
De CISA onderhoudt een catalogus genaamd Known Exploited Vulnerabilities (KEV). Deze lijst bevat kwetsbaarheden die actief in het wild worden uitgebuit. Een kwetsbaarheid met een gemiddelde CVSS-score maar aanwezig in deze catalogus verdient onmiddellijke correctie. Omgekeerd kan een theoretische kwetsbaarheid met een zeer hoge score, maar nooit uitgebuit, wachten.
Voor een werkelijk nuttige controle, kruis drie criteria:
- De technische ernst gegeven door de CVSS-score, die het schadepotentieel van de kwetsbaarheid meet.
- De aanwezigheid in de KEV-catalogus van de CISA, die aangeeft of de kwetsbaarheid actief wordt uitgebuit door aanvallers.
- De werkelijke blootstelling van de betrokken component: een dienst die toegankelijk is vanaf het internet is dringender dan een interne tool achter een VPN.
Het kruisen van technische ernst, actieve exploitatie en werkelijke blootstelling verandert radicaal de prioriteitenlijst voor correcties. Zonder deze sortering kan een bedrijf weken bezig zijn met een theoretische kwetsbaarheid terwijl een geëxploiteerde inbreuk open blijft.
Open source-componenten en AI-modellen in beveiligingsanalyse
De meeste moderne websites zijn afhankelijk van open source-bibliotheken. Een CMS, een JavaScript-framework, een betalingsmodule: elk bevat externe code met zijn eigen potentiële kwetsbaarheden.
Het controleren van deze componenten vereist een nauwkeurige inventarisatie, vaak aangeduid als Software Bill of Materials (SBOM). Dit document vermeldt elke afhankelijkheid, zijn versie en zijn onderhoudstoestand. Een component dat door zijn onderhouders is verlaten, is een stille risico: er zullen geen updates komen om de kwetsbaarheden die na het verlaten zijn ontdekt te verhelpen.
Functies die kunstmatige intelligentie integreren, vormen een extra probleem. Een AI-model dat via een API is blootgesteld, kan worden gemanipuleerd door verzoeken die zijn ontworpen om trainingsgegevens te extraheren of filters te omzeilen. Deze aanvalsvectoren worden nog steeds slecht gedekt door klassieke scanners.
Controleer de serverconfiguratie en HTTP-headers
Voordat je zelfs maar naar kwetsbaarheden in de code zoekt, onthult de serverconfiguratie vaak eenvoudige problemen die gemakkelijk op te lossen zijn. HTTP-headers, bijvoorbeeld, controleren hoe de browser met de site omgaat.
Een goed geconfigureerde Content-Security-Policy-header blokkeert de meeste XSS-aanvallen. Omgekeerd zijn sommige headers die ooit werden aanbevolen nu verouderd. X-XSS-Protection is bijvoorbeeld volgens de MDN-documentatie niet meer nuttig in moderne browsers. Het kopiëren van een configuratie die op een forum uit 2018 is gevonden, kan een vals gevoel van veiligheid geven.
De punten die aan de serverzijde moeten worden gecontroleerd:
- Het HTTPS-protocol is actief met een geldig certificaat, en de HTTP-omleidingen naar HTTPS werken zonder lus.
- Gevoelige bestanden (back-ups, configuratiebestanden, .git-mappen) zijn niet openbaar toegankelijk.
- Beveiligingsheaders zijn up-to-date en aangepast aan de context van de site, niet gewoon gekopieerd van een generiek sjabloon.
- De foutmeldingen van de server onthullen geen technische informatie (softwareversies, bestandslocaties).
Controle na correctie: de stap die de meeste bedrijven overslaan
Een kwetsbaarheid detecteren, deze corrigeren, doorgaan naar de volgende. Deze cyclus lijkt compleet, maar er ontbreekt een formele stap: bevestigen dat de correctie daadwerkelijk werkt.
De gegevens van 2024 tonen aan dat bekende kwetsbaarheden gedurende lange perioden open blijven, zelfs in bedrijven die zijn uitgerust met scanners. De patch is uitgerold naar een testomgeving, maar niet in productie. Of de update is toegepast, maar een kwetsbare versie van de component draait nog op een andere server.
De controle na correctie moet een nieuwe scan omvatten die gericht is op de behandelde kwetsbaarheid, een handmatige controle dat de patch geen regressie heeft veroorzaakt (een gebroken functionaliteit, een formulier dat geen invoer meer valideert) en een controle dat de kwetsbare versies uit alle blootgestelde omgevingen zijn verwijderd.
Deze stap transformeert een auditrapport in meetbare verbetering. Zonder deze blijft het rapport een PDF-document dat in een map is geclassificeerd, en blijft de kwetsbaarheid exploiteerbaar.
