Wat security.txt eigenlijk is
security.txt is een platte tekstbestand, gedefinieerd in RFC 9116, dat iedereen die een beveiligingslek op je site vindt precies vertelt hoe ze het moeten melden. Het bevindt zich op een voorspelbare locatie — /.well-known/security.txt — zodat beveiligingsonderzoekers en geautomatiseerde scanners niet door je contactpagina hoeven te graven of een e-mailadres moeten raden.
Een minimaal voorbeeld ziet er zo uit:
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: nl
Dat is het complete formaat: een kleine set platte-tekstvelden, elk op zijn eigen regel. Geen JSON, geen XML, niets ingewikkelds.
Waarom dit meer is dan "leuk om te hebben"
Zonder een security.txt-bestand heeft een onderzoeker die een kwetsbaarheid op je WordPress-site vindt beperkte opties: door je contactformulier graven, een e-mailadres raden, of — als hij niets redelijks vindt — de kwetsbaarheid publiekelijk posten zonder je eerst de kans te geven het te repareren. Geen van die uitkomsten is goed voor jou.
Er is ook een regelgevend aspect. De EU Cyber Resilience Act, die geldt voor producten met digitale elementen die in de EU worden verkocht, vereist dat fabrikanten een gedocumenteerd proces hebben voor het afhandelen en melden van kwetsbaarheden. security.txt is niet de hele nalevingsvereiste, maar het is de standaard, verwachte manier om dat proces publiekelijk vindbaar te maken. Als je WordPress-site EU-gebruikers bedient of digitale producten verkoopt, is er een hebben een kleine, weinig moeite kostende stap richting die bredere verwachting.
Welke velden daadwerkelijk in het bestand horen
De RFC definieert verschillende velden, niet allemaal verplicht. Dit is wat elk doet:
Contact (verplicht, minstens één): Hoe je te bereiken bent. Kan een e-mail zijn (mailto:), een URL naar een meldformulier, of beide. Je kunt meerdere Contact-regels opnemen als je meer dan één meldkanaal hebt.
Expires (verplicht): Een ISO 8601-tijdstempel. Dit dwingt je om het bestand periodiek te herzien en opnieuw te bevestigen — een security.txt die jaren verouderd is met achterhaalde contactgegevens is arguably erger dan er geen hebben. Stel het in op iets realistisch, zoals een jaar verder, en werk het bij wanneer het verloopt.
Encryption (optioneel): Een link naar een PGP-sleutel als je wilt dat onderzoekers rapporten met gevoelige details versleutelen voordat ze ze versturen.
Acknowledgments (optioneel): Een link naar een pagina die onderzoekers erkent die problemen verantwoord hebben gemeld — een kleine stimulans waar sommige onderzoekers specifiek naar zoeken voordat ze besluiten te melden in plaats van publiekelijk te onthullen.
Preferred-Languages (optioneel): In welke talen je rapporten kunt lezen.
Canonical (optioneel): De gezaghebbende URL van het bestand zelf, nuttig als je site via meerdere domeinen bereikbaar is.
Policy (optioneel): Een link naar je volledige beleid voor het melden van kwetsbaarheden — het gedetailleerde document dat de scope, verwachte reactietijden, en wat onderzoekers van je kunnen verwachten beschrijft.
security.txt toevoegen aan WordPress
Omdat de structuur "Instellingen → Permalinks" van WordPress de meeste URL's via PHP afhandelt, heb je een van twee benaderingen nodig om een statisch bestand op /.well-known/security.txt te laten staan:
Optie A — Upload het bestand direct via FTP/bestandsbeheer. Maak een bestand met de naam security.txt met de bovenstaande inhoud, en upload het naar de .well-known-map in de webroot van je site (maak de map aan als die niet bestaat). Dit werkt op vrijwel elke host en is helemaal niet afhankelijk van WordPress, wat eigenlijk een voordeel is — het blijft werken, ook als je van thema of plugins wisselt.
Optie B — Gebruik een plugin die het voor je beheert. Een statisch bestand handmatig onderhouden betekent dat je moet onthouden om het Expires-veld jaarlijks bij te werken en de contactgegevens gesynchroniseerd te houden als ze veranderen. Erdo CRA Compliance genereert en serveert een security.txt-bestand als onderdeel van zijn bredere EU-compliancescan, naast de andere documentatie (beleid voor het melden van kwetsbaarheden, SBOM) die de Cyber Resilience Act verwacht — zodat het op één plek wordt onderhouden in plaats van als een vergeten statisch bestand van drie jaar geleden.
Veelgemaakte fouten
Een paar dingen die het waard zijn om te controleren zodra je het bestand hebt toegevoegd:
- Vergeten Expires bij te werken. Een verlopen security.txt signaleert meer verwaarlozing dan een ontbrekende. Stel een herinnering in, of gebruik een tool die dit voor je beheert.
- Een contactadres gebruiken dat niemand bijhoudt. Als security@jouwdomein.nl in een inbox terechtkomt die niemand controleert, heb je het vindbaarheidsprobleem opgelost en een nieuwe dode hoek gecreëerd.
- Het alleen in de domeinroot plaatsen. /.well-known/security.txt is de huidige standaardlocatie. Een /security.txt op rootniveau is toegestaan als fallback voor oudere crawlers, maar vertrouw er niet alleen op.
- Het behandelen als het hele compliance-verhaal. security.txt maakt je meldkanaal vindbaar; het vervangt niet het hebben van een daadwerkelijk triageproces wanneer er een melding binnenkomt.
Kortom
security.txt is een vijf-minuten-fix met een buitenproportioneel voordeel: het verandert "ik heb een bug op je site gevonden, en nu?" van een dood spoor in een gedocumenteerd proces. Of je het nu handmatig toevoegt als statisch bestand of een compliance-tool het laat onderhouden naast je andere EU-documentatie, het is een van de minst inspannende, meest impactvolle beveiligingspraktijken die een WordPress-site kan toepassen.