All guides · Security

security.txt: Tell Researchers How to Reach You

security.txt is a small text file at a fixed address on your site, /.well-known/security.txt, that tells security researchers how to report a vulnerability to you. It is defined in RFC 9116.

Why it matters

People who find a security problem on a website often cannot work out whom to tell. A general contact form goes to support, emails to guessed addresses bounce, and social media is public. Some give up; others publish the problem without warning you. A security.txt file gives them a known place to look and a direct channel, so reports reach someone who can act on them.

It is a single static file and takes a few minutes to set up.

What we check

We request https://your-host/.well-known/security.txt once, following at most two redirects.

A missing file, a non-200 response, a file without Contact:, or a missing or past Expires: date is reported as “needs attention”. A common cause of the “not an HTML page” case is a site that answers every unknown path with its normal home page or a styled 404 page that still returns 200.

How to fix

Create a plain-text file with at least these two fields:

Contact: mailto:security@example.com
Expires: 2027-10-01T00:00:00.000Z

• Contact (required, can appear more than once): a mailto: address, an https:// link to a reporting form, or a tel: number. List them in order of preference. Use an address that is monitored and does not depend on a single person.
• Expires (required, exactly once): the date after which the file should be treated as stale, in ISO 8601 format. The RFC recommends a date less than a year ahead. Put a reminder in your calendar to update it before it passes.

Useful optional fields:

Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy
Acknowledgments: https://example.com/security-thanks
Encryption: https://example.com/pgp-key.txt

• Canonical states the official URL of the file, which helps if it is copied or mirrored.
• Policy links to your disclosure policy: what researchers may test, how you respond, and whether you offer rewards.
• Encryption links to a key researchers can use to send you sensitive details.

Where and how to serve it

• Place it at /.well-known/security.txt on every hostname you want to cover, including www.example.com and example.com if both serve content.
• Serve it over HTTPS with Content-Type: text/plain; charset=utf-8.
• Return a real 200 response for the file and a real 404 for paths that do not exist.

Nginx: serve it from a file on disk:

location = /.well-known/security.txt {
    alias /var/www/security.txt;
    default_type text/plain;
    charset utf-8;
}

Apache: place the file at .well-known/security.txt in your document root. Static file serving handles the rest; make sure no rewrite rule sends the path to your application.

Frameworks and static site generators: put the file in the folder that is copied to the site root as-is, often named public/ or static/, inside a .well-known subfolder. Some build tools skip folders whose names start with a dot, so check that the file is actually deployed.

The RFC also allows an older location, /security.txt at the site root, but /.well-known/security.txt is the one clients look for first.

Optional: sign it

You can sign the file with an OpenPGP cleartext signature so readers can verify it came from you. If you do, keep the signing key safe and re-sign the file every time you change it, including when you update Expires.

Be ready to respond

Publishing the file sets an expectation. Make sure someone reads the mailbox, acknowledges reports promptly, and knows how to escalate. A short public policy, linked from the Policy field, sets expectations on both sides.

The securitytxt.org site has a form that generates a valid file.

Last updated October 24, 2026