Security.txt Generator

security.txt is een best practice voor webbeveiliging die formeel is gestandaardiseerd door de IETF (Internet Engineering Task Force) in RFC 9116, ontworpen om websites een uniforme, standaard manier te bieden om beveiligingscontactgegevens te publiceren. Simpel gezegd is het een tekstbestand dat op een vast pad op een website wordt geplaatst en beveiligingsonderzoekers (white hat hackers) vertelt: "Als u beveiligingskwetsbaarheden op mijn website vindt, is dit hoe u contact met ons kunt opnemen, dit is onze coderingssleutel, dit is ons onthullingsbeleid, wij verwelkomen uw rapporten."

Voordat de security.txt-standaard bestond, waren beveiligingscontactgegevens van websites wanordelijk. Sommige websites hadden helemaal geen beveiligingscontactgegevens, sommige begroeven het op een obscure pagina, sommige vermeldden alleen een onbeheerd info@-e-mailadres en sommige vereisten moeizaam zoeken op LinkedIn om het beveiligingsteam te vinden. Dit veroorzaakte een serieus probleem: wanneer goedgelovige beveiligingsonderzoekers kwetsbaarheden ontdekten, konden ze vaak niet het juiste kanaal vinden om ze te melden. Het resultaat was—veel kwetsbaarheden werden stil genegeerd, niet gerepareerd gelaten, totdat ze door kwaadwillende hackers werden ontdekt en uitgebuit. security.txt is geboren om dit "laatste mijl"-probleem op te lossen.

Het concept van security.txt werd voor het eerst voorgesteld door beveiligingsonderzoekers EdOverflow en Yakov Shafranovich in 2017 en kreeg al snel brede steun uit de industrie. In april 2022 werd security.txt formeel door de IETF goedgekeurd als RFC 9116, waardoor het een internationaal erkende webbeveiligingsstandaard werd. Tegenwoordig hebben grote technologiebedrijven zoals Google, GitHub, Meta (Facebook), LinkedIn en Cloudflare, evenals overheidsinstanties waaronder de Britse overheid, het Amerikaanse CISA (Cybersecurity and Infrastructure Security Agency), de Franse overheid, de Italiaanse overheid, de Nederlandse overheid en het Australian Cyber Security Centre, security.txt op hun officiële websites geïmplementeerd en bevelen ze andere organisaties publiekelijk aan om het te adopteren.

Het kernontwerp van het security.txt-bestand is heel eenvoudig—het is een gewoon tekstbestand dat bestaat uit regels in het formaat "veldnaam: waarde", vergelijkbaar met het HTTP-headerformaat. De standaard definieert twee verplichte velden: Contact (beveiligingscontactgegevens, die meerdere kunnen zijn) en Expires (bestandsvervaltijd); evenals verschillende optionele velden: Encryption (PGP-coderingssleutel-URL), Acknowledgments (dankpagina-URL), Policy (kwetsbaarheidsonthullingsbeleid-URL), Hiring (beveiligingsvacature-URL), Canonical (canonieke bestands-URL), Preferred-Languages (ondersteunde rapporttalen), CSAF (Common Security Advisory Framework-provider metadata-URL). Dit eenvoudige formaat maakt het gemakkelijk voor zowel mensen als machines om te parseren.

Waarom is het implementeren van security.txt zo belangrijk? Ten eerste verlaagt het de drempel voor kwetsbaarheidsrapportage. Beveiligingsonderzoekers hoeven geen aanzienlijke tijd te besteden aan het vinden van contactgegevens—ze kunnen het juiste rapportkanaal met één klik vinden. Ten tweede toont het de proactieve houding van een organisatie ten opzichte van beveiliging—een website met security.txt zegt in wezen "Wij nemen beveiliging serieus en verwelkomen verantwoorde rapporten." Ten derde vermindert het het risico dat kwetsbaarheden publiekelijk worden onthuld of uitgebuit: met een formeel kanaal zullen onderzoekers er niet voor kiezen kwetsbaarheden direct op Twitter of GitHub publiekelijk te onthullen omdat ze niemand kunnen bereiken. Ten vierde is het in veel industriële regelgevingseisen (financiën, gezondheidszorg, overheid) een nalevingsvereiste geworden om een kwetsbaarheidsonthullingskanaal op te zetten.

Er zijn verschillende belangrijke details om op te merken bij het implementeren van security.txt. Ten eerste moet het pad correct zijn: het standaardpad is /.well-known/security.txt en u kunt ook een kopie op /security.txt in de hoofdmap plaatsen als fallback. De .well-known-map hier is een standaard "bekende bronnen"-map gedefinieerd door RFC 8615, waar andere standaardbestanden zoals robots.txt ook op gerelateerde locaties worden geplaatst. Ten tweede moet het via HTTPS worden aangeboden—platte-tekst-HTTP wordt als onveilig beschouwd. Ten derde moet Content-Type text/plain zijn, niet text/html of andere typen. Ten vierde, voer geen cross-domeinomleidingen uit voor security.txt—als https://example.com/.well-known/security.txt doorverwijst naar https://other-domain.com/security.txt, beschouwen onderzoekers en geautomatiseerde tools dit als verdacht. Ten vijfde, vergeet niet het Expires-veld in te stellen en het regelmatig bij te werken; een verlopen security.txt wordt beschouwd als met onbetrouwbare informatie.

