security.txt: как принимать сообщения об уязвимостях сайта
Файл security.txt по RFC 9116: что в него писать, куда положить и почему он нужен даже небольшому сайту. Готовый пример и ссылка на генератор.
Проверено по источникам: 11 октября 2026 г.

- RFC 9116стандарт файла security.txt
- 2обязательных поля: Contact и Expires
- 1 годмаксимум для срока Expires
Зачем нужен файл
Исследователь нашёл дыру на вашем сайте. Если непонятно, кому написать, он промолчит или опубликует находку открыто. Файл security.txt отвечает на этот вопрос одним адресом.
Что в нём должно быть
- Contact: почта, форма или телефон для сообщений. Обязательное поле.
- Expires: дата окончания действия файла, не дальше года. Обязательное поле.
- Preferred-Languages, Policy, Encryption, Acknowledgments: по желанию.
Contact: mailto:security@example.com Expires: 2027-12-31T23:59:59Z Preferred-Languages: ru, en
Куда положить
По адресу /.well-known/security.txt в корне сайта, по HTTPS, как обычный текст. Раз в год обновляйте дату Expires: просроченный файл считается недействительным, и Awe Check отметит его как риск. Готовый файл соберёт генератор security.txt.
Частые вопросы
Обязательно ли иметь security.txt?
Нет, закон его не требует. Но для сайта с личными данными и платежами это недорогой признак зрелости, который проверяют сканеры безопасности.
Какой контакт указывать?
Отдельную почту вроде security@вашсайт, которую читает человек. Не личный адрес разработчика: он уйдёт вместе с человеком.
Что делать, если пришло сообщение об уязвимости?
Ответьте за два-три дня, проверьте находку, исправьте и сообщите автору. Если вы не отвечаете, он, скорее всего, опубликует находку сам.
