Een gratis scanner die het SSL-certificaat en de HTTP-headers controleert, geeft een valse indruk van dekking. De OWASP Top 10:2025 plaatst Security Misconfiguration op de tweede plaats en introduceert Software Supply Chain Failures als een aparte categorie. Het testen van de beveiliging van een website online veronderstelt dat je begrijpt wat deze tools daadwerkelijk vastleggen, en vooral wat ze negeren.
Supply Chain en uitzonderlijke omstandigheden: de blinde vlekken van gratis scanners
De meeste tools die zonder registratie toegankelijk zijn, analyseren het blootgestelde oppervlak: geldigheid van het TLS-certificaat, aanwezigheid van de headers Content-Security-Policy, X-Frame-Options, DNS-configuratie. Dit is een nuttige basis, maar dekt noch de keten van softwareafhankelijkheden, noch het beheer van applicatiefouten.
De OWASP Top 10:2025 heeft deze twee risico’s geformaliseerd onder de categorieën Software Supply Chain Failures en Mishandling of Exceptional Conditions. Een JavaScript-component geïmporteerd via npm, een Docker-image gebouwd op een niet-onderhouden basis, een CI/CD-pijplijn waarvan de geheimen zijn blootgesteld: geen enkele anonieme externe scan detecteert deze tekortkomingen.
We raden aan om de online scan te beschouwen als een eerste filter, niet als een audit. Het identificeert configuratiefouten die van buitenaf zichtbaar zijn. Voor de softwareketen is een tool van het type Software Composition Analysis (Snyk Open Source, OWASP Dependency-Check) nodig die in de code repository wordt uitgevoerd.
Voordat je een scan start, is het nuttig om de beveiliging van een website online te testen door precies te begrijpen welk bereik door elk hulpmiddel wordt gedekt, om te voorkomen dat je een schoon rapport verwart met een werkelijk verkleind aanvalsurface.
Security Misconfiguration: wat de scans van HTTP-headers echt detecteren
De stijging van Security Misconfiguration naar de tweede plaats in de OWASP-ranglijst is niet anekdotisch. Het weerspiegelt de toename van configuratieoppervlakken: openbare cloud-buckets, toegankelijke beheerseindpunten, uitgebreide foutpagina’s die stacktraces blootleggen, cookies zonder Secure- of SameSite-attribuut.
Gratis scanners dekken een deel van dit bereik. Ze controleren typisch:
- De aanwezigheid en waarde van de HTTP-beveiligingsheaders (Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
- De TLS-configuratie (protocolversie, versleutelingssets, vervaldatum van het certificaat)
- De blootstelling van serverinformatie in de response headers (Server, X-Powered-By)
- Het CORS-beleid en de toegestane oorsprongen
Daarentegen test een externe scan geen interne configuraties: IAM-regels van een S3-bucket, toegang tot een beheersconsole beschermd door een obscure URL, of omgevingsvariabelen die in platte tekst in de client-side broncode zijn geïnjecteerd. Deze controles vereisen een geauthenticeerde toegang of een audit van de gedeployde code.
Een beveiligingsscore interpreteren zonder deze te overschatten
Een rapport dat een hoge score (A of A+) op de HTTP-headers weergeeft, betekent niet dat de applicatie veilig is. Het betekent dat de transportlaag en de browserrichtlijnen correct zijn ingesteld. We zien regelmatig sites met een A+-beoordeling waarvan het beheerpaneel toegankelijk is via /admin zonder IP-beperkingen of dubbele authenticatie.
De score is een indicator van volwassenheid over een specifiek bereik. Het dekt noch de bedrijfslogica, noch de applicatieve toegangscontroles.
Broken Access Control en geauthenticeerde tests: de structurele limiet van de anonieme scan
Het risico dat door OWASP als nummer één is geclassificeerd in 2025 blijft Broken Access Control, dat nu ook SSRF (Server-Side Request Forgery) omvat. Dit type kwetsbaarheid vereist testaccounts met verschillende niveaus van bevoegdheden en concrete bedrijfs-scenario’s: een standaardgebruiker die probeert toegang te krijgen tot een bron die voorbehouden is aan een beheerder, een API-aanroep die de identificatie van een object wijzigt om de gegevens van een andere gebruiker te bereiken (IDOR).
Geen enkele anonieme externe scanner kan de toegangscontroles valideren zonder ten minste twee geauthenticeerde sessies met verschillende rollen. Een tool zoals OWASP ZAP maakt het mogelijk om authenticatiecontexten in te stellen en scenario’s opnieuw te spelen, maar dit valt buiten het bereik van een eenvoudige online test.
Gecombineerde aanpak voor een realistische audit zonder budget
Om een acceptabel bereik te dekken zonder financiële investering, raden we aan om drie lagen te combineren:
- Een scan van headers en TLS-configuratie via een gratis online tool (Mozilla Observatory, SecurityHeaders.com) voor het netwerk- en transportbereik
- Een lokale interceptieproxy (OWASP ZAP in standaardmodus) om handmatig de toegangscontroles en injecties op formulieren te testen, met geauthenticeerde sessies
- Een afhankelijkheidsanalyse (npm audit, pip-audit, OWASP Dependency-Check) direct in de build-pijplijn om de softwareketen te dekken
Deze combinatie dekt drie van de vijf belangrijkste risico’s in de OWASP 2025-ranglijst. Het vervangt geen professionele pentest, maar verhoogt het detectieniveau aanzienlijk in vergelijking met een enkele scan van HTTP-headers.
CORS, cookies en Content-Security-Policy: de instellingen die prioriteit hebben om te controleren
Onder de gratis testbare elementen concentreren drie configuraties een onevenredig deel van de exploiteerbare fouten.
De slecht geconfigureerde CORS-policy blijft veelvoorkomend. Een Access-Control-Allow-Origin ingesteld op * met Access-Control-Allow-Credentials op true stelt de sessiecookies bloot aan elk derde domein. Gratis scanners signaleren deze combinatie, maar testen de applicatieve gevolgen niet.
De cookie-attributen verdienen bijzondere aandacht. Een sessiecookie zonder Secure, zonder HttpOnly en zonder SameSite=Strict (of Lax) is kwetsbaar voor diefstal via XSS of voor opname in cross-site-aanroepen. Recente browsers verzachten sommige scenario’s, maar de expliciete configuratie blijft de enige betrouwbare bescherming aan de serverzijde.
Tenslotte maakt een permissieve Content-Security-Policy de bescherming tegen XSS-injecties ongeldig. Een script-src-richtlijn die ‘unsafe-inline’ of ‘unsafe-eval’ bevat, maakt de CSP cosmetisch. Online scan-tools detecteren deze richtlijnen, wat het een van de weinige applicatieve controles maakt die toegankelijk zijn zonder authenticatie.
De gratis beschikbaarheid van een testtool is op zich geen probleem. Wat een vals gevoel van veiligheid creëert, is het behandelen van het rapport als uitputtend, terwijl het slechts een fractie van het werkelijke aanvalsurface dekt. Een schone scan van de HTTP-headers blijft een goed startpunt, op voorwaarde dat je doorgaat met de lagen die het hulpmiddel niet kan bereiken.
