Security guide
security.txt, explained
Someone has found a flaw in your website and wants to tell you. This one plain-text file is how they find out where to write, and it takes ten minutes to publish.
01 Why it matters
The report you never received
A researcher who finds a vulnerability in your site has a short window of goodwill. They look for somewhere to send it, find a contact form that promises a reply within five working days, a support address staffed by people who will not understand the message, or nothing at all. What happens next is rarely malice: they give up, they post it publicly to get attention, or they sell it. All three are worse for you than an email.
security.txt is the agreed answer, standardised as RFC 9116. It is a text file at a known location saying who to contact and what to expect. It costs nothing, it is machine-readable so scanners and researchers find it automatically, and its presence signals that a report will reach someone who wants it.
02 The fields
Two required fields, four worth adding
Only Contact and Expires are mandatory. The rest reduce the number of round trips between a finder and your team, which is the whole point of the file.
Contact
What it does. Names where to send a report. A mailto: address, a phone number or an https: URL of a reporting form, and the field may appear more than once in order of preference.
Why it matters. This is the one field the file exists for. Use an address that reaches a person rather than a ticket queue that closes unrecognised mail, and prefer a role address over a named individual so it survives them leaving.
Contact: mailto:security@example.com Expires
What it does. A timestamp after which the file should no longer be trusted. Required since RFC 9116, and given in the ISO 8601 format.
Why it matters. It is what stops an abandoned file pointing at an address nobody reads any more. Set it under a year out and put the renewal in the same calendar you use for certificate renewals, because an expired security.txt is treated as no file at all.
Expires: 2027-01-31T23:59:00.000Z Encryption
What it does. Points at a public key a reporter can use to encrypt their message, as a URL rather than the key itself.
Why it matters. A vulnerability report is the one email you would least like intercepted. Offering a key is optional, but a finder who wants one and cannot find one may simply not send the details.
Encryption: https://example.com/pgp-key.txt Policy
What it does. Links to your vulnerability disclosure policy: what is in scope, how long you take to respond and what you ask a finder to do before going public.
Why it matters. It sets expectations on both sides. A researcher who knows you will respond within a week is far more likely to wait than one who has heard nothing and is guessing.
Policy: https://example.com/security-policy Preferred-Languages
What it does. Lists the languages your security team reads, as a comma-separated set of language tags.
Why it matters. Small but practical in the DACH region: a finder who writes German to a team that reads only English, or the other way round, adds a translation round trip to something that is often time-critical.
Preferred-Languages: de, en Canonical
What it does. States the URL the file is meant to be served from.
Why it matters. It lets a reader confirm the file they found belongs where they found it, which matters if your content is mirrored or served across several hostnames.
Canonical: https://example.com/.well-known/security.txt03 Rolling it out
One file, one location
The file belongs at /.well-known/security.txt and must be served over HTTPS with the content type text/plain. A copy at the root path is allowed for older clients but the well-known location is the one that counts. Nothing in it is secret, so it needs no protection beyond being served correctly.
Contact: mailto:security@example.com Expires: 2027-01-31T23:59:00.000Z Preferred-Languages: de, en Canonical: https://example.com/.well-known/security.txt Policy: https://example.com/security-policyTwo things go wrong in practice. A web server that serves the file as text/html makes it fail automated checks, and a framework that routes every unknown path into a 404 page will swallow it: request the URL yourself once and look at the status code and the content type, not just at the text in the browser.
04 Questions
What people ask about security.txt
Does publishing a contact address invite attacks?
It does not change who probes your site. Automated scanning is indiscriminate and already happening. What the file changes is what a person does with what they find, and the alternative to a report reaching you is not silence, it is the finding going somewhere else.
We are a small business without a security team. Is this for us?
Especially for you. The file does not promise a team, it promises an address. Point it at whoever actually reads mail and can reach your developer or agency, and say in the policy that you are small and will respond within a stated time.
Do we need a bug bounty to publish one?
No, and the two are unrelated. security.txt says where to send a report; a bounty says what you pay for it. Most published files offer no reward at all, and saying so plainly in your policy is better than leaving it open.
What happens when the Expires date passes?
Checkers treat the file as invalid, so you get the same result as never having published it. Renewing is a one-line edit, but it has to actually happen, which is why it belongs on the same maintenance list as your certificates and your domain renewals.
05 In depth
Related security topics
A contact address is what happens after something goes wrong. These guides are about the part before that.
HTTP security headers
What each response header does, which ones your site should send and how to configure them correctly.
Content Security Policy
The strongest defence against cross-site scripting: which directives to set, how to roll a policy out in report-only mode and how to reach an enforcing policy without breaking your site.
HSTS
Strict-Transport-Security explained: what max-age, includeSubDomains and preload actually do, and why the preload list is a decision you cannot quickly undo.
Cookie security
Secure, HttpOnly and SameSite: the cookie attributes that keep a session out of reach of scripts and cross-site requests, with the settings for a typical stack.
Clickjacking and X-Frame-Options
How an invisible overlay turns a visitor click into an action on your site, and the two headers that stop it: X-Frame-Options for older clients, frame-ancestors for everything else.
Referrer-Policy
Which part of your URLs travels to other sites when a visitor clicks away: the five policy values that matter, what each one gives up and the one to set by default.
Permissions-Policy
Switch off camera, microphone, geolocation and payment for your site and everything it embeds: the allow-list syntax, and why a feature you did not name is not a feature you turned off.
SPF, DMARC and DNSSEC
The records that stop someone sending mail in your name, and the one that keeps your DNS answers honest: what each does and the order to introduce them in.
Monitoring security headers
A header that is right today can be gone after the next deploy. Three ways to notice: a cron job with curl, a check in your CI pipeline and a scheduled scan, with what each of them catches and misses.
Detecting CSP changes
How a policy changes quietly through deploys, plugins and CDN rules, and how to catch it: a header diff, violation reports through report-to, and what a scan comparison can and cannot show.
Keep reading
More guides
Every guide stands on its own, and together they cover what our scanner looks at. Pick the one closest to your next question.
See whether your site publishes a security.txt
Our free Quickscan looks for the file at the standard location alongside your security headers, and explains every finding in plain language.