Methodologie & Bronnen
ScanZeker raadpleegt meerdere externe bronnen en protocollen per scan. Hieronder vind je precies welke databronnen we gebruiken, welke controles we uitvoeren en hoe onze scores tot stand komen.
Twee outputs, één scan
Elke ScanZeker-scan vult twee complementaire views: een lineair rapport en een interactieve kaart. Je hoeft niet te kiezen en je wisselt binnen de resultatenpagina met één klik tussen beide.
Website Headers
We checken de instellingen die jouw webserver meestuurt bij elke pagina. Die instellingen bepalen of een browser bezoekers beschermt tegen dingen als phishing, afluisteren en klik-trucs. Als je site de bezoeker doorstuurt (bijvoorbeeld van voorbeeld.nl naar www.voorbeeld.nl en dan naar een beveiligde versie), dan checken we elke tussenstop. Krijgen we geen antwoord omdat er een beveiligingsmuur voor zit? Dan openen we jouw site via een echte browser om dezelfde informatie alsnog op te halen.
Bronnen
- ProtocolDirecte HTTP(S) verbinding
Stap 1: GET-request met browser User-Agent, volgt redirect-chain en bewaart security headers uit alle hops
- ProtocolRemote browser (Chromium)
Stap 2 (bij WAF-blokkade): echte headless browser leest response headers na JS-executie. Passeert Akamai, Cloudflare en andere WAFs
- APIMozilla Observatory
Stap 3 (laatste fallback): HTTP Observatory v2 API als browser en HTTP beide falen
- RFC/StandaardGoogle CSP Evaluator
Patronen voor CSP-effectiviteitsanalyse (unsafe-inline, JSONP bypass-domeinen, etc.)
- RFC/StandaardRFC 9116 (security.txt)
Validatie van /.well-known/security.txt inclusief Contact, Encryption, Policy en Expires
Controles
- Drielaags scan-keten: HTTP fetch (snel) → remote browser bij WAF-blokkade → Observatory als laatste fallback
- Remote browser toont "direct gemeten via browser" in de UI, echte headerwaarden, geen extern totaaloordeel
- Content-Security-Policy (CSP, 15pt) met effectiviteitsanalyse: unsafe-inline/eval, wildcard bronnen, data:/blob: URIs, http: bronnen, bekende JSONP bypass-domeinen (googleapis.com, cdnjs, etc.), form-action en object-src checks
- CSP-Report-Only herkenning: 50% van de punten als actieve CSP ontbreekt
- Strict-Transport-Security (HSTS, 10pt) met max-age, includeSubDomains en preload analyse
- X-Content-Type-Options (9pt), X-Frame-Options (5pt), Referrer-Policy (5pt)
- Permissions-Policy (1pt), X-XSS-Protection (1pt, legacy)
- Security headers uit alle redirect-hops worden bewaard (eerste voorkomen wint)
- WAF/bot-blokkade detectie: bij kleine response (<5KB) + fout-status of WAF-tekst wordt remote browser ingeschakeld
- SSRF-bescherming: interne/private URLs worden geblokkeerd vóór browser-scan
- HTTPS redirect, X-Powered-By en Server header lekkage
- security.txt validatie (RFC 9116) inclusief Contact, Encryption, Policy
- Directory listing en foutpagina informatielek
SSL/TLS Deep Scan
We testen grondig hoe sterk de versleuteling is tussen bezoekers en jouw website. Dat is wat het slotje in de browser betekent. Niet elke versleuteling is even veilig: oude varianten zijn gekraakt, nieuwere niet. We kijken ook of het certificaat nog geldig is, bij wie het hoort en of er bekende kwetsbaarheden zijn waarop we moeten letten.
Bronnen
- APIQualys SSL Labs
Industriestandaard voor SSL/TLS-beoordeling
- ProtocolDirecte TLS-scan (fallback)
Eigen TLS-handshake als SSL Labs niet bereikbaar is
Controles
- SSL Labs Grade (A+ t/m F)
- Protocol-ondersteuning (TLS 1.0 t/m 1.3, SSL)
- Forward Secrecy
- HSTS-configuratie
- OCSP Stapling
- Heartbleed, POODLE, BEAST, FREAK, Logjam, DROWN, ROBOT
- Cipher suite sterkte
- Certificaat-chain validatie
E-mail Beveiliging
Oplichters kunnen proberen mails te sturen die eruitzien alsof ze van jouw bedrijf komen (spoofing). We checken of je de instellingen hebt staan die dat tegenhouden. Drie maatregelen werken samen: SPF zegt welke servers namens jou mogen mailen, DKIM zet er een digitaal waarmerk op, en DMARC zegt wat er moet gebeuren als een mail die twee controles faalt. Verstuur je geen mail vanaf dit domein? Dan checken we of je dat expliciet hebt dichtgezet.
Bronnen
- ProtocolDNS queries (TXT, MX)
Directe DNS-lookups voor SPF, DKIM, DMARC, MTA-STS
- RFC/Standaard
- RFC/Standaard
- RFC/Standaard
Controles
- Kernscore (100 punten): SPF (25pt), DMARC (30pt), DKIM (25pt), MX (20pt)
- SPF record aanwezigheid en policy (-all vs ~all vs ?all)
- DKIM selectors en sleutelsterkte (2048-bit RSA of ed25519)
- DMARC policy (none/quarantine/reject) en rapportage (rua)
- MX records, fallback en provider-detectie
- Extra hardening (informatief, geen scoreimpact): MTA-STS, TLS-RPT, BIMI
- No-mail domein detectie: SPF -all zonder includes + geen MX = apart scoringmodel
DNS Beveiliging
DNS is het telefoonboek van internet: het vertaalt een domeinnaam naar het adres van de server die de website draait. We checken of jouw telefoonboek-regels goed beschermd zijn. Als die beveiliging ontbreekt, kan een aanvaller bezoekers stiekem naar een nep-versie van jouw site sturen zonder dat ze het doorhebben.
Bronnen
- ProtocolDNS queries (SOA, NS, AAAA, CAA)
- APIGoogle DNS-over-HTTPS
DNSSEC-validatie via AD flag, DNSKEY en DS records
- APICloudflare DNS-over-HTTPS
Fallback DNSSEC-validatie via AD flag
- APICloudflare RPKI API
Route Origin Validation (ROV) voor BGP-beveiliging
- ProtocolDNSSEC validatie
Multi-provider check: AD flag (Google + Cloudflare), DNSKEY records (type 48), DS records (type 43)
Controles
- DNSSEC inschakeling en validatie (20pt, kernmaatregel tegen DNS-spoofing)
- Nameserver redundantie (20pt)
- SOA record aanwezigheid (15pt)
- CAA records voor certificaatuitgifte beperking (12pt)
- IPv6-ondersteuning via AAAA records (3pt, bonus, moderniseringssignaal)
- RPKI route origin validatie (5pt, geavanceerd, niet hard straffen bij onbekend)
- DANE/TLSA records (3pt, zeer geavanceerd, bonus)
- DNS-provider detectie voor contextbewuste aanbevelingen
Server Exposure
Servers hebben allemaal "deuren" die open of dicht kunnen staan (poorten). Sommige deuren horen open te zijn (bijvoorbeeld voor je website), andere horen juist dicht omdat er gevoelige dingen achter zitten (databases, beheer-panelen). We kijken welke deuren er openstaan, wat erachter draait en of daar bekende problemen mee zijn. We checken ook of externe bronnen dit IP-adres al gemeld hebben als verdacht, zodat open deuren die er al in het vizier zijn zwaarder meetellen.
Bronnen
- APIShodan
Betaalde licentie voor poorten, CVE's, services en OS-fingerprints (passieve cache)
- ProtocolTCP-verificatie
Lichte actieve TCP-handshake op door Shodan gerapporteerde poorten om de cache te bevestigen op moment van scan
- APIAlienVault OTX
Open threat intelligence (pulse feeds en tags), gebruikt als context-versterker
- APIAbuseIPDB
IP-abuse rapportage en confidence score, gebruikt als context-versterker
- APINVD (NIST CVE-database)
Versie-gebaseerde CVE-verrijking voor whitelisted producten (nginx, apache, openssh, redis, elasticsearch, mongodb, docker)
Controles
- Open poorten en services, inclusief control-panel poorten (cPanel 2082/2083, WHM 2086/2087, Webmail 2095/2096, DirectAdmin 2222, Plesk 8443, Webmin 10000)
- Lichte TCP-verificatie per Shodan-poort: handshake bevestigt of de service nu daadwerkelijk antwoordt (Live bevestigd / Niet meer bereikbaar / Niet live bevestigd). We proberen alleen wat Shodan al rapporteert, breiden de attack surface niet uit, met 2,5s timeout en max 20 poorten op risico-prioriteit (Kritiek > Hoog > Middelmatig)
- Interstitial-detectie: cPanel JS-challenges en Cloudflare bot-checks worden vertaald naar begrijpelijke labels
- Bekende CVE-kwetsbaarheden via Shodan + NVD-verrijking per service-product
- Threat-intel correlatie: AbuseIPDB (≥25% confidence) of OTX-pulses worden gekoppeld aan open beheer-/database-/control-plane services
- Context-versterker bumpt risico-label naar Hoog voor: SSH, RDP, SMB, MSSQL, PostgreSQL, MySQL, VNC, LDAP, SNMP, NFS
- Context-versterker bumpt risico-label naar Kritiek voor: Docker API, Kubernetes API, kubelet, Jenkins, Redis, MongoDB, Elasticsearch, Memcached, CouchDB
- Threat-intel zonder open kwetsbare service blijft informatief, niet alarmerend
- CDN/proxy-detectie via ASN, organisatie, rDNS (Cloudflare, Fastly, Akamai, etc.)
- CDN-standaardpoorten worden herkend en niet meegeteld in de score
- Shared infra detectie: provider-herkenning en domein-telling op IP-niveau
- False positive filtering: compromised-tags en EOL-OS op gedeelde hosting
- Per-service AuditDetail: aparte mapping voor Elasticsearch, Redis, MongoDB, RDP, SMB, Docker API, Kubernetes API, kubelet, Jenkins, VNC, X11, Memcached
Technologie Stack
Elke website draait op software: een webserver (zoals nginx of Apache), vaak een CMS (zoals WordPress), een framework en soms extra tools. We kijken welke software aan de buitenkant zichtbaar is. Als je site te veel prijsgeeft over welke versie je draait, maak je het hackers makkelijker om bekende zwakke plekken te zoeken.
Bronnen
- ProtocolHTTP header fingerprinting
Server, X-Powered-By, X-Generator, en 40+ specifieke headers (X-Akamai-*, cf-ray, x-amz-cf-id, x-vercel-id, x-nf-request-id, etc.)
- ProtocolHTML/DOM patroonherkenning
Meta tags, script sources, CSS classes, inline patronen
- ProtocolSet-Cookie fingerprinting
PHPSESSID, JSESSIONID, ak_bmsc (Akamai), laravel_session, connect.sid, etc.
Controles
- WAF-detectie: Cloudflare (cf-ray), Akamai (headers + Bot Manager cookies), Imperva/Incapsula, AWS WAF, Azure WAF (Front Door + App Gateway), Google Cloud Armor, Fastly NGWAF, Sucuri, Barracuda, F5 BIG-IP, FortiWeb, Wallarm. Europese alternatieven: OVHcloud (Frankrijk), Scaleway (Frankrijk), Bunny Shield (Slovenië), G-Core Labs (Luxemburg), CDN77 (Tsjechië)
- CDN-detectie: Cloudflare, Akamai, Fastly, AWS CloudFront, Azure Front Door, KeyCDN, StackPath, Bunny.net, OVHcloud, Scaleway, G-Core Labs, CDN77, Vercel, Netlify, TransIP
- Hosting-detectie: Vercel, Netlify, Fly.io, Render, Railway, Heroku, Google App Engine, Deno Deploy
- Webserver fingerprinting: Nginx, Apache, Microsoft IIS, LiteSpeed, OpenResty, Caddy, Envoy, Gunicorn, Uvicorn, Kestrel
- Framework/CMS detectie: WordPress, Drupal, Shopify, Next.js, Nuxt.js, React, Vue, Gatsby, Laravel, Django, Flask, ASP.NET, Ruby on Rails, Express.js
- Taaldetectie via headers en cookies: PHP, Java, Python, Ruby, Node.js.NET
- Platform-aware analyse (managed hosting en CDN-platformen worden anders beoordeeld)
- Server header informatielek beoordeling
- Directory listing detectie
- Error page disclosure controle
- Third-party script inventarisatie per extern domein (eigen subdomeinen worden correct als first-party herkend)
- Subresource Integrity (SRI) controle per extern script
- Supply chain risico via trust-tiers: grote providers (Google, Cloudflare), open-source CDNs, analytics/tracking, onbekende domeinen
Domein Beveiliging
Een domeinnaam is geregistreerd bij een partij die het voor je beheert (de registrar). We checken hoe oud dat domein is, wie het beheert, en of er sloten op staan die voorkomen dat iemand het stiekem overneemt. Voor subdomeinen (zoals admin.voorbeeld.nl) kijken we naar de gegevens van het hoofddomein, want subdomeinen worden niet apart geregistreerd.
Bronnen
- ProtocolWHOIS protocol
Directe WHOIS-query via whois servers
- ProtocolRDAP (Registration Data Access Protocol)
Moderne opvolger van WHOIS via IANA bootstrap
Controles
- Domeinleeftijd
- Registrar informatie
- DNSSEC ondertekening (via WHOIS)
- Privacy/WHOIS bescherming
- Registratiedatum
Reputatie Check
We vragen aan verschillende organisaties of ze jouw domein of server-adres al eerder als verdacht hebben geregistreerd: phishing, malware, spam of misbruik. Als Google, Microsoft of grote anti-spam-diensten je markeren als kwaadaardig, krijgen bezoekers waarschuwingen in hun browser en belanden je mails in de spambox. Alleen bronnen met een goede reputatie tellen mee, bekende ruisbronnen laten we bewust weg om valse alarmen te voorkomen.
Bronnen
- APIGoogle Safe Browsing
Realtime threat-database die Chrome, Firefox en Safari gebruiken voor waarschuwingsschermen bij phishing en malware
- DatabaseSpamhaus ZEN
SBL, XBL en CSS gecombineerd, primaire bron (zen.spamhaus.org)
- DatabaseBarracuda Central
Barracuda Reputation Block List, primaire bron (b.barracudacentral.org)
- DatabaseSpamhaus DBL
Domain Block List, primaire bron (dbl.spamhaus.org)
- DatabaseSURBL
Spam URI Reputation Block List (multi.surbl.org)
- DatabaseURIBL
URI Black List voor phishing/spam (black.uribl.com)
- DatabaseSpamCop
Aanvullende bron, gebaseerd op spam-meldingen (bl.spamcop.net)
- DatabaseComposite Blocking List
Aanvullende bron, botnets en malware-infecties (cbl.abuseat.org)
Controles
- Google Safe Browsing v4: phishing (SOCIAL_ENGINEERING), malware, ongewenste software (UNWANTED_SOFTWARE), potentieel schadelijke applicaties (PHA)
- Bij Safe Browsing-hit: zware score-penalty (-50), risk level forced naar Kritiek, top-level waarschuwingsbanner, géén automatische F zodat één bron het hele model niet kaapt
- IP-reputatie tegen 4 DNSBL databases
- Domein-reputatie tegen 3 URI blacklists
- Strikte filtering van false positives (Spamhaus PBL, cloud-resolver errors)
- Onderscheid primaire bronnen vs. aanvullende signalen
Certificaten
Elk SSL-certificaat dat ooit voor jouw domein is uitgegeven wordt openbaar gelogd in een publiek register. We kijken welke certificaten er in dat register staan. Dat geeft een beeld van welke partijen namens jou certificaten hebben aangevraagd. Een onverwacht certificaat kan een teken zijn dat iemand anders zich probeert voor te doen als jouw organisatie.
Bronnen
- Databasecrt.sh (Certificate Transparency)
Comodo CT log aggregator
Controles
- Totaal aantal uitgegeven certificaten
- Wildcard certificaten
- Laatste uitgever (CA)
- Geldigheidsduur
- Verdachte of onverwachte certificaten
Subdomains & Infrastructure
Naast je hoofddomein (voorbeeld.nl) bestaan vaak allerlei subdomeinen (mail.voorbeeld.nl, staging.voorbeeld.nl, oud.voorbeeld.nl). Soms vergeten teams die, en vergeten subdomeinen met verouderde software zijn een bekende manier waarop aanvallers binnenkomen. We zoeken in drie publieke bronnen welke subdomeinen er bestaan, checken welke nog leven, en signaleren risico's zoals verweesde namen die iemand kan overnemen of vergeten loginpagina's. Op verzoek kun je per subdomein een diepere analyse starten waarbij we ook kijken naar TLS-config, ontbrekende security-headers, login-pagina's en wat de buitenwereld over die specifieke server weet.
Bronnen
- Databasecrt.sh (Certificate Transparency)
Primaire CT-bron, breedste dekking
- APICertspotter (SSLMate)
Tweede CT-bron, dekking als crt.sh niet beschikbaar is
- APIAlienVault OTX (passieve DNS)
Derde bron met observaties uit malware-sandboxes en passieve DNS-collectoren, vangt subs die niet in CT-logs staan
- ProtocolDNS wordlist enumeratie
Test 200+ veelvoorkomende subdomeinnamen, fallback bij volledig falen van CT-bronnen
- ProtocolTCP reachability check
Verbindingstest op poort 443 en 80 (5s timeout) om daadwerkelijke bereikbaarheid te bevestigen
- ProtocolCNAME resolution
Detecteert dangling CNAMEs naar externe services
- ProtocolHTTP fingerprinting
Verificatie van onbeheerde services (Heroku, S3, Azure Traffic Manager, GitHub Pages, Vercel, etc.)
- ProtocolReverse DNS (PTR records)
Detecteert hosting provider via rDNS patronen
- ProtocolIP range matching
Fallback voor bekende CDN/cloud CIDRs (Cloudflare, Vercel, Fastly, etc.)
- APIShodan Host API (deep-scan)
Per-IP enrichment in fase 2: ports, banners, ASN, indicatieve CVEs. Apart van apex-exposure scan; per uniek non-CDN/non-private IP, met 24u cache.
- APINVD CVE-database (deep-scan)
Banner-versie → bekende CVEs voor 8 whitelisted producten. Top 5 per service, gesorteerd op CVSS-score, 24u cache per CPE-string.
Controles
- Fase 1: drie CT-bronnen + DNS-wordlist parallel, met circuit-breaker per bron en wall-clock budget van 50s
- Drielaags status: bereikbaar (TCP connect ok), DNS actief (resolvt maar niet bereikbaar op 80/443), inactief (geen DNS)
- Sorteer op risico: TAKEOVER → RISICO → CHECK (sensitive+bereikbaar) → INFO (sensitive+DNS) → overige bereikbaar → DNS actief → inactief
- Risicobadges in tabel: CHECK (amber, sensitive+bereikbaar), INFO (grijs, sensitive+DNS), RISICO (amber, potentiële takeover), TAKEOVER (rood, bevestigd)
- Gevoelige subdomeinen (admin, staging, test, etc.) met gedifferentieerde scoring: bereikbaar -5pt, DNS-only -2pt
- Subdomain takeover detectie via CNAME + HTTP-fingerprinting (15+ services), met onderscheid bevestigd kwetsbaar vs verificatie nodig (Azure Traffic Manager-uitzondering)
- Hosting provider identificatie (AWS, Azure, Google Cloud, Vercel, Hetzner, etc.)
- CDN detectie via ASN-lijst (Cloudflare, Fastly, CloudFront, Akamai, BunnyCDN, Azure CDN, Google CDN, KeyCDN, CDNetworks, Limelight)
- SaaS platform detectie (Microsoft 365, Google Workspace, Shopify, etc.)
- Nederlandse hosters (TransIP, Hostnet, Antagonist, Mijndomein, LeaseWeb)
- Fase 2 (deep-scan, max 15 hosts): TLS-versie + cipher per host, ontbrekende headers (HSTS, CSP, X-Frame-Options), login-detectie via homepage-scrape + 44 standaardpaden parallel
- Fase 2 host-exposure: per uniek non-CDN/non-private IP een Shodan-host-call. Private/loopback/CGNAT-IPs worden vooraf gefilterd. CDN-IPs (op basis van ASN) krijgen alleen een context-label, geen findings, omdat Shodan-data daar generiek en niet zinvol is.
- Fase 2 ASN-vergelijk: subdomein op andere ASN dan apex = aandachtspunt (amber chip), niet automatisch risico. Tekst: "controleer of dit bewust onderdeel is van de architectuur".
- Fase 2 NVD CVE-enrichment: alleen voor whitelisted producten (nginx, Apache HTTPD, OpenSSH, PHP, WordPress, MariaDB, MySQL, PostgreSQL), top 5 CVEs per service gesorteerd op CVSS V3.1/V3.0/V2 score, expliciet als indicatief gelabeld met backport-disclaimer (distros backporten security fixes zonder versie-string te wijzigen).
Datalekken
Als een website (bijvoorbeeld van een leverancier) gehackt wordt, komen wachtwoorden van gebruikers vaak op straat te liggen. We kijken of e-mailadressen die eindigen op jouw domein voorkomen in bekende datalekken of op computers die besmet zijn geweest met wachtwoord-stelende malware. We maken onderscheid tussen medewerkers en klanten, omdat medewerkersaccounts vaak gevoeliger zijn voor een bedrijf dan een enkele klant.
Bronnen
- APIHave I Been Pwned
Bekendste bron voor datalekken
- APIHudsonRock Cavalier
Infostealer-malware monitoring met accounttype-onderscheid
Controles
- Datalekken per bron
- Gelekte datatypes (wachtwoorden, e-mail, IP, etc.)
- Infostealer-infecties met accounttype-onderscheid: medewerkers (organisatierisico) vs gebruikers (bezoeker's apparaat besmet)
- Severity op basis van accounttype: medewerkers-accounts wegen zwaarder dan gebruikersaccounts
- Beveiligingsimpact correctie alleen bij medewerker-infostealer signalen, niet bij gebruikers-only
- Paste dumps met gelekte data
Cookies & Privacy
We checken welke cookies je site plaatst vóórdat de bezoeker ergens op heeft geklikt, en welke tracking-scripts al meteen meedraaien. In Europa moet je mensen toestemming vragen voordat je tracking-cookies plaatst. We openen de site met een echte browser om precies te meten wat er gebeurt voor iemand de cookie-popup ziet of ermee interacteert.
Bronnen
- ProtocolHTTP Set-Cookie headers
Stap 1: cookies die de server direct meegeeft (= vóór consent)
- ProtocolRemote browser (Chromium)
Stap 2 (bij WAF-blokkade): echte browser verzamelt cookies na JS-executie, inclusief cookies die pas na page load verschijnen
- ProtocolHTML/script patroonherkenning
Detecteert 40+ tracking platforms en 26+ consent tools
- ProtocolJavaScript bundle analyse
Downloadt en parst JS-bestanden voor verborgen tracking en consent-code
- ProtocolPreconnect/DNS-prefetch hints
Onthult tracking-domeinen in initiële HTML
- DatabaseCookie knowledge base
Classificatie van 100+ bekende cookies (platform, categorie, retentie)
- DatabaseBekende consent wall domeinen
DPG Media (nu.nl, ad.nl, etc.), Mediahuis (telegraaf.nl, etc.), RTL/Talpa
Controles
- Laag 1: Pre-consent compliance. Worden niet-essentiële cookies geplaatst vóór toestemming?
- Laag 2: Privacy profiel. Welke tracking is vermoedelijk actief na toestemming?
- Laag 3: Cookie hygiëne. Lifecycle/retentie (max-age/expires), security flags, third-party domeinen
- Drie signaalniveaus binnen Laag 1: bewezen (cookie gezet), sterk signaal (script geladen), indicatie (preconnect)
- Functionele cookies (sessie, CSRF, load balancer) uitgesloten van penalties
- Consent banner / CMP detectie (26+ platforms, inclusief JS-bundle scan)
- Bot/WAF-blokkade detectie: bij Access Denied of gelijkwaardige response + bekende uitgevers wordt consent wall aangenomen
- Cookie lifecycle classificatie (sessie, <24u, <30d, <1j, >1j)
- Geen consent + tracking: zwaardere scoring dan tracking achter consent
Hoe komt de score tot stand?
De score van ScanZeker is geen optelsom van aanvinkbare controls. In plaats daarvan beoordelen we wat we daadwerkelijk kunnen vaststellen over het risico van een domein. De impact van elke bevinding wordt bepaald op basis van drie principes:
Opbouw van de score
Elke module levert een score van 0 tot 100. De totaalscore is een gewogen gemiddelde, waarbij fundamentele beveiligingsmaatregelen en direct bereikbare risicodiensten het zwaarst meewegen: SSL/TLS (18%), Website Headers (14%), E-mail (12%), Server Exposure (12%), Datalekken (10%), DNS en Subdomains (elk 8%), Certificaten en Technologie (elk 5%), Cookies (4%), WHOIS en Reputatie (elk 2%). Dit vormt de basisscore.
De labels beschrijven wat een externe scan kan vaststellen, niet de algehele beveiliging van de organisatie. Een hoge score is een positief extern signaal, geen garantie voor interne weerbaarheid; een lage score is een aanleiding tot opvolging, geen veroordeling.
Daarbovenop wordt een aparte beveiligingsimpact toegepast voor bevindingen die zwaarder wegen dan configuratie alleen, zoals direct bereikbare services of duidelijke risicocombinaties. Deze correctie kan de score met maximaal 25 punten verlagen.
Aandachtspunten naast de score
Naast de gewogen totaalscore toont het rapport een Aandachtspunten-paneel met de meest urgente individuele bevindingen, gesorteerd op ernst (kritiek, hoog, middel, laag). Dit is een aparte prioritering bovenop dezelfde scan-data, bedoeld voor "wat moet ik nu eerst doen". De score geeft de algehele staat aan, de aandachtspunten geven de volgorde van actie aan.
Kritieke aandachtspunten worden altijd zichtbaar getoond (anti-paniek principe: één kritiek mag nooit verstopt zijn). Daarna geldt een minimum van twee zichtbare items in totaal, met de rest achter een "toon meer"-knop. Sommige aandachtspunten worden samengevoegd of vervangen door een sterkere variant, zodat dezelfde bevinding niet dubbel telt.
Beveiligingsimpact
Bovenop de gewogen basisscore past ScanZeker een aparte correctielaag toe voor bevindingen die zwaarder wegen dan configuratiepunten. Deze correctie is contextbewust: bij shared hosting, mailservers of cPanel-omgevingen worden bepaalde poorten en protocollen anders gewogen. Maximaal -25 punten.
De correctie is opgebouwd uit de volgende categorieën:
De eindscore is: basisscore minus beveiligingsimpact (max -25). Beide worden apart getoond in het rapport, zodat je precies kunt zien waar de correctie vandaan komt.
Beïnvloedbaarheid van bevindingen
Een technisch juiste bevinding is niet altijd iets wat jij als domeineigenaar zelf kunt wegnemen. Op gedeelde hostingomgevingen worden bijvoorbeeld mailprotocollen (POP3, IMAP, SMTP) en beheerpanelen (cPanel, Plesk, Webmin) vrijwel altijd door de hostingprovider beheerd. ScanZeker labelt daarom per bevinding wie er daadwerkelijk aan de knoppen zit, zodat fix-advies aansluit bij wat haalbaar is.
De classificatie is bewust conservatief: bij twijfel over de context valt een poort terug op direct, zodat we geen risico's wegmoffelen voor domeinen met eigen beheer. Kritieke services zoals databases, control-plane poorten (Docker, Kubernetes, Jenkins) en plaintext netwerkdiensten (Telnet, RDP, VNC, Redis, MongoDB) blijven altijd op direct staan, ook in shared-hosting contexten. Ze horen nooit op het publieke internet, ongeacht wie de infrastructuur beheert.
In de huidige versie is het label puur informatief: een badge op de poort-kaart maakt duidelijk wanneer een bevinding buiten de directe invloedssfeer ligt, maar de beveiligingsimpact-correctie wordt er nog niet op afgeschaald. Een optionele tier-factor (waarbij indirecte en platform-gebonden bevindingen minder zwaar meetellen) staat voorbereid achter een feature-flag, zodat we de kalibratie eerst tegen een bredere dataset kunnen toetsen voordat we hem activeren.
Threat intelligence als context-versterker
AbuseIPDB en AlienVault OTX leveren signalen dat een IP-adres gerapporteerd is voor misbruik (scanning, brute-force, C2, phishing). Op zichzelf zegt zo'n score weinig, een AbuseIPDB-percentage van 42% leidt zonder context tot vage aanbevelingen. ScanZeker gebruikt deze signalen daarom niet als losse score, maar als amplifier op bestaande exposure-bevindingen: een verhoogde abuse-score telt pas mee als er ook een open beheer- of dataservice is die concreet misbruikt kán worden.
Het verschil zit in de framing: niet “IP heeft abuse-score 42”, maar “dit IP wordt actief gescand door aanvallers terwijl jouw Docker API publiek bereikbaar is, dat is geen hypothetisch risico meer”. Voor Google Safe Browsing geldt een vergelijkbare logica, maar zwaarder: een hit is een direct extern signaal dat browsers al een waarschuwingsscherm tonen aan bezoekers. Daarom volgt daar wel een zware score-penalty plus top-level banner, maar géén automatische grade-F zodat één bron het hele model niet kaapt.
Shared infra detectie
ScanZeker herkent wanneer een IP-adres wordt gedeeld met meerdere domeinen. Dit is relevant omdat open poorten op IP-niveau niet altijd toe te wijzen zijn aan de specifieke applicatie die wordt gescand.
De detectie werkt op twee niveaus:
Bij minder dan 10 domeinen op een IP (zoals een kleine gedeelde hostingomgeving) worden poortbevindingen nog steeds meegenomen, omdat de kans groot is dat de poorten daadwerkelijk bij de gescande applicatie horen.
Mogelijke Aanvalspaden
Naast losse bevindingen combineert ScanZeker signalen uit meerdere modules tot mogelijke dreigingsscenario's. Dit toont niet alleen wat er mis is, maar hoe het samen een aanvalspad zou kunnen vormen.
Belangrijke kanttekening: dit zijn scenario's op basis van observeerbare signalen, geen bevestigde kwetsbaarheden. Ze zijn bedoeld als startpunt voor verificatie door een beveiligingsprofessional, niet als vaststelling dat een aanval daadwerkelijk mogelijk is.
Elk aanvalspad krijgt een severity (hoog risico, verhoogd, aandacht) en een concreet advies. Dit helpt bij het signaleren en prioriteren van risico's.
Uitvalbestendigheid
Alle externe API-bronnen zijn optioneel. Als een bron niet beschikbaar is (door rate limits, onderhoud of netwerkstoringen), gaat de scan gewoon door met de overige bronnen. De score wordt dan berekend op basis van de beschikbare data.
Bij WAF/bot-blokkade (zoals Akamai, Cloudflare challenge pages) worden headers niet leesbaar via een standaard HTTP-verzoek. In dat geval wordt een externe headless browser ingezet die de WAF passeert met een echte TLS-fingerprint en JavaScript-executie. Lukt ook dat niet, dan dient Mozilla Observatory als laatste fallback voor de headerscore. Het rapport toont de gebruikte meetmethode: "direct gemeten" (HTTP), "direct gemeten via browser" (headless Chromium), of "Observatory" (extern totaaloordeel). Bij cookies wordt bij WAF-blokkade eveneens de browser ingezet om cookies na JS-executie te verzamelen. Als fallback wordt bij bekende uitgevers (DPG Media, Mediahuis) een consent wall aangenomen.