External Network Penetration Testing
Testing of everything you expose to the internet, from forgotten admin panels to VPN gateways, with every finding manually validated.
Free tool
security.txt Generator
Fill in how researchers should reach you. You'll get a standards-compliant security.txt file to publish at /.well-known/security.txt on your site.
Runs entirely in your browser. Nothing you enter is sent to us.
security.txt
Publish at https://yourdomain.com/.well-known/security.txt, served as text/plain.
How to use the result
Publishing your security.txt
- Save the file as
security.txtand upload it to/.well-known/on every domain you operate. - Check it loads over HTTPS as plain text, and that every link in it works.
- Make sure someone reads the inbox. A security contact nobody monitors is worse than none, because reports go unanswered.
- Renew before it expires. An expired file tells researchers the information may be out of date.
You can optionally sign the file with OpenPGP. This tool produces the unsigned version, which is what most sites publish.
Background
What security.txt is
security.txt is a small text file, defined in RFC 9116, that tells security researchers how to report a vulnerability to you. It lives at /.well-known/security.txt, so anyone can find it without searching your site or guessing an email address.
The fields
- Contact (required): an email address, phone number or web page for reports. You can list more than one, in order of preference.
- Expires (required): the date after which the file shouldn't be trusted. RFC 9116 recommends setting it less than a year ahead.
- Policy: a link to your vulnerability disclosure policy, which explains what researchers may test and how you'll respond.
- Encryption: a link to a key researchers can use to encrypt sensitive reports.
- Acknowledgments: a page thanking people who have reported issues.
- Preferred-Languages: the languages your team can read reports in.
- Canonical: the URL where the file officially lives, so copies elsewhere can be spotted.
- Hiring: a link to security roles you're hiring for.
Why it's worth publishing
Without a published contact, people who find a flaw in your product often can't reach the right team, and reports end up in a sales inbox or nowhere at all. A security.txt file and a short disclosure policy give them a clear route, and give you the chance to fix issues before they become public. See our own disclosure policy for an example.
FAQ
security.txt Generator questions
Do we need a bug bounty to publish security.txt?
No. security.txt only says how to contact you. You can accept reports without offering rewards. Say so in your disclosure policy so researchers know what to expect.
Where exactly does the file go?
At https://yourdomain/.well-known/security.txt, served as plain text over HTTPS. RFC 9116 also allows a copy at /security.txt for older tools, but the .well-known location is the one to rely on.
Should every subdomain have one?
Publish one on each domain and important subdomain that people might report issues for. They can all point to the same contact and policy.
How often should we update it?
Before the Expires date, and whenever your contact details or policy change. A reminder a month before it expires is a simple way to keep it current.