Awe Checksecurity.txt: how to receive vulnerability reports for your site
The security.txt file per RFC 9116: what to put in it, where to place it and why even a small site needs it. A ready example and a link to the generator.
Checked against sources: 11 October 2026
- RFC 9116the security.txt standard
- 2required fields: Contact and Expires
- 1 yearmaximum for the Expires date
Why the file exists
A researcher found a hole on your site. If it is unclear whom to tell, they stay silent or publish openly. security.txt answers that with one address.
What it must contain
- Contact: an email, form or phone for reports. Required.
- Expires: when the file lapses, no more than a year ahead. Required.
- Preferred-Languages, Policy, Encryption, Acknowledgments: optional.
Contact: mailto:security@example.com Expires: 2027-12-31T23:59:59Z Preferred-Languages: en, ru
Where to put it
At /.well-known/security.txt in the site root, over HTTPS, as plain text. Refresh the Expires date yearly: an expired file is invalid and Awe Check flags it as a risk. The security.txt generator builds the file for you.
Frequently asked
Is security.txt mandatory?
No, no law requires it. But for a site with personal data and payments it is a cheap sign of maturity that security scanners look for.
Which contact should I give?
A dedicated mailbox such as security@yoursite that a person reads. Not a developer’s personal address: it leaves with the person.
What if a report arrives?
Reply within two or three days, verify, fix and tell the author. If you stay silent they will likely publish the finding themselves.
