Serhii LypiiIn mijn ervaring hebben negen op de tien mkb-websites geen security.txt. Zonde, want het is één tekstbestand van vijf regels en het scheelt security-onderzoekers uren zoeken. Een security.txt RFC 9116 website is één plat tekstbestand met één taak: een onderzoeker die een lek vindt, weet binnen 30 seconden waar hij moet melden. Zonder security.txt: LinkedIn-zoektocht, contactformulier, geen reactie. Met: één e-mailadres, klaar. Kosten: 10 minuten. Winst: je oogt in tien minuten een stuk professioneler, en (voor bedrijven onder NIS2) laat je zien dat je een ontvangstkanaal voor security-issues hebt ingericht.
Dit artikel legt uit wat de RFC vereist, waar het bestand hoort te staan, welke velden verplicht zijn, en geeft een template die je vandaag kunt kopiëren.
Wat is security.txt en waar komt het vandaan
security.txt (RFC 9116) op je website is een IETF-standaard uit april 2022, gepubliceerd op de IETF datatracker door Ed Foudil en Yakov Shafranovich. Analoog aan robots.txt: standaard-locatie, plain-text, machine-leesbaar. Het doel is responsible disclosure faciliteren, dus een security-onderzoeker die iets vindt de kortste route geven om jou te bereiken zonder dat hij een sales-formulier moet invullen.
Adoptie stijgt gestaag. Facebook, Google, GitHub, veel EU-overheden en het NCSC-NL hebben er één. DigiD ook. Voor mkb is het nog uitzondering, wat betekent dat je er nu snel goedkoop mee vooroploopt.
security.txt RFC 9116 op je website plaatsen
Twee locaties zijn correct, één is primair.
/.well-known/security.txt is de standaard
De primaire locatie is https://jouwdomein.nl/.well-known/security.txt. De fallback is https://jouwdomein.nl/security.txt in de root. Beide over HTTPS, met Content-Type: text/plain; charset=utf-8.
Waarom .well-known? Dat is de IETF-standaard voor “well-known URIs” (RFC 8615). Voorspelbare plek waar tooling naar zoekt. De root-fallback bestaat voor legacy-scanners die de RFC-locatie niet kennen; RFC 9116 accepteert beide, maar noemt .well-known als primair.
Op WordPress werkt dit standaard door .well-known als map aan te maken en het bestand daar te plaatsen, mits je webserver hidden files niet blokkeert. Nginx-configs blokkeren soms alle .-paths behalve .well-known; check dus je server-config. Op Shopify moet je het via een redirect regelen omdat Shopify geen directe file-toegang biedt; op Laravel-projecten plaats je het in /public/.well-known/.
Verplichte velden: Contact en Expires
RFC 9116 maakt precies twee velden verplicht: Contact en Expires. Alle andere zijn aanbevolen of optioneel.
Contact. Een e-mail (mailto:security@jouwdomein.nl), een URL naar een bug-bounty-platform of meldformulier (https://jouwdomein.nl/responsible-disclosure/), of een telefoonnummer (tel:+31...). Meerdere Contact-regels zijn toegestaan en zelfs aan te bevelen: mail plus formulier bijvoorbeeld.
Expires. ISO 8601 datum-tijd met timezone. Aanbeveling in de RFC: maximaal 1 jaar vooruit. Verlopen security.txt is ongeldig; onderzoekers en tooling behandelen het bestand als niet-bestaand. Zet een agenda-reminder 30 dagen vóór Expires, of automatiseer (zie sectie Onderhoud).
Aanbevolen velden: Encryption, Canonical, Policy, Preferred-Languages
Naast de twee verplichte velden zijn er zes aanbevolen. Voor mkb zijn er vier relevant, twee zijn overkill.
- Encryption: URL naar je PGP-publieke sleutel of key-server. Voor mkb vaak overslaan, tenzij je écht PGP-mail wilt ontvangen. In de praktijk stuurt 95% van de melders een gewone mail.
- Canonical: URL waar dit bestand hoort te staan. Voorkomt dat een gekopieerd bestand op een verkeerd domein wordt vertrouwd (bijvoorbeeld op een staging-omgeving). Aanrader.
- Policy: URL naar je responsible-disclosure-pagina. Aanrader: één simpele pagina met “wat mag / wat niet / hoe reageren we / binnen welke termijn”.
- Preferred-Languages:
nl, envoor NL-mkb typisch. Voor internationale sites:en, nl. - Acknowledgments: URL naar een wall-of-fame met eerdere melders. Leuk als je er hebt, niet verplicht.
- Hiring: URL naar security-vacatures. Voor mkb niet relevant.
Template die je vandaag kunt kopiëren
Onderstaand een complete voorbeeld-security.txt die je vandaag kunt aanpassen en plaatsen.
Contact: mailto:security@jouwdomein.nl
Contact: https://jouwdomein.nl/responsible-disclosure/
Expires: 2027-01-01T00:00:00+01:00
Preferred-Languages: nl, en
Canonical: https://jouwdomein.nl/.well-known/security.txt
Policy: https://jouwdomein.nl/responsible-disclosure/Uitleg per regel:
- Regel 1: monitored
security@mailbox. Zet aliassen door naar de persoon die security-mail leest. - Regel 2: een meldformulier of disclosure-pagina als alternatief kanaal.
- Regel 3: geldigheid tot 1 januari 2027. Update jaarlijks (of automatiseer).
- Regel 4: talen waarin je meldingen accepteert. Onderzoekers weten dan of ze in NL of EN mogen schrijven.
- Regel 5: canonical-URL, zodat kopieën op verkeerd domein niet verward worden met het echte.
- Regel 6: link naar de responsible-disclosure-pagina.
PGP-signed versie. Voor extra betrouwbaarheid kun je een PGP-signed variant plaatsen als security.txt.sig ernaast. Voor mkb overkill, tenzij je overheids- of financiële klanten hebt. Voor de generator die dit voor je maakt: de officiële generator op securitytxt.org.
RFC 9116 generator
Maak jouw security.txt
Vul je meldpunt en vervaldatum in. Je krijgt direct een bestand dat je op de vaste well-known locatie kunt plaatsen.
Zet je favoriete contactmethode bovenaan. Gebruik een volledige URI, zoals mailto:, tel: of https://.
De generator stelt bij de eerste keer openen ongeveer negen maanden voor.
Aanbevolen velden toevoegen
Link naar je sleutel. Plak de sleutel zelf niet in dit veld.
Contact en Expires zijn verplicht volgens RFC 9116.
Alleen ingevulde en geldige regels komen in het bestand.
Vul minimaal Contact en Expires in.Plaats het bestand op https://jouwdomein.nl/.well-known/security.txt. Publiceer het via HTTPS als gewone UTF-8 tekst. Ondertekenen met OpenPGP is aanbevolen. Zet ook een kalenderherinnering voor de Expires-datum.
Controleer het resultaat. Dit is een startpunt, geen juridische disclosure-policy.
security.txt en NIS2: signaal voor mkb
NIS2 (in NL de Cyberbeveiligingswet) verplicht essential- en important-entities om cyberincidenten te melden binnen strakke termijnen (24 uur early warning, 72 uur notification, 30 dagen final report). Voor mkb dat onder NIS2 valt is security.txt geen directe wettelijke eis; NIS2 vraagt niet expliciet om een security.txt. Een security.txt RFC 9116 website is dan een goedkoop, zichtbaar signaal dat je beveiliging serieus neemt.
Wel is het een sterk signaal richting toezichthouder, verzekeraar en klant dat je een ontvangstkanaal voor security-issues hebt ingericht. Meerdere sectorale gedragscodes (onder andere van Cyberveilig Nederland) noemen security.txt expliciet als volwassenheidsindicator. In pentestrapporten wordt het ontbreken standaard aangestipt als “aandachtspunt”. Kort gezegd: geen wettelijke stok, wel een volwassenheidsmeter.
Voor mkb dat NIS2-scope raakt: combineer security.txt met een incident response plan onder NIS2. Het één zonder het ander is een halve maatregel. security.txt is het kleinste onderdeel van je totale respons-inrichting, en tegelijk het snelst gerealiseerd.
Onderhoud: Expires-datum en workflow
De grootste faalmodus van een security.txt (RFC 9116) op je website: de Expires-datum vervalt vergeten. Twee praktische oplossingen.
Optie 1: agenda-reminder. Zet in je jaaragenda een reminder 30 dagen vóór de Expires-datum. Wanneer die trigger, werk je Expires met een jaar bij en commit je de wijziging. Simpel, werkt voor kleine sites.
Optie 2: automatiseren. Een cron-job die maandelijks controleert of Expires binnen 45 dagen valt en indien nodig een pull-request opent (voor teams met git-workflow) of een Slack-bericht stuurt. Voor sites met een DevOps-pipeline is dit 20 minuten werk.
Documenteer daarnaast wie eigenaar is van de security@-mailbox. Als de webmaster vertrekt en de mailbox daarmee mee, is je security.txt de facto dood zonder dat het bestand het weet. In mijn ervaring gebeurt dit vaker dan een verlopen Expires.
Wanneer schakel je Lypii in
security.txt opzetten plus een responsible-disclosure-pagina plus (optioneel) een basic PGP-key: 1 tot 2 uur. Aan €70 per uur voor kantooruren komt dat op €70 tot €140, inclusief oplever-docs met de Expires-verwerking.
Als onderdeel van bredere WordPress security audit checklist of van een security-hygiene-pakket: goedkoper per uur. Ik werk niet ’s nachts, wel binnen de week.
Verbeteren boven herbouwen: je site hoeft niet aangeraakt te worden. Eén bestand toevoegen, één pagina bouwen, klaar.
Multi-stack opmerking: security.txt werkt op elke website, ongeacht CMS of stack. Het is een statisch bestand op een vaste URL; WordPress, Shopify, Laravel, statische sites en custom PHP hebben alle drie dezelfde plaats voor het bestand. Alleen de manier waarop je het uploadt of serveert verschilt per platform.
