Stel dat een beveiligingsonderzoeker een lek vindt in jouw webapplicatie. Weet die persoon dan waar hij het moet melden? Bij veel Nederlandse organisaties is het antwoord nee. Vervolgens is het de vraag of en hoe de melding bij het security-team terecht komt. Een security.txt lost dat op. Hieronder lees je wat erin hoort, waar het moet staan, en wat er in de praktijk misgaat.

Wat is security.txt?

Security.txt is een tekstbestand op je webserver waarin staat hoe iemand een beveiligingsprobleem bij jouw organisatie kan melden. Het formaat is vastgelegd in RFC 9116, gepubliceerd in april 2022 door Edwin Foudil en Yakov Shafranovich.

De opzet lijkt op robots.txt: een vaste plek op je domein, een vast formaat en een bestand dat zowel een mens als een script kan lezen. Elke regel bestaat uit een veldnaam, een dubbele punt en een waarde. Regels die met een hekje beginnen zijn commentaar.

Waarom zou je een security.txt plaatsen?

Omdat de melder anders moet gaan zoeken. Iemand die een kwetsbaarheid in jouw klantportaal ontdekt heeft vier opties: hij zoekt tot hij de juiste persoon vindt, hij stuurt een mail naar het algemene mailadres, hij geeft het op, of hij post zijn bevinding op social media. Alleen bij de eerste optie hoor jij het als eerste.

Ethische hackers, security-onderzoekers en klanten met technische kennis melden regelmatig kwetsbaarheden aan bedrijven die daar helemaal niet op zijn ingericht. Wat er dan gebeurt: het bericht komt binnen op info@, blijft twee weken liggen, en de melder trekt de conclusie dat het jou blijkbaar niet interesseert. De melder kan dan uit frustratie of bezorgdheid over het lek de publiciteit op gaan zoeken, iets wat je waarschijnlijk wilt voorkomen.

Er zit ook een intern voordeel aan. Door een security.txt te plaatsen dwing je jezelf om vooraf te bepalen wie meldingen oppakt, binnen welke termijn er antwoord gaat en wie er beslist over een noodpatch. Dat gesprek wil je gevoerd hebben voordat de eerste melding binnenkomt.

Waar moet het bestand staan?

Op https://jouwdomein.nl/.well-known/security.txt. Dat is de enige juiste locatie volgens RFC 9116. Drie voorwaarden horen daarbij:

• Het bestand moet via https bereikbaar zijn.
• Het moet worden uitgeserveerd als text/plain, met tekencodering utf-8.
• Staat er ook een bestand in de webroot (/security.txt), dan geldt volgens de RFC de versie in /.well-known/. Die oude locatie mag je gebruiken als redirect, zodat wie er toch begint alsnog op de goede plek uitkomt.

Werk je met meerdere domeinen of losstaande subdomeinen, dan heeft elk domein waar iemand een lek kan vinden zijn eigen bestand nodig. Verwijs met het veld Canonical naar de plek waar het origineel hoort te staan.

Welke velden staan er in een security.txt?

Twee velden zijn verplicht:

• Contact – waar je de melding naartoe stuurt. Een e-mailadres (mailto:), een telefoonnummer (tel:) of een webformulier (https:). Dit veld mag meerdere keren voorkomen; de volgorde geeft je voorkeur aan.
• Expires – de datum waarop de informatie in dit bestand als verouderd geldt. Dit veld mag precies een keer voorkomen.

De rest is optioneel:

• Encryption – een link naar je publieke sleutel, zodat een melder de details versleuteld kan sturen.
• Policy – een link naar je CVD-beleid of responsible disclosure-pagina.
• Acknowledgments – een pagina waarop je melders bedankt.
• Preferred-Languages – de talen waarin je een melding graag ontvangt. Mag maar een keer voorkomen.
• Canonical – de plek waar dit bestand thuishoort.
• Hiring – een link naar je securityvacatures.

