Перейти к содержанию
TextArray1.41.0
100% локально

Валидатор security.txt

Проверьте файл security.txt по RFC 9116 и узнайте, что отсутствует, неверно или устарело.

Входные данные
Выходные данные
Связанные инструменты
Robots.txt тестерновоеИнструменты разработчика
Генератор human.txtИнструменты разработчика
Проверка SPF и DMARCновоеИнструменты разработчика
i18n ключевая разницаИнструменты разработчика
Конвертер TOML в JSONИнструменты разработчика
SQL в JSONИнструменты разработчика
Валидатор security.txt
Вставьте содержимое файла security.txt — того, что должен находиться в /.well-known/security.txt — и этот инструмент проверит его по RFC 9116, стандарту, определяющему формат. Он сообщает об отсутствующих обязательных полях, значениях, которые не анализируются, и названиях полей, которые устарели или не распознаны, каждое привязано к строке, откуда оно взялось.
RFC 9116 требует как минимум одну строку "Contact" и ровно одну строку "Expires"; обе проверяются по умолчанию, вместе с самой датой "Expires" — она должна быть полной меткой времени ISO 8601 с часовым поясом, и инструмент предупреждает, когда эта дата уже истекла. Encryption, Policy, Hiring, Canonical и Acknowledgments должны содержать URI, поэтому инструмент помечает простой домен или адрес электронной почты без схемы. Он также обнаруживает устаревшее британское написание "Acknowledgements" (RFC 9116 использует "Acknowledgments"), поля, удаленные из предыдущих черновиков, такие как "Disclosure", названия полей, набранные в неправильном регистре, дублирующиеся строки "Expires" или "Preferred-Languages", и поля, которые выпадают из обычного порядка чтения. Любая из этих проверок может быть отключена отдельно.
Переключайтесь между выводом список проблем, построчно, и исправленным файлом: исправленная версия переупорядочивает известные поля в обычном порядке, сводит дублирующиеся единственные поля к первому появлению, исправляет устаревшие названия полей и сохраняет все, что не распознается, вместо удаления. Строки без допустимой формы "Field: value" вызываются вместо угадывания, а отсутствующие "Contact" или "Expires" указываются комментарием, а не выдумываются совсем.
Всё работает локально в вашем браузере — файл, который вы вставляете, часто это реальный, еще не опубликованный адрес контакта безопасности, никогда не загружается никуда. Скопируйте результат, загрузите его как файл .txt, готовый к публикации, или отправьте обратно во входные данные, чтобы проверить другую версию.
FAQ
Что именно требует RFC 9116?
Как минимум одно поле "Contact" и ровно одно поле "Expires" с действительной меткой времени RFC 3339. Все остальное — Encryption, Canonical, Preferred-Languages, Acknowledgments, Hiring и Policy — опционально.
Почему моя дата "Expires" помечена как недействительная?
RFC 9116 требует полную дату-время с часовым поясом, например 2027-01-01T00:00:00Z. Одна дата, такая как 2027-01-01, или формат, не являющийся ISO, не удовлетворяет спецификации, даже если выглядит как дата.
Что изменит "Исправленный файл"?
Он переупорядочивает известные поля в обычном порядке чтения, оставляет только первое появление поля, которое должно быть единственным (Expires, Preferred-Languages), и исправляет устаревшее написание "Acknowledgements" на "Acknowledgments". Он никогда не придумывает значение Contact или Expires, которого нет в вашем файле.
Он извлекает мой живой security.txt из моего домена?
Нет. Вставьте содержимое файла самостоятельно — инструмент никогда не делает сетевой запрос, поэтому не может подтвердить, что на самом деле опубликовано в /.well-known/security.txt на вашем сайте.
Мой файл security.txt загружается где-то?
Нет. Валидация выполняется полностью в вашем браузере. Поскольку этот файл часто содержит подлинный, еще не опубликованный адрес контакта безопасности, ничто из того, что вы вставляете, никогда не покидает ваше устройство.