Nederlandse betaald voetbalclubs zijn allang niet meer alleen zichtbaar in het stadion. Kaartverkoop, merchandise, zakelijke dienstverlening, nieuwsvoorziening, supportersaccounts en marketingcampagnes lopen voor een groot deel via digitale kanalen. Daarmee is de website van een club niet alleen een communicatiemiddel, maar ook een belangrijk onderdeel van de digitale voordeur.
Securitytest.nl onderzocht de publiek zichtbare digitale basisbeveiliging van Nederlandse betaald voetbalclubs. Daarbij is gekeken naar officiële clubwebsites uit de Eredivisie en Keuken Kampioen Divisie. Het doel was niet om clubs volledig te pentesten, maar om te bekijken welke beveiligingsmaatregelen vanaf de buitenkant zichtbaar zijn.
De resultaten laten een wisselend beeld zien. Vrijwel alle onderzochte clubs hebben de digitale basis op onderdelen op orde, maar de verschillen zijn opvallend groot. Sommige websites beschikken over vrijwel alle onderzochte basismaatregelen, terwijl andere clubs nog relatief eenvoudige verbeteringen kunnen doorvoeren. Vooral op het gebied van security headers, e-mailbeveiliging en DNS-configuraties lopen de resultaten sterk uiteen.
Wat hebben we gemeten?
Het onderzoek richtte zich op beveiligingsmaatregelen die vanaf het openbare internet zichtbaar zijn. Daarbij is gekeken naar zaken zoals HTTPS, HSTS, security headers, DNSSEC, SPF, DMARC, CAA-records, wildcard DNS en opvallende technische verwijzingen in publieke JavaScript-bestanden.
Bewust niet onderzocht zijn onderdelen waarvoor toegang tot interne systemen of gebruikersaccounts nodig is. Het onderzoek zegt daardoor iets over de zichtbare digitale basis van een clubwebsite, niet over de volledige beveiliging van de achterliggende systemen.
Dat onderscheid is belangrijk. Een club kan aan de buitenkant veel basismaatregelen hebben, maar intern alsnog kwetsbaarheden hebben. Andersom betekent een ontbrekende header of zwakke e-mailpolicy niet automatisch dat een website direct misbruikbaar is. De waarde van dit onderzoek zit vooral in het zichtbaar maken van verschillen in basisinrichting.
Waarom 34 metingen en geen 38?
In totaal zijn 38 clubvermeldingen meegenomen in het onderzoek. Niet iedere club heeft echter een volledig eigen technische omgeving. Jong-teams maken namelijk gebruik van hetzelfde hoofddomein als de eerste selectie.
Om dubbele metingen te voorkomen zijn deze domeinen slechts één keer meegenomen. Daardoor zijn de percentages en rankings gebaseerd op 34 unieke technische metingen.
Dat geeft een eerlijker beeld van de digitale basisbeveiliging van de onderzochte websites.
Ranglijst: wie heeft de basis het beste op orde?
Op basis van de onderzochte beveiligingsmaatregelen is een ranglijst samengesteld. Daarbij is gekeken naar de aanwezigheid van onder andere security headers, DNS-beveiliging, e-mailbeveiliging en aanvullende technische aandachtspunten.
De ranglijst moet niet worden gezien als een overzicht van de ‘veiligste clubs van Nederland’. Daarvoor is een veel diepgaander onderzoek nodig. De score laat vooral zien welke clubs tijdens deze meting de meeste zichtbare basismaatregelen op orde hadden.
📊 Hoe moet je deze ranking lezen?
De ranglijst is gebaseerd op een score van maximaal 60 punten voor zichtbare beveiligingsmaatregelen. Daarbij zijn onder andere security headers, DNS- en e-mailbeveiliging en aanvullende technische aandachtspunten meegenomen.
Een hogere score betekent dat tijdens deze meting meer van de onderzochte beveiligingsmaatregelen op orde waren. De score zegt vooral iets over de technische basis die vanaf het internet zichtbaar is. Onderdelen achter een login, ticketing- en betaalprocessen en interne systemen vallen buiten dit onderzoek.
De ranking is daarom geen ranglijst van “veiligste clubs”, maar een vergelijking van publiek zichtbare basismaatregelen. De volledige scoremethodiek is onderaan dit artikel opgenomen.
Opvallend is dat de ranglijst niet simpelweg de sportieve of financiële verhoudingen volgt. Excelsior Rotterdam deelt de eerste plaats met PSV, terwijl clubs als N.E.C., FC Eindhoven en sc Heerenveen hoger eindigen dan sommige grotere namen.
Dat laat zien dat een sterke digitale basis niet afhankelijk hoeft te zijn van de omvang van een club of het beschikbare budget. Veel van de onderzochte maatregelen zijn relatief eenvoudig te implementeren en hebben vooral te maken met beheer, configuratie en periodieke controle.
Aan de onderkant van de ranglijst zien we juist dat meerdere ontbrekende basismaatregelen snel kunnen doorwerken in de totaalscore. Dat betekent niet automatisch dat deze clubs kwetsbaar zijn, maar wel dat er op de zichtbare technische basis meer ruimte voor verbetering bestaat.
HTTPS is breed aanwezig
Een positieve uitkomst is dat HTTPS bij alle 34 unieke domeinmetingen actief was. Dat is inmiddels een minimale basisvoorwaarde voor publieke websites, zeker wanneer bezoekers formulieren invullen, inloggen, tickets kopen of worden doorgestuurd naar externe diensten.
HTTPS alleen zegt echter niet dat de beveiliging volledig op orde is. Het versleutelt de verbinding tussen bezoeker en website, maar voorkomt niet automatisch andere problemen. Denk aan ontbrekende security headers, zwakke e-mailbeveiliging, verkeerd ingestelde DNS-records of publieke technische informatie die onnodig veel inzicht geeft in de achterliggende omgeving.
Daarom is in het onderzoek ook gekeken naar aanvullende maatregelen.
HSTS ontbreekt bij bijna een derde
HSTS was aanwezig bij 24 van de 34 unieke domeinmetingen. Dat betekent dat 10 domeinen geen HSTS-header lieten zien tijdens de meting.
HSTS, voluit HTTP Strict Transport Security, vertelt browsers dat een website alleen via HTTPS benaderd mag worden. Daardoor wordt het risico kleiner dat bezoekers per ongeluk of via een omweg op een onbeveiligde HTTP-versie terechtkomen.
Voor websites van betaald voetbalclubs is dit geen exotische beveiligingsmaatregel. Het is een redelijk standaard onderdeel van een volwassen HTTPS-configuratie. Het ontbreken ervan betekent niet direct dat een website kwetsbaar is, maar laat wel zien dat de HTTPS-inrichting nog niet overal volledig is aangescherpt.
Content-Security-Policy blijft achter
Een Content-Security-Policy werd aangetroffen bij 18 van de 34 unieke domeinmetingen. Bij 16 domeinen werd geen CSP-header gezien.
Dat is opvallend, omdat moderne clubwebsites vaak veel externe scripts laden. Denk aan analytics, tag managers, video-embeds, advertentieplatforms, social media pixels, ticketingwidgets, chatwidgets en marketingtools. Juist in zo’n omgeving helpt een CSP om beter te sturen welke bronnen scripts, frames, afbeeldingen en andere content mogen laden.
Een ontbrekende CSP betekent niet automatisch dat er sprake is van een kwetsbaarheid. Toch is het wel een duidelijk aandachtspunt. Zonder CSP is er minder technische begrenzing wanneer een scriptinjectie of fout in externe content optreedt. Voor websites met veel third-party scripts is dat geen theoretisch punt, maar een realistisch onderdeel van de aanvalsoppervlakte.
In de praktijk is CSP niet altijd eenvoudig goed in te richten. Een te strenge policy kan functionaliteit breken. Een te ruime policy voegt weinig toe. Toch is dat geen reden om CSP helemaal weg te laten. Vaak is een gefaseerde aanpak verstandig: eerst meten met een report-only policy, daarna stapsgewijs aanscherpen.
E-mailbeveiliging: DMARC vaak aanwezig, maar niet altijd afdwingend
DMARC was aanwezig bij 32 van de 34 unieke domeinmetingen. Dat lijkt op het eerste gezicht sterk. Toch zit de nuance vooral in de ingestelde policy.
Bij 19 domeinen stond DMARC op p=none. Dat betekent dat de domeineigenaar wel rapportages kan ontvangen, maar dat ontvangende mailservers niet expliciet de opdracht krijgen om verdachte e-mail te blokkeren of in quarantaine te plaatsen. Slechts 13 domeinen gebruikten een afdwingende policy, zoals quarantine of reject.
DMARC is belangrijk omdat voetbalclubs herkenbare merken zijn. Supporters, sponsoren en zakelijke contacten vertrouwen op communicatie vanuit het clubdomein. Een aanvaller kan misbruik maken van dat vertrouwen met phishingmails die lijken te komen van de club, bijvoorbeeld rond ticketverkoop, merchandise, hospitality of acties.
Een DMARC-policy op p=none is niet verkeerd als startpunt. Het is vaak een logische eerste stap om mailstromen in kaart te brengen. Maar als die instelling langdurig blijft staan, wordt het vooral monitoring zonder afdwinging. Voor bekende merken is het verstandig om toe te werken naar quarantine of reject, mits de legitieme mailstromen goed zijn ingericht.
DNSSEC is geen vanzelfsprekendheid
DNSSEC was aanwezig bij 14 van de 34 unieke domeinmetingen. Bij 20 domeinen werd geen DNSSEC aangetroffen.
DNSSEC helpt te voorkomen dat bezoekers ongemerkt naar een verkeerd systeem worden gestuurd doordat DNS-antwoorden onderweg worden gemanipuleerd. Het is geen maatregel die alle risico’s wegneemt, maar vormt wel een extra beschermlaag rond een domeinnaam.
Tijdens het onderzoek bleek dat DNSSEC bij minder dan de helft van de onderzochte domeinen actief was. Daarmee behoort DNSSEC tot de maatregelen waarop de verschillen tussen clubs het duidelijkst zichtbaar zijn.
CAA werd niet aangetroffen
Een van de opvallendste uitkomsten van het onderzoek is dat geen enkel onderzocht domein gebruikmaakt van een CAA-record.
Met een CAA-record kan een organisatie aangeven welke certificaatuitgevers SSL-certificaten voor het domein mogen uitgeven. Het is een relatief eenvoudige maatregel die extra controle biedt over certificaatuitgifte.
Juist omdat de implementatie vaak beperkt is, kan dit voor veel organisaties worden gezien als relatief laaghangend fruit.
Wildcard DNS bij 13 domeinen
Wildcard DNS werd vastgesteld bij 13 van de 34 onderzochte domeinen.
Dat hoeft niet direct een probleem te zijn. In sommige omgevingen is wildcard DNS een bewuste ontwerpkeuze. Het kan bijvoorbeeld worden gebruikt voor redirects, multi-tenant omgevingen of applicatieplatformen.
Tegelijkertijd maakt het het lastiger om onderscheid te maken tussen bestaande en niet-bestaande subdomeinen. Daarom is wildcard DNS in dit onderzoek niet als kwetsbaarheid aangemerkt, maar wel als aandachtspunt meegenomen.
Publieke JavaScript-bestanden bevatten veel technische context
Naast headers en DNS-instellingen zijn publieke JavaScript-bestanden geanalyseerd op opvallende technische verwijzingen. Dat leverde vooral context op: API-endpoints, externe diensten, analytics, widgets en configuratiereferenties.
Dit soort informatie is niet automatisch gevoelig. Moderne websites functioneren nu eenmaal met veel client-side code en externe diensten. Toch kan JavaScript onbedoeld inzicht geven in de technische opbouw van een website. Denk aan interne routes, oude endpoints, testverwijzingen, externe widgets of key-achtige waarden.
In dit onderzoek zijn mogelijke secrets en API-keys extra beoordeeld. Daarbij zijn geen bevestigde club-eigen secrets vastgesteld. Enkele key-achtige waarden bleken te herleiden naar third-party scripts of normale client-side configuratie, zoals Google Analytics, Google Maps of publieke reCAPTCHA-sleutels.
Belangrijk is dat tool-output niet één-op-één is overgenomen. Automatische tools geven vaak false positives, bijvoorbeeld omdat woorden als token, password, authorization of api in normale JavaScript-code voorkomen. Alleen bevindingen die herleidbaar waren naar een clubdomein en inhoudelijk relevant bleven na handmatige beoordeling, zijn meegenomen in de interpretatie.
Geen volledige pentest, wel duidelijke patronen
Dit onderzoek is nadrukkelijk geen volledige pentest. Toch worden er duidelijke patronen zichtbaar.
HTTPS is inmiddels breed ingeburgerd. Daartegenover staat dat maatregelen zoals Content-Security-Policy, DNSSEC en afdwingende DMARC-configuraties nog lang niet overal aanwezig zijn.
Ook blijkt dat relatief eenvoudige maatregelen, zoals CAA-records en aanvullende DNS-beveiliging, vaak ontbreken.
Het onderzoek laat daarmee vooral zien dat er tussen clubs aanzienlijke verschillen bestaan in de inrichting van de zichtbare digitale basis.
Waarom dit ertoe doet
Betaald voetbalclubs hebben een bijzondere positie. Ze hebben trouwe supporters, herkenbare merken, zakelijke relaties en vaak veel piekmomenten in online verkeer. Denk aan kaartverkoop, transfers, Europese wedstrijden, merchandise-acties of seizoenkaartcampagnes.
Juist op zulke momenten is digitale betrouwbaarheid belangrijk. Supporters moeten erop kunnen vertrouwen dat zij op de echte website zitten, dat e-mail van de club herkenbaar en betrouwbaar is, en dat de website technisch zorgvuldig is ingericht.
Cybersecurity hoeft daarbij niet altijd te beginnen met een complex traject. Veel verbeteringen zitten juist in de basis:
- security headers goed configureren;
- DMARC van monitoring naar afdwinging brengen;
- DNSSEC en CAA toevoegen waar passend;
- wildcard DNS bewust beheren;
- publieke JavaScript-bestanden periodiek controleren;
- oude test- of dev-verwijzingen opruimen;
- technische serverinformatie beperken.
Dat zijn geen spectaculaire maatregelen, maar ze verkleinen wel het aanvalsoppervlak.
Wat clubs concreet kunnen verbeteren
Voor clubs die hun digitale basis willen versterken, zijn dit logische eerste stappen.
Begin met een actuele inventarisatie van domeinen, subdomeinen en externe diensten. Veel risico ontstaat niet doordat een hoofdwebsite bewust slecht is ingericht, maar doordat oude omgevingen, marketingtools, testverwijzingen of externe leveranciers uit beeld raken.
Controleer daarna de security headers van de hoofdwebsite. HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy en een zorgvuldig opgebouwde Content-Security-Policy horen bij een moderne basisinrichting.
Kijk vervolgens naar e-mailbeveiliging. SPF, DKIM en DMARC moeten niet alleen bestaan, maar ook logisch op elkaar aansluiten. Een DMARC-policy op p=none kan een goed startpunt zijn, maar zou meestal niet het eindpunt moeten blijven. Voor domeinen die actief worden gebruikt voor communicatie met supporters of zakelijke relaties is een afdwingende policy wenselijk.
Neem ook DNS mee. DNSSEC en CAA zijn voor veel organisaties relatief overzichtelijke verbeteringen. Wildcard DNS verdient aparte aandacht: gebruik het alleen bewust en controleer of het niet leidt tot verwarrende of ongewenste subdomeinresponsen.
Tot slot is periodieke controle belangrijk. Websites veranderen continu. Nieuwe scripts, campagnes, leveranciers, widgets en integraties worden vaak onder tijdsdruk toegevoegd. Daardoor kan een configuratie die vandaag netjes is, over een paar maanden alweer afwijken.
Zichtbare basisbeveiliging is geen volledige pentest
Dit onderzoek beoordeelt alleen wat vanaf de buitenkant zichtbaar is. Daarmee zegt het niets definitiefs over interne processen, leveranciersafspraken, incidentrespons, logging, autorisatie, betaalprocessen of de beveiliging achter inlogschermen.
Voor een volledig beeld is een diepgaandere pentest nodig. Daarbij wordt niet alleen gekeken naar headers en DNS-records, maar ook naar de werking van de applicatie zelf. Kunnen gebruikers bij gegevens die niet voor hen bedoeld zijn? Zijn rechten goed afgedwongen? Kunnen functies op een ongewenste manier worden gebruikt? Zijn koppelingen met externe systemen veilig ingericht?
Die vragen vallen buiten dit onderzoek, maar zijn voor clubs met online ticketing, accounts, webshops en zakelijke portalen wel degelijk relevant.
De digitale basis verdient structurele aandacht
De belangrijkste conclusie is niet dat Nederlandse betaald voetbalclubs massaal onveilig zijn. Daarvoor is dit onderzoek te beperkt. Wat het onderzoek wel laat zien, is dat de verschillen tussen clubs groter zijn dan je op basis van de buitenkant zou verwachten.
Sommige organisaties hebben zichtbaar geïnvesteerd in hun digitale basis en beschikken over een groot deel van de onderzochte maatregelen. Andere clubs kunnen met relatief beperkte inspanning nog duidelijke verbeteringen doorvoeren.
Juist omdat veel van deze maatregelen geen grote projecten vereisen, liggen hier concrete kansen om de digitale weerbaarheid van Nederlandse betaald voetbalclubs verder te versterken.
Digitale veiligheid begint zelden bij geavanceerde aanvalstechnieken. Vaak begint het bij het consequent op orde brengen van de basis.
Onderzoeksmethode
Voor dit onderzoek heeft Securitytest.nl gekeken naar de publiek zichtbare digitale basisbeveiliging van Nederlandse betaald voetbalclubs. Het doel was niet om de volledige beveiliging van clubs te beoordelen, maar om vast te stellen welke beveiligingsmaatregelen vanaf het openbare internet zichtbaar zijn.
De meting richtte zich op de officiële websites van clubs uit het Nederlandse betaald voetbal. Daarbij zijn zowel clubs uit de Eredivisie als de Keuken Kampioen Divisie meegenomen. Voor clubs waarvan een Jong-team hetzelfde hoofddomein gebruikt als de eerste selectie, is de technische meting niet dubbel meegeteld. Daardoor zijn de resultaten gebaseerd op unieke domeinmetingen in plaats van op dubbele clubvermeldingen.
De controles zijn uitgevoerd op publiek toegankelijke informatie. Er is geen gebruikgemaakt van inlogaccounts, geen poging gedaan om toegang te krijgen tot besloten omgevingen en er zijn geen kwetsbaarheden actief uitgebuit. Ook zijn er geen formulieren misbruikt, geen brute-forcepogingen uitgevoerd en geen betaal-, ticketing- of klantprocessen getest.
Meetperiode en context
De metingen zijn uitgevoerd in juni 2026. De resultaten zijn een momentopname: websites, DNS-records, headers en configuraties kunnen op ieder moment worden aangepast.
Securitytest.nl is een commerciële aanbieder van securitytesten en pentests. Dit onderzoek is op eigen initiatief uitgevoerd als publiek onderzoek naar zichtbare basismaatregelen. Clubs hebben niet betaald voor deelname aan dit onderzoek en de resultaten zijn niet gebaseerd op klantrelaties.
Omdat het onderzoek uitsluitend gebruikmaakt van publiek zichtbare informatie en geen kwetsbaarheden actief zijn uitgebuit, is vooraf geen hoor en wederhoor toegepast op iedere individuele score. Clubs die hun resultaat willen laten toelichten of feitelijke onjuistheden willen melden, kunnen contact opnemen met info@securitytest.nl. Waar nodig worden correcties of updates verwerkt.
Wat is onderzocht?
De analyse richtte zich op basismaatregelen die voor vrijwel iedere publieke website relevant zijn. Daarbij is gekeken naar onder andere:
- HTTPS en TLS-configuratie;
- aanwezigheid van HSTS;
- security headers, zoals Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy en Permissions-Policy;
- zichtbare technologieën en serverinformatie;
- publieke DNS- en e-mailbeveiligingsmaatregelen, zoals DNSSEC, SPF, DMARC en CAA;
- DMARC-policy, waaronder
none,quarantineenreject; - aanwezigheid van wildcard DNS-records;
- opvallende technische verwijzingen in publieke JavaScript-bestanden, zoals API-endpoints, externe diensten of verwijzingen naar niet-productieomgevingen;
- mogelijke secrets of API-keys in publieke JavaScript-bestanden.
Publieke JavaScript-bestanden zijn geanalyseerd op opvallende technische verwijzingen, zoals endpoints, externe diensten en key-achtige waarden. Wanneer daarbij een verwijzing naar een mogelijke ontwikkel- of testomgeving werd aangetroffen, is alleen beperkt gecontroleerd of deze omgeving publiek bereikbaar was. Er is geen actieve zoektocht uitgevoerd naar ontwikkel-, test- of beheeromgevingen en er zijn geen beheerinterfaces verder onderzocht.
De resultaten geven daarmee een beeld van de zichtbare basisbeveiliging, maar vormen geen volledige pentest. Een organisatie kan intern goede beveiligingsmaatregelen hebben die in dit type onderzoek niet zichtbaar zijn. Andersom betekent een ontbrekende header of zwakke e-mailpolicy ook niet automatisch dat een website direct kwetsbaar is. Het laat vooral zien waar de digitale basis nog aangescherpt kan worden.
Hoe is de score berekend?
Om de resultaten vergelijkbaar te maken, is per uniek domein een zichtbare basisscore berekend. Deze score loopt van 0 tot 60 punten en bestaat uit drie onderdelen:
- Security headers: maximaal 25 punten
- DNS- en e-mailbeveiliging: maximaal 25 punten
- Aanvullende technische aandachtspunten: maximaal 10 punten
De score is bedoeld als indicatie van publiek zichtbare basismaatregelen. Het is geen volledige veiligheidsscore en ook geen vervanging voor een pentest.
Security headers: maximaal 25 punten
Bij de security headers is gekeken naar maatregelen die via de HTTP-response zichtbaar zijn. Deze headers helpen onder andere bij het beperken van scriptinjectie, clickjacking, MIME-type misbruik, onnodige referrer-informatie en ongewenst gebruik van browserfunctionaliteiten.
| Controle | Punten |
|---|---|
| Content-Security-Policy aanwezig | 8 |
| Clickjacking-bescherming aanwezig, via X-Frame-Options of CSP frame-ancestors | 5 |
| X-Content-Type-Options aanwezig | 4 |
| Referrer-Policy aanwezig | 4 |
| Permissions-Policy aanwezig | 4 |
| Totaal | 25 |
Een hogere headerscore betekent dat er meer zichtbare browserbeveiligingsmaatregelen zijn ingericht. De score zegt niet automatisch iets over de kwaliteit van iedere header. Een Content-Security-Policy kan bijvoorbeeld aanwezig zijn, maar alsnog ruim of beperkt effectief zijn. In dit onderzoek is vooral gekeken naar de aanwezigheid van deze basismaatregelen.
HSTS is apart geanalyseerd en in de resultaten besproken, maar maakt in deze ranglijst geen onderdeel uit van de puntentelling voor security headers. Daarmee voorkomen we dat één maatregel dubbel wordt meegewogen binnen de bredere HTTPS/TLS-duiding.
DNS- en e-mailbeveiliging: maximaal 25 punten
Bij DNS- en e-mailbeveiliging is gekeken naar maatregelen die helpen bij domeinbescherming en het beperken van e-mailmisbruik.
| Controle | Punten |
|---|---|
| SPF aanwezig | 5 |
DMARC aanwezig met policy p=none | 5 |
DMARC aanwezig met policy p=quarantine | 10 |
DMARC aanwezig met policy p=reject | 15 |
| DNSSEC aanwezig | 5 |
| Maximale score | 25 |
DMARC telt zwaarder mee wanneer de policy daadwerkelijk afdwingend is. Een policy op p=none is nuttig voor monitoring, maar geeft ontvangende mailservers nog geen opdracht om verdachte e-mail te blokkeren of in quarantaine te plaatsen. Daarom leveren quarantine en reject meer punten op.
CAA, MTA-STS, TLS-RPT en wildcard DNS zijn ook bekeken, maar niet allemaal op dezelfde manier meegewogen in de hoofdranglijst. CAA werd bij geen van de onderzochte domeinen aangetroffen en is daarom vooral als sectorbreed aandachtspunt behandeld. MTA-STS en TLS-RPT zijn informatief meegenomen. Wildcard DNS is niet per definitie fout en is daarom beoordeeld als aanvullend aandachtspunt.
Aanvullende technische aandachtspunten: maximaal 10 punten
Naast headers en DNS/e-mail is gekeken naar handmatig gevalideerde technische aandachtspunten die tijdens de publieke analyse naar voren kwamen. Deze categorie begint met 10 punten. Bij bevestigde aandachtspunten wordt een beperkte aftrek toegepast.
| Bevinding | Aftrek |
|---|---|
| Bevestigde publieke verwijzing naar of bereikbaarheid van een niet-productieomgeving | -5 |
| Bevestigd TLS- of certificaatketenprobleem op het hoofddomein of www-domein | -5 |
| Bevestigde wildcard DNS-configuratie | -2 |
| Bevestigde club-eigen secret of API-key in publieke JavaScript-bestanden | -10 |
Niet iedere automatische toolmelding is meegewogen. Meldingen zijn alleen meegenomen wanneer ze handmatig zijn beoordeeld, herleidbaar waren naar een clubdomein en relevant waren voor de zichtbare digitale basis. False positives, third-party scripts en normale client-side configuraties zijn niet als bevinding meegeteld.
In de JavaScript-analyse zijn geen bevestigde club-eigen secrets aangetroffen.
Wat zegt de score wel?
De score laat zien hoeveel van de onderzochte, publiek zichtbare basismaatregelen tijdens de meting aanwezig waren en of er aanvullende zichtbare aandachtspunten zijn bevestigd. Een hogere score betekent dus dat een club in deze buitenkantmeting meer zichtbare basismaatregelen had ingericht en minder bevestigde aandachtspunten liet zien.
De score is vooral nuttig om verschillen in basisinrichting zichtbaar te maken. Clubs bovenaan de ranglijst hadden relatief veel meetbare maatregelen op orde. Clubs lager in de ranglijst hadden tijdens de meting minder zichtbare maatregelen of meerdere ontbrekende basisinstellingen.
Wat zegt de score niet?
De score zegt niet dat een club volledig veilig of onveilig is. Er is niet gekeken naar onderdelen van websites waarvoor een gebruikersaccount nodig is, autorisatie, ticketingprocessen, betaalstromen, klantgegevens, leverancierskoppelingen, logging, monitoring of interne securityprocessen.
Een hoge score betekent dus niet dat er geen kwetsbaarheden kunnen bestaan. Een lage score betekent ook niet automatisch dat een club direct kwetsbaar is. De score zegt alleen iets over de zichtbare digitale basismaatregelen die in dit onderzoek zijn meegenomen.
Daarom spreken we in dit onderzoek niet over “de veiligste clubs”, maar over clubs die in deze meting het beste scoorden op publiek zichtbare basismaatregelen.
Welke tools zijn gebruikt?
Voor de meting zijn meerdere hulpmiddelen gebruikt om de resultaten te verzamelen en te controleren. Nuclei is ingezet voor publieke webcontroles, zoals security headers, technologieherkenning en lichte misconfiguraties. BBOT is gebruikt als aanvullende controlelaag voor publieke technische signalen. Voor DNS- en e-mailbeveiliging is een aparte, uniforme controle uitgevoerd met DNS-query’s, zodat alle domeinen op dezelfde manier zijn beoordeeld.
Daarnaast zijn publieke JavaScript-bestanden geanalyseerd met tools zoals jsluice en SecretFinder. Deze analyse is gebruikt om opvallende endpoints, externe diensten en mogelijke key-achtige waarden te signaleren. Bevindingen uit deze tools zijn niet automatisch als kwetsbaarheid beschouwd. Iedere relevante hit is handmatig beoordeeld op context, herleidbaarheid en realistische impact.
Hoe zijn false positives behandeld?
Automatische securitytools leveren regelmatig meldingen op die bij handmatige controle niet kwetsbaar blijken te zijn. Daarom zijn opvallende resultaten handmatig gevalideerd voordat ze zijn meegenomen in de interpretatie.
Voorbeelden van meldingen die niet automatisch als kwetsbaarheid zijn beschouwd:
- API-endpoints die onderdeel zijn van normale websitefunctionaliteit;
- publieke reCAPTCHA site keys;
- Google Analytics- of Google Maps-keys in third-party scripts;
- SPF-verwijzingen naar e-maildiensten zoals SendGrid;
- algemene JavaScript-termen zoals
password,tokenofauthorizationzonder echte geheime waarde; - technologie- of frameworkinformatie zonder aantoonbare blootstelling;
- CNAME- of takeover-indicaties die na controle naar een normaal werkende website bleken te verwijzen.
Alleen bevindingen die herleidbaar waren naar een clubdomein en relevant waren voor de zichtbare beveiligingsbasis zijn meegenomen. Ruwe tool-output is dus niet één-op-één overgenomen als onderzoeksresultaat.
Responsible disclosure
Tijdens het onderzoek is één technische bevinding aangetroffen die vanwege de aard van de configuratie apart via responsible disclosure is gemeld aan de betreffende organisatie.
Om onnodige risico’s te voorkomen is deze bevinding niet inhoudelijk opgenomen in de publieke onderzoeksresultaten en niet meegenomen in de ranglijst of puntentelling.
Het doel van dit onderzoek is het zichtbaar maken van verschillen in publiek waarneembare basismaatregelen, niet het publiceren van mogelijk misbruikbare technische details. Wanneer tijdens onderzoek signalen worden aangetroffen die mogelijk aanvullende aandacht verdienen, kiest Securitytest.nl ervoor deze rechtstreeks bij de betreffende organisatie te melden.
Wat is niet onderzocht?
Dit onderzoek is bewust beperkt gehouden. Er is onder andere niet gekeken naar:
- pagina’s achter een login
- ticketing- en betaalprocessen waarvoor een account benodigd is;
- klantgegevens of persoonsgegevens;
- autorisatieproblemen binnen applicaties;
- business logic-kwetsbaarheden;
- kwetsbaarheden die actieve exploitatie vereisen;
- kwetsbaarheden in interne netwerken;
- social engineering;
- fysieke beveiliging;
- leverancierscontracten of interne securityprocessen;
- actieve inventarisatie van ontwikkel-, test- of beheeromgevingen.
Ook zijn er geen grootschalige subdomeinscans, portscans of agressieve vulnerability scans uitgevoerd. Het onderzoek is opgezet als een laagdrempelige en niet-intrusieve controle van wat vanaf de buitenkant zichtbaar is.
Beperkingen van het onderzoek
De resultaten zijn een momentopname. Websites, DNS-records, headers en configuraties kunnen op ieder moment worden aangepast. De uitkomsten zeggen daarom iets over de situatie tijdens de meetperiode, niet noodzakelijk over de huidige of toekomstige beveiligingsstatus van een club.
Daarnaast beoordeelt dit onderzoek alleen de zichtbare basismaatregelen. Een club met ontbrekende security headers is niet automatisch onveilig, en een club met veel zichtbare maatregelen is niet automatisch volledig beschermd. Voor een volledig oordeel over de beveiliging van een website is een diepgaandere pentest nodig, inclusief handmatige beoordeling van functionaliteit, autorisatie, dataverwerking en misbruikscenario’s.
Dit onderzoek laat vooral zien welke basismaatregelen vanaf de buitenkant zichtbaar zijn en waar clubs relatief eenvoudig verbeteringen kunnen doorvoeren.