Website security scan

Wat de scan controleert

De securitycategorie toetst aan de OWASP Application Security Verification Standard en de OWASP Secure Headers-baseline. Dat zijn dezelfde referentiepunten die een pentestbureau gebruikt als vertrekpunt. Concreet kijken we naar:

• API-keys, tokens en secrets die zichtbaar zijn in je client-side JavaScript
• Configuratiebestanden die publiek opvraagbaar zijn: .env, .git/config, backup-bestanden, database-dumps
• Ontbrekende of zwak geconfigureerde securityheaders (HSTS, X-Content-Type-Options, Referrer-Policy)
• Content Security Policy: aanwezig, en of hij daadwerkelijk iets tegenhoudt
• Clickjacking-bescherming via X-Frame-Options of frame-ancestors
• Mixed content: onveilige resources die over http:// geladen worden op een https-pagina
• CORS-instellingen die elke willekeurige origin toelaten
• security.txt, getoetst aan RFC 9116

Waarom een lekkende API-key zo vaak voorkomt

Frontend-frameworks maken het makkelijk om een omgevingsvariabele in te bouwen. Te makkelijk. Een sleutel die met een publiek prefix wordt geëxporteerd, belandt letterlijk in de JavaScript die elke bezoeker downloadt. Voor een analytics-sleutel is dat prima — daar is hij voor bedoeld. Voor een mail-API, een betaalprovider of een database-token is het een openstaande deur.

Het venijnige is dat er niets kapotgaat. De site werkt, de tests slagen, de deploy is groen. Niemand merkt het, totdat iemand die wél zoekt het vindt. De scan haalt je gebundelde JavaScript op en herkent de patronen van bekende sleutelformaten, dus je ziet het voordat een ander het ziet.

Bewijs, geen lijstje met vinkjes

Elke bevinding komt met de onderbouwing erbij: het opgevangen verzoek, de responseheader zoals hij binnenkwam, of het fragment uit je JavaScript waar de sleutel staat. Daarnaast noemt het rapport de norm of best practice waarop de bevinding is gebaseerd.

Even belangrijk: het rapport vermeldt ook welke controles níet konden draaien. Als een pagina achter een login zit of een check op een timeout liep, staat dat er als 'niet getest' — niet als 'goed'. Een auditrapport dat stilzwijgend gaten laat vallen is erger dan geen rapport.

Alleen meelezen, nooit aanpassen

De scan doet uitsluitend GET-verzoeken. Er wordt niets verstuurd, niets aangemaakt en niets verwijderd. Er wordt niet geprobeerd een gevonden zwakte daadwerkelijk uit te buiten — we stellen vast dát de deur openstaat, we lopen er niet doorheen.

Daardoor is de scan veilig te draaien op elke publieke URL, ook op een site die je niet zelf beheert. Wil je dieper gaan, met een crawl over meerdere pagina's of het testen van formulieren, dan vraagt dat om verificatie van het domein.

Veelgestelde vragen

Is een security scan hetzelfde als een pentest?

Nee. Een scan controleert geautomatiseerd op bekende, meetbare problemen. Een pentester denkt na, combineert zwakheden en probeert er daadwerkelijk doorheen te komen. De scan is de laag ervóór: hij ruimt het voor de hand liggende op, zodat een pentester zijn tijd aan het interessante werk kan besteden.

Merkt mijn server iets van de scan?

Je ziet een handvol requests in je logs vanaf onze user-agent. Er is geen sprake van belasting die op een aanval lijkt en er wordt niets herhaald afgevuurd.

Kan ik een site scannen die niet van mij is?

Ja, voor de gratis scan. Die doet alleen wat elke browser ook doet: publieke pagina's opvragen. De diepere varianten crawlen meerdere pagina's en raken formulieren aan, en zijn daarom afgeschermd.