Складайте abuse-скарги для реєстраторів, хостинг-провайдерів і CDN у вигляді листа та JSON.
Генератор security.txt
Сам інструмент доступний англійською мовою; на цій сторінці наведено пояснення вашою мовою.
Використовуйте Генератор security.txt
Як це працює
Створіть файл security.txt, щоб дослідники й люди, які повідомляють про фішинг під виглядом вашого бренду, знали, як із вами зв'язатися. Збережіть результат як /.well-known/security.txt.
Програма працює повністю у вашому браузері: жодні введені вами дані не завантажуються.
Як користуватися Генератор security.txt
- Введіть контакт. У полі «Контакти» вкажіть, як зв’язатися з вашою командою безпеки, по одному елементу в кожному рядку: mailto:security@example.com, адресу https:// форми повідомлення або номер телефону. До простої адреси електронної пошти автоматично додається префікс «mailto:».
- Встановіть дату закінчення дії. Виберіть дату в Expires. За замовчуванням це рік від сьогодні; RFC 9116 рекомендує менше року, тож виберіть ранішу дату.
- Додайте необов'язкові поля. Заповніть Preferred-Languages (за замовчуванням en), Canonical, Policy, Encryption, Acknowledgments і Hiring, якщо вони у вас є. Порожні поля до файлу не потрапляють.
- Створіть і скопіюйте. Натисніть Generate і прочитайте результат у полі виводу. Ще раз перевірте кожну адресу, бо інструмент копіює їх так, як їх введено, потім натисніть Copy (копіювати).
- Опублікуйте й оновлюйте. Збережіть текст як /.well-known/security.txt на своєму сайті з доступом через HTTPS, за бажання підпишіть його командою gpg --clearsign і запишіть дату, щоб оновити файл до закінчення його дії.
Приклад
Мінімальний файл
mailto:security@example.comContact: mailto:security@example.com
Expires: 2027-10-20T23:59:59.000Z
Preferred-Languages: enГенерує поле «Contact»: mailto:security@example.com, поле «Expires» із терміном дії через рік о 23:59:59Z та поле «Preferred-Languages»: en — два обов’язкові поля та підказку щодо мови, із нагадуванням про те, що RFC 9116 рекомендує встановлювати дату «Expires» не пізніше ніж через рік.
Що перевіряється
| Сигнал | Що це означає |
|---|---|
| Contact: | Один рядок на кожен контакт, у тому порядку, в якому ви їх ввели. Кожен контакт повинен мати вигляд URI типу «mailto:», «https://» або «tel:», як передбачено стандартом RFC 9116; при введенні «http://» або неправильно сформованих значень замість файлу з’явиться повідомлення про помилку. |
| Expires: | Вибрана дата о 23:59:59 UTC, записана з мілісекундами, наприклад 2027-03-31T23:59:59.000Z. Якщо очистити поле дати, Generate перестає створювати новий файл. |
| Preferred-Languages: | За замовчуванням en. Використовуйте коди мов через кому, наприклад en, de, або очистіть поле, щоб пропустити цей рядок. |
| Canonical: | Повна адреса https://, за якою розміщено цей файл, щоб можна було розпізнати копію, що віддається з іншого місця. |
| Encryption: | Посилання на ваш відкритий ключ OpenPGP, щоб ті, хто повідомляє, могли зашифрувати чутливі подробиці. |
| Policy, Acknowledgments, Hiring | Посилання на вашу політику розкриття вразливостей, сторінку подяк тим, хто повідомляє, і вакансії в безпеці. Усі необов'язкові, і інструмент не перевіряє, чи працюють посилання. |
| Рольова адреса в Contact | Використовуйте адресу чи форму, за якою стежить команда, наприклад security@ вашого домену, а не поштову скриньку однієї людини, щоб повідомлення надходили й тоді, коли люди змінюють роботу. |
| Error: Contact is required | Відображається, коли поле «Контакт» порожнє. Будь-яка помилка замінює результат на повідомлення про те, що нічого не було згенеровано, доки поля не будуть виправлені. |
Ще кілька прикладів
Вебформа з мовами та політикою
Contact https://example.org/report-security, Expires 2027-03-31, Preferred-Languages en, de, Canonical https://example.org/.well-known/security.txt, Policy https://example.org/security-policyП'ять рядків у такому порядку: Contact: https://example.org/report-security, Expires: 2027-03-31T23:59:59.000Z, Preferred-Languages: en, de, Canonical: https://example.org/.well-known/security.txt, Policy: https://example.org/security-policy.
Контакт електронною поштою з ключем, без мови
Contact mailto:abuse@example.net, Expires 2027-06-30, Preferred-Languages cleared, Encryption https://example.net/pgp-key.txtТри рядки: Contact: mailto:abuse@example.net, Expires: 2027-06-30T23:59:59.000Z і Encryption: https://example.net/pgp-key.txt.
Поле Contact залишено порожнім
All fields filled except ContactПомилка: Поле «Контакт» є обов’язковим для заповнення, а також з’явилося повідомлення про те, що нічого не було згенеровано. Значення в інших полях збереглися, тому заповніть поле «Контакт» і натисніть кнопку «Згенерувати» ще раз.
Часті запитання
Які поля обов'язкові?
Згідно з RFC 9116, обов’язковими є принаймні одне поле «Contact» і рівно одне поле «Expires»; решта полів є необов’язковими. Кожен рядок «Contact» повинен мати вигляд URI у форматі «mailto:», «https://» або «tel:» (до простої адреси електронної пошти додається «mailto:»), поле «Expires» має містити дату в майбутньому, а функція «Generate» відображає повідомлення про помилку замість файлу, якщо одне з цих полів відсутнє або є недійсним.
Яку дату вказати в Expires?
За замовчуванням дата встановлюється на один рік від сьогодні, тоді як у RFC 9116 рекомендується встановлювати термін менше одного року, тому, щоб дотриматися цієї рекомендації, виберіть більш ранню дату; сторінка нагадає вам, якщо дата буде більше ніж через рік. Оновіть файл до настання цієї дати, оскільки згідно з RFC файл security.txt, термін дії якого закінчився, слід вважати застарілим.
Чи завантажує або підписує він щось?
Ні. Файл складається у вашому браузері, і нічого нікуди не надсилається. Він не підписаний; RFC 9116 рекомендує текстовий підпис OpenPGP (cleartext signature), який можна додати командою gpg --clearsign перед публікацією.
Чи можна вказати більше одного контакту?
Так. Стандарт RFC 9116 дозволяє вказувати кілька рядків з контактними даними, які обробляються в порядку пріоритетності. У полі «Контакт» введіть по одному контакту в кожному рядку; дублікати записуються лише один раз.
Де саме має лежати файл?
За адресою https://your-domain/.well-known/security.txt, з доступом через HTTPS як звичайний текст. Копія або переспрямування за адресою /security.txt необов'язкові.
Чи охоплює один файл мої піддомени?
Ні. За RFC 9116 security.txt стосується лише хоста, з якого його отримано, а не його піддоменів чи батьківського домену. Опублікуйте копію на кожному хості, де люди можуть її шукати, наприклад www і shop.
Як security.txt допомагає проти фішингу, що копіює мій бренд?
Люди, які знаходять схожий сайт або фейковий лист від вашого імені, часто хочуть вас попередити. Робочий рядок Contact доставляє таке повідомлення вашій команді безпеки, а не до загальної черги підтримки, тож ви зможете швидше вжити заходів щодо схожого домену.