Hoe ziet een goede security.txt eruit?

# Meldingen over de beveiliging van onze systemen zijn welkom.
Contact: mailto:security@jouwdomein.nl
Contact: tel:+31-88-1234567
Expires: 2027-09-01T00:00:00.000Z
Encryption: https://jouwdomein.nl/pgp-key.txt
Policy: https://jouwdomein.nl/responsible-disclosure
Acknowledgments: https://jouwdomein.nl/hall-of-fame
Preferred-Languages: nl, en
Canonical: https://jouwdomein.nl/.well-known/security.txt

Let op het adres achter Contact. Een gedeelde mailbox als security@ blijft werken als een collega vertrekt, waar een persoonlijk adres na een jaar stilletjes doodloopt.

Waarom heeft security.txt een vervaldatum?

Omdat verouderde contactgegevens erger zijn dan geen contactgegevens. Wie mailt naar een adres dat niemand meer leest, denkt dat de melding is aangekomen. Het veld Expires maakt zichtbaar wanneer het bestand voor het laatst is nagelopen, en de RFC beveelt aan de datum minder dan een jaar in de toekomst te zetten.

Zet de vervaldatum daarom in de agenda van degene die het beheer doet, of laat je hostingpartij het bestand jaarlijks meenemen in het onderhoud. Een verlopen security.txt is voor onderzoekers een teken dat de rest waarschijnlijk ook niet meer klopt.

Moet je security.txt ondertekenen met PGP?

De RFC beveelt een OpenPGP-handtekening aan, in combinatie met het veld Canonical, zodat een melder kan controleren dat het bestand echt van jou komt en op de juiste plek staat. Zo kan de melder controleren of er niet met het bestand gerommeld is. Let wel, niets is zo verwarrend als een incorrecte handtekening. Begin daarom met een correct ingevuld bestand met een actueel adres en een geldige Expires-datum.

Wat is het verschil tussen security.txt en een responsible disclosure-pagina?

Ze horen bij elkaar en doen verschillend werk. Een responsible disclosure-pagina, ook wel een Coordinated Vulnerability Disclosure of CVD genoemd, is een pagina op je website met de spelregels: wat je van een melder verwacht en wat hij van jou mag verwachten. Die pagina is geschreven voor mensen, staat op een URL die je zelf kiest en mag zo lang zijn als nodig.

Security.txt is de wegwijzer ernaartoe. Het bestand staat op een voorgeschreven locatie, is machine-leesbaar en bevat weinig meer dan een contactadres en een link naar die pagina. Een scanner, een onderzoekstool of een AI-assistent die uitzoekt waar een melding heen moet, kijkt als eerste naar /.well-known/security.txt.

Daar zit meteen de zwakke plek van een losse disclosure-pagina: die is alleen te vinden als iemand hem tegenkomt in je footer of weet te googelen. Staat die op een logische plek, dan gaat het vaak goed en is de security.txt de kers op de taart. Heb je al een responsible disclosure-pagina staan? Dan ben je in vijf minuten klaar. Zet de URL van die pagina achter het veld Policy, het mailadres achter Contact, en plaats het bestand op de juiste plek.

Wat zet je in het CVD-beleid waar je naar verwijst?

Het veld Policy wijst naar je beleid voor Coordinated Vulnerability Disclosure of Responsible Disclosure beleid. Daarin staat wat je van een melder verwacht en wat hij van jou mag verwachten. Vier onderdelen horen er zeker in:

• De reikwijdte: welke domeinen, applicaties en systemen vallen eronder, en welk soort onderzoek je uitdrukkelijk niet wilt (denial-of-service-aanvallen, social engineering van je medewerkers, het downloaden van klantgegevens).
• Wat jij toezegt: binnen hoeveel werkdagen je een ontvangstbevestiging stuurt, wanneer je inhoudelijk terugkoppelt en welke hersteltermijn je nastreeft.
• Of je naamsvermelding of een beloning geeft, en waar die vermelding komt te staan.
• De toezegging dat je geen juridische stappen onderneemt tegen melders die zich aan je spelregels houden. In Nederland lopen ethische hackers die zich aan de spelregels houden geen risico’s, maar toch is het goed om dit te vermelden.

Het NCSC heeft hiervoor een leidraad die je als basis kunt gebruiken.

Is security.txt verplicht?

Nee. RFC 9116 heeft de status Informational, wat betekent dat het een breed geaccepteerde afspraak is en geen norm waaraan je moet voldoen.

De Cyberbeveiligingswet, de Nederlandse invulling van NIS2 die sinds 15 augustus 2026 van kracht is voor ruim 8.000 organisaties, noemt security.txt nergens. Wat die wet wel vraagt is dat je risico’s beheerst en dat je incidenten binnen 24 uur meldt bij het CSIRT. Een meldkanaal dat aantoonbaar werkt hoort bij die eerste eis, en security.txt is de goedkoopste manier om dat kanaal vindbaar te maken. Ook bij ISO 27001-audits en in leveranciersvragenlijsten komt de vraag steeds vaker langs.

Wat gaat er in de praktijk mis?

Bij websites die we onderzoeken komen steeds dezelfde fouten terug. Een bestand met een Expires-datum die twee jaar geleden is verstreken. Een contactadres van een beheerder die inmiddels ergens anders werkt. Een security.txt die alleen in de webroot staat en niet in /.well-known/. Een Policy-link die naar een pagina wijst die bij de laatste websitemigratie is verdwenen.

Er is nog een subtielere: een server die op elke onbekende URL een nette HTML-pagina teruggeeft met statuscode 200. Een scanner leest dan een security.txt die er niet is, en jij denkt dat het geregeld is. Controleer daarom altijd de statuscode en het content-type, en niet alleen wat je browser laat zien.

Verhoogt een security.txt het risico dat je gehackt wordt?

Het bestand bevat geen informatie waar een aanvaller iets aan heeft. Je publiceert een contactadres, geen versienummers of interne systeemnamen.

Wat je wel krijgt is ruis. Er bestaat een categorie afzenders die geautomatiseerde scanrapporten rondstuurt met de vraag om een beloning, zonder dat er een echte kwetsbaarheid onder ligt. Spreek daarom vooraf af wie die berichten beoordeelt en hoe je onderscheid maakt tussen een serieuze melding en een standaardmail. Dat is een kleine prijs voor het feit dat de onderzoeker die wel iets echts vindt jou meteen weet te bereiken.

Hoe controleer je of je security.txt klopt?

Begin bij de basis en haal het bestand op zoals een scanner dat doet:

curl -i https://jouwdomein.nl/.well-known/security.txt

Je wilt statuscode 200 zien, een Content-Type van text/plain en een Expires-datum die in de toekomst ligt. Daarna is de belangrijkste test de menselijke: stuur een testmelding naar het adres achter Contact en kijk of er binnen je eigen toegezegde termijn iemand antwoordt. Een bestand dat technisch klopt maar uitkomt in een mailbox die niemand opent, is nog steeds een dood spoor.

Een deurbel is geen slot

Security.txt zorgt ervoor dat je hoort wanneer iemand iets vindt. Het zegt niets over wat er te vinden valt. Die twee dingen horen bij elkaar: een organisatie die meldingen serieus afhandelt maar nooit zelf laat testen, wacht in feite af tot een buitenstaander het werk doet.

Wil je weten wat er nu al op jouw omgeving te vinden is? Bij een pentest gaan onze gecertificeerde ethisch hackers verder dan een geautomatiseerde scan: we zoeken handmatig door wat een scanner overslaat, en je krijgt daarna in gewone taal te horen waar de zwakke plekken zitten. Plan een adviesgesprek en we kijken samen waar je staat.