Het Contact-veld is het belangrijkste veld in security.txt en het enige echt essentiële veld (Expires is ook verplicht maar is slechts een tijdstempel). Contact ondersteunt drie URI-formaten: mailto: voor e-mailadressen, https: voor weblinks (zoals beveiligingsrapportformulierpagina's), tel: voor telefoonnummers. Het wordt ten zeerste aanbevolen om ten minste één mailto-e-mail en één https-formulierlink te verstrekken—formulieren voorkomen botspam, terwijl e-mail handiger is voor onderzoekers om direct gecodeerde rapporten te verzenden. Meerdere contacten kunnen op meerdere regels worden vermeld, bijvoorbeeld door tegelijkertijd zowel het beveiligingsteam-e-mailadres, het e-mailadres van de beveiligingsverantwoordelijke en links naar platforms voor kwetsbaarheden van derden te verstrekken.

Hoewel het Encryption-veld optioneel is, is het in de praktijk erg belangrijk. Wanneer beveiligingsonderzoekers een kritieke kwetsbaarheid ontdekken (zoals gebruikersgegevenslek of uitvoering van externe code), willen ze absoluut geen kwetsbaarheidsdetails in platte-tekst-e-mail verzenden—omdat e-mail tijdens verzending via meerdere servers gaat, kan elke hop worden afgeluisterd. PGP (Pretty Good Privacy) publieke sleutelcodering is de industriestandaard voor veilige communicatie. U hoeft alleen een PGP-sleutelpaar te genereren, de publieke sleutel op uw website te plaatsen (bijv. op /.well-known/pgp-key.txt) en die URL in het Encryption-veld in te voeren. Onderzoekers coderen de rapportinhoud met uw publieke sleutel en alleen degenen die de bijbehorende privésleutel bezitten, kunnen deze decoderen en lezen.

Het Policy-veld linkt naar uw Kwetsbaarheidsonthullingsbeleid (Vulnerability Disclosure Policy, VDP)-pagina, wat de sleutel is tot het opbouwen van vertrouwen bij onderzoekers. Een goede VDP moet duidelijk aangeven: testbereik (welke systemen binnen de testscope vallen en welke niet), toegestane testmethoden (bijv. SQL-injectie/XSS-testen toegestaan maar DDoS/sociale engineering/toegang tot echte gebruikersgegevens verboden), toegezegde responstijden (bijv. "Wij bevestigen de ontvangst van rapporten binnen 3 werkdagen"), of u beloningen aanbiedt en wettelijke safe harbor-toezeggingen (duidelijk aangeven dat u goedgelovige onderzoekers die de regels volgen niet zult vervolgen). Er zijn internationaal veel VDP-sjablonen beschikbaar ter referentie en het Amerikaanse CISA biedt ook een open source VDP-sjabloon aan.

Naast beveiligingscontact zelf heeft security.txt verschillende "verrassings"-velden. Het Acknowledgments-veld bouwt een Security Hall of Fame op—publiekelijk onderzoekers bedanken die u helpen kwetsbaarheden te vinden, hun werk erkennen en ook dienen als gemeenschapsopbouw. Het Hiring-veld is een heel slim ontwerp: mensen die kwetsbaarheden op uw website kunnen vinden, zijn inherent uitstekend beveiligingstalent en het plaatsen van een wervingslink in security.txt is het meest precieze kanaal om beveiligingstalent te werven. Veel bedrijven hebben uitstekende beveiligingsengineers aangenomen via security.txt. Het Canonical-veld is een beveiligingsoverweging—het voorkomt dat aanvallers uw security.txt op andere domeinen vervalsen.

Wat betreft de veelvoorkomende zorg over spam: in de praktijk melden de meeste organisaties die security.txt hebben geïmplementeerd geen significante toename van spam. Dit komt omdat: ten eerste, spammers doorgaans geen e-mailadressen verkrijgen door security.txt te crawlen; ten tweede, https:-formulierlinks kunnen worden gebruikt in plaats van direct mailto-e-mails te plaatsen en het toevoegen van CAPTCHA aan formulieren bots volledig kan blokkeren; ten derde, speciale beveiligings-e-mails (bijv. security@) meestal met strikte spamfilters zijn geconfigureerd. Daarentegen wegen de kosten van het missen van kritieke kwetsbaarheidsrapporten als gevolg van een gebrek aan een beveiligingscontactkanaal veel zwaarder dan de mogelijke toename van kleine hoeveelheden spam.

Deze generator is gebouwd in strikte overeenstemming met de RFC 9116-standaard en alle uitvoerformaten zijn genormaliseerd: het Contact-veld herkent automatisch voorvoegsels, het Expires-veld gebruikt het standaard ISO 8601 UTC-tijdformaat en Preferred-Languages wordt automatisch ingesteld op basis van de taal die u gebruikt. De gegenereerde inhoud kan direct worden gekopieerd en geïmplementeerd naar het /.well-known/security.txt-pad zonder enige wijziging. Bovendien wordt alle configuratie lokaal in uw browser uitgevoerd en nooit naar een server verzonden—uw beveiligingscontactgegevens blijven altijd op uw apparaat. Het implementeren van security.txt kost slechts 5 minuten, maar het beveiligingscommunicatiekanaal dat het opzet, kan u helpen een ernstig beveiligingsincident in de toekomst te voorkomen.