Security.txt: куда сообщать об уязвимости вашего сайта

Security.txt указывает, куда сообщить об уязвимости сайта, но полезен только вместе с работающим каналом и ответственным за разбор. Опубликуйте актуальные Contact и Expires, проверьте получение безопасного контрольного сообщения и назначьте замену основному исполнителю. Сам файл не предотвращает взлом и не запускает автоматически программу вознаграждений.

Как находят контакт, когда обычная поддержка не подходит

Сообщение о предполагаемой уязвимости может потеряться среди обращений о заказах или попасть подрядчику, который уже не обслуживает сайт. Публичный технический контакт помогает направить его сразу по нужному пути. Но адрес в файле ещё не подтверждает, что письмо дойдёт до человека с полномочиями.

В RFC 9116 определён формат security.txt и расположение /.well-known/security.txt для веб-сайта по HTTPS. Для владельца это понятная точка публикации. Проверка должна доходить до фактически получаемого содержимого, а не останавливаться на файле, который лежит в рабочей папке разработчика.

Минимальные поля и их назначение

Contact задаёт способ сообщения об уязвимости, а Expires — момент, после которого сведения считаются устаревшими. Срок актуальности контакта не является обещанием ответа за такое же время. В инструкции Cloudflare эти поля также обозначены как обязательные при настройке файла.

Для электронной почты используется соответствующий URI с mailto, для веб-канала — HTTPS-адрес. В реальной публикации подставляют только подтверждённый действующий канал. Не копируйте из примера чужой адрес и давно истёкшую дату, чтобы просто пройти проверку наличия полей.

Учебная карта приёма сообщения

Следующая таблица — предложенная организация работы небольшой команды. Она не описывает действующие контакты студии и не назначает универсальный срок реагирования. Конкретные обязанности и пределы доступа согласуются владельцем сервиса.

Как проверить канал без поиска уязвимостей

Достаточно согласованного сообщения о проверке связи без секретов, вложений с кодом и действий против сервиса. Подтвердите прохождение канала, регистрацию и передачу ответственному. Это проверяет обработку обращения, а не устойчивость сайта к атаке.

Отдельно проверьте, кто видит уведомление при отсутствии основного получателя. Общий адрес может пересылать письма в личный ящик бывшего сотрудника; веб-форма может показывать успех без создания задачи. Такие гипотезы требуют проверки результата, а не уверенности по внешнему виду канала.

В этой статье сообщение не отправлялось и контакты не публиковались. Контрольную процедуру проводит владелец в своей согласованной области. Публичный файл с вымышленным рабочим адресом не нужен даже для демонстрации: учебного описания достаточно до настройки настоящего канала.

Что должно происходить после получения

Внутренний процесс должен различать регистрацию, первичную оценку, необходимость уточнения и решение о дальнейшей работе. Письмо с предположением не является автоматически подтверждённой уязвимостью. Но отсутствие готового доказательства также не повод потерять сообщение без ответственного.

Сохраняйте необходимые сведения о затронутом ресурсе и предполагаемом воздействии в разрешённой области доступа. Не просите присылать пароли, персональные данные или полный закрытый набор ради удобного разбора. При необходимости специалист определит безопасный способ уточнения.

Если сообщение оказалось нерелевантным или повторным, отметьте основание решения и связь с уже известным случаем. Не создавайте множество независимых задач по одной проблеме. И не закрывайте всё одной общей пометкой, если затронуты разные сервисы и нужны разные действия.

Контакт не означает разрешение на любые тесты

RFC отдельно оговаривает отсутствие подразумеваемого разрешения на тестирование. Публикация или отсутствие security.txt не заменяет согласованные правила. Поэтому ссылка Policy и внутренний порядок должны описывать действительную область, если организация хочет её определить.

Обещание оплаты тоже должно иметь собственное основание. Не называйте файл bug bounty только потому, что рядом есть контакт безопасности. Вознаграждения, допустимые действия и обработка сообщений — разные условия, которые нельзя молча дописать за владельца сайта.

Когда пересматривать файл

Проверяйте его после смены подрядчика, ответственного, домена или канала приёма. Expires помогает напомнить о периодическом пересмотре, но не узнаёт такие события самостоятельно. Удаление старого ящика без обновления публикации оставляет внешнего отправителя с неверным маршрутом.

Для нескольких сервисов уточните область действия опубликованных сведений. Не предполагайте, что файл одного адреса автоматически задаёт одинаковый порядок для всех проектов компании. Получатель должен понимать, какие ресурсы он обслуживает и куда передать обращение вне своей области.

Приёмка процесса disclosure

1. Назначьте владельца канала и согласуйте область обслуживаемых ресурсов.
2. Подготовьте действительные Contact и Expires, при необходимости ссылку Policy.
3. Проверьте фактическое получение файла по согласованному HTTPS-адресу.
4. Проведите безопасную проверку связи и подтвердите регистрацию обращения.
5. Проверьте замещение и передачу на разбор без раскрытия лишних данных.
6. Запланируйте пересмотр и свяжите его со сменой ответственных или подрядчика.

Для аудита безопасности можно описать такую цепочку как проверяемый процесс. В задаче доработки сайта укажите способ публикации и обновления файла. Если каналом служит почта, в поддержке почты нужны требования к доставке и доступу ответственных.

Признак работающего решения — обращение доходит до нужного человека и получает понятный статус. Наличие файла само по себе доказывает только публикацию сведений, а не готовность команды обработать проблему.