Suppose a security researcher finds a vulnerability in your web application. Does that person know where to report it? For many Dutch organizations, the answer is no. The next question is whether and how the report will reach the security team. A security.txt file solves that problem. Below, you\u2019ll learn what it should contain, where it should be placed, and what often goes wrong in practice. <\/p>\n
Security.txt is a text file on your web server that specifies how someone can report a security issue to your organization. The format is defined in RFC 9116<\/a>, published in April 2022 by Edwin Foudil and Yakov Shafranovich. <\/p>\n The structure is similar to robots.txt: a fixed location on your domain, a fixed format, and a file that can be read by both humans and scripts. Each line consists of a field name, a colon, and a value. Lines that begin with a hash sign are comments. <\/p>\n Otherwise, the person reporting the issue will have to look elsewhere. Someone who discovers a vulnerability in your customer portal has four options: they can keep searching until they find the right person, send an email to the general email address, give up, or post their findings on social media. Only with the first option will you be the first to know. <\/p>\n Ethical hackers, security researchers, and technically savvy customers regularly report vulnerabilities to companies that aren\u2019t equipped to handle them at all. Here\u2019s what happens: the report comes in to info@, sits there for two weeks, and the reporter concludes that you apparently aren\u2019t interested. Out of frustration or concern about the vulnerability, the reporter may then decide to go public\u2014something you\u2019ll likely want to avoid. <\/p>\n There\u2019s also an internal benefit. By creating a security.txt file, you force yourself to determine in advance who will handle reports, within what timeframe a response will be provided, and who will decide on an emergency patch. You\u2019ll want to have that discussion before the first report comes in. <\/p>\n On If you work with multiple domains or standalone subdomains, each domain where someone might find a vulnerability needs its own file. Use the “Canonical” field to point to where the original should be located. <\/p>\n Two fields are required:<\/p>\n The rest is optional:<\/p>\n Note the address listed under \u201cContact.\u201d A shared mailbox like security@ will continue to function even if a colleague leaves, whereas a personal email address will quietly become inactive after a year. <\/p>\n Because outdated contact information is worse than no contact information at all. Anyone who sends an email to an address that no one checks anymore will assume the message was delivered. The “Expires” field shows when the file was last checked, and the RFC recommends setting the date to less than one year in the future. <\/p>\n Therefore, make sure to add the expiration date to the calendar of the person in charge of management, or have your hosting provider include the file in their annual maintenance. An expired security.txt file is a sign to researchers that the rest of the site is likely out of date as well. <\/p>\n The RFC recommends an OpenPGP signature, in combination with the Canonical field, so that a reporter can verify that the file truly comes from you and is in the correct location. This allows the reporter to verify that the file has not been tampered with. Keep in mind, nothing is more confusing than an incorrect signature. Therefore, start with a correctly filled-out file that includes a current address and a valid \u201cExpires\u201d date. <\/p>\n They go hand in hand and serve different purposes. A responsible disclosure page, also known as a Coordinated Vulnerability Disclosure (CVD), is a page on your website that outlines the ground rules: what you expect from a reporter and what they can expect from you. This page is written for people, is hosted at a URL of your choice, and can be as long as necessary. <\/p>\n Security.txt serves as the guide to that page. The file is located in a specified directory, is machine-readable, and contains little more than a contact address and a link to that page. A scanner, an investigation tool, or an AI assistant that determines where a report should be sent first checks That\u2019s the main weakness of a standalone disclosure page: it can only be found if someone stumbles upon it in your footer or knows how to Google it. If it\u2019s located in a logical spot, things usually go well, and the security.txt file is the icing on the cake. Do you already have a responsible disclosure page? Then you\u2019ll be done in five minutes. Enter the URL of that page in the \u201cPolicy\u201d field, the email address in the \u201cContact\u201d field, and place the file in the correct location. <\/p>\n The “Policy” field refers to your Coordinated Vulnerability Disclosure or Responsible Disclosure policy. It outlines what you expect from a reporter and what the reporter can expect from you. It should definitely include the following four components: <\/p>\n The NCSC has published guidelines<\/a> on this topic that you can use as a starting point.<\/p>\n No. RFC 9116 has the status “Informational,” which means it is a widely accepted convention and not a standard that you are required to comply with. <\/p>\n The Cybersecurity Act\u2014the Dutch implementation of NIS2, which has been in effect since August 15, 2026, for more than 8,000 organizations\u2014does not mention security.txt anywhere. What the law does require is that you manage risks and report incidents to the CSIRT within 24 hours. A reporting channel that demonstrably works is part of that first requirement, and security.txt is the most cost-effective way to make that channel discoverable. The question is also coming up more and more frequently in ISO 27001 audits and supplier questionnaires. <\/p>\n We keep finding the same errors on the websites we examine. A file with an “Expires” date that expired two years ago. A contact address for an administrator who now works elsewhere. A security.txt file located only in the webroot and not in There\u2019s an even more subtle one: a server that returns a clean HTML page with a 200 status code for every unknown URL. A scanner then reads a security.txt file that doesn\u2019t exist, and you think the issue is resolved. That\u2019s why you should always check the status code and the content type\u2014not just what your browser displays. <\/p>\n The file does not contain any information that would be useful to an attacker. You are publishing a contact address, not version numbers or internal system names. <\/p>\n What you do get is noise. There\u2019s a category of senders who circulate automated scan reports asking for a reward, even though there\u2019s no actual vulnerability behind them. Therefore, agree in advance on who will review these messages and how you\u2019ll distinguish between a legitimate report and a form letter. That\u2019s a small price to pay to ensure that a researcher who does find a real vulnerability can reach you immediately. <\/p>\n Start with the basics and retrieve the file the way a scanner would:<\/p>\n You want to see a 200 status code, a \u201c Security.txt ensures that you\u2019re notified when someone finds something. It says nothing about what can be found. These two things go hand in hand: an organization that takes reports seriously but never conducts its own testing is, in effect, waiting for an outsider to do the work. <\/p>\n Want to know what vulnerabilities are already present in your environment? During a penetration test<\/a>, our certified ethical hackers go beyond an automated scan: we manually search for what a scanner misses, and then explain to you in plain language where the vulnerabilities are. Schedule a consultation<\/a>, and we\u2019ll work with you to assess your current situation. <\/p>\nWhy should you include a security.txt file?<\/h2>\n
Where should the file be located?<\/h2>\n
https:\/\/jouwdomein.nl\/.well-known\/security.txt<\/code>. That is the only correct location according to RFC 9116. There are three requirements associated with it: <\/p>\n\n
text\/plain<\/code>, with UTF-8 character encoding.<\/li>\n\/security.txt<\/code>), then according to the RFC, the version at \/.well-known\/<\/code> takes precedence. You can use that old location as a redirect, so that anyone who still tries to access it will end up in the right place. <\/li>\n<\/ul>\nWhat fields are included in a security.txt file?<\/h2>\n
\n
mailto:<\/code>), a phone number (tel:<\/code>), or a web form (https:<\/code>). This field may appear multiple times; the order indicates your preference. <\/li>\n\n
What does a good security.txt file look like?<\/h2>\n
# Meldingen over de beveiliging van onze systemen zijn welkom.\nContact: mailto:security@jouwdomein.nl\nContact: tel:+31-88-1234567\nExpires: 2027-09-01T00:00:00.000Z\nEncryption: https:\/\/jouwdomein.nl\/pgp-key.txt\nPolicy: https:\/\/jouwdomein.nl\/responsible-disclosure\nAcknowledgments: https:\/\/jouwdomein.nl\/hall-of-fame\nPreferred-Languages: nl, en\nCanonical: https:\/\/jouwdomein.nl\/.well-known\/security.txt\n<\/code><\/pre>\nWhy does security.txt have an expiration date?<\/h2>\n
Do you need to sign your security.txt file with PGP?<\/h2>\n
What is the difference between security.txt and a responsible disclosure page?<\/h2>\n
\/.well-known\/security.txt<\/code>. <\/p>\nWhat do you include in the CVD policy you’re referring to?<\/h2>\n
\n
Is security.txt required?<\/h2>\n
What goes wrong in practice?<\/h2>\n
\/.well-known\/<\/code>. A Policy link pointing to a page that disappeared during the last website migration. <\/p>\nDoes a security.txt file increase your risk of being hacked?<\/h2>\n
How do you check if your security.txt file is correct?<\/h2>\n
curl -i https:\/\/jouwdomein.nl\/.well-known\/security.txt\n<\/code><\/pre>\nContent-Type<\/code> \u201d from text\/plain<\/code>, and an \u201cExpires\u201d date that\u2019s in the future. After that, the most important test is the human one: send a test message to the address listed under \u201cContact\u201d and see if someone responds within your own promised timeframe. A file that\u2019s technically correct but ends up in a mailbox that no one opens is still a dead end. <\/p>\nA doorbell is not a lock<\/h2>\n