Przejdź do treści
TextArray1.41.0
100% lokalnie

walidator security.txt

Sprawdź plik security.txt względem RFC 9116 i wymień, co brakuje, jest nieprawidłowe lub przestarzałe.

Wejście
Wynik
Powiązane narzędzia
Robots.txt testernoweNarzędzia dla programistów
Generator humans.txtNarzędzia dla programistów
Sprawdzanie SPF i DMARCnoweNarzędzia dla programistów
różnica kluczy i18nNarzędzia dla programistów
Konwerter TOML na JSONNarzędzia dla programistów
SQL do JSONNarzędzia dla programistów
walidator security.txt
Wklej zawartość pliku security.txt — tego, który powinien znajdować się pod adresem /.well-known/security.txt — a to narzędzie sprawdzi go zgodnie z RFC 9116, standardem definiującym format. Zgłasza brakujące pola wymagane, wartości, które się nie parsują, oraz nazwy pól, które są przestarzałe lub nieznane, każde powiązane z wierszem, z którego pochodzi.
RFC 9116 wymaga co najmniej jednego wiersza "Contact" i dokładnie jednego wiersza "Expires"; oba są sprawdzane domyślnie, wraz z datą w polu "Expires" — musi to być pełny znacznik ISO 8601 ze strefą czasową, a narzędzie ostrzega, gdy data już minęła. Pola Encryption, Policy, Hiring, Canonical i Acknowledgments powinny zawierać URI, więc narzędzie oznacza nagą domenę lub e-mail bez schematu. Również wychwytuje przestarzałą brytyjską pisownię "Acknowledgements" (RFC 9116 używa "Acknowledgments"), pola zaniechane z wcześniejszych wersji, takie jak "Disclosure", nazwy pól napisane dużymi literami, zduplikowane wiersze "Expires" lub "Preferred-Languages" oraz pola, które wychodzą poza zwykłą kolejność czytania. Każdy z tych sprawdzeń można wyłączyć indywidualnie.
Przepinaj wyjście między listą ustaleń wiersz po wierszu a poprawionym plikiem: poprawiona wersja zmienia kolejność pól na zwykłą, redukuje zduplikowane pola liczbę pojedynczą do pierwszego wystąpienia, naprawia przestarzałe nazwy pól i zachowuje wszystko, czego nie rozpoznaje, zamiast je usuwać. Wiersze bez prawidłowego kształtu "Field: value" są oznaczone zamiast domysłów, a brakujący "Contact" lub "Expires" jest zanotowany komentarzem zamiast być całkowicie wymyślonym.
Wszystko działa lokalnie w Twojej przeglądarce — plik, który wklejasz, który jest często rzeczywistym, jeszcze nieopublikowanym adresem kontaktu bezpieczeństwa, nigdy nie jest wysyłany nigdzie. Skopiuj wynik, pobierz go jako plik .txt gotowy do publikacji lub wyślij go z powrotem na wejście, aby sprawdzić kolejną wersję.
Częste pytania
Co dokładnie wymaga RFC 9116?
Co najmniej jeden wiersz "Contact" i dokładnie jeden wiersz "Expires" z prawidłowym znacznikiem czasu RFC 3339. Wszystko inne — Encryption, Canonical, Preferred-Languages, Acknowledgments, Hiring i Policy — jest opcjonalne.
Dlaczego moja data "Expires" jest oznaczona jako nieprawidłowa?
RFC 9116 wymaga pełnego znacznika czasu ze strefą czasową, takiego jak 2027-01-01T00:00:00Z. Sama data, taka jak 2027-01-01, lub format inny niż ISO nie spełnia specyfikacji, nawet jeśli wygląda jak data.
Co zmieni "Poprawiony plik"?
Zmienia kolejność pól na zwykłe pořadí czytania, utrzymuje tylko pierwsze wystąpienie pola, które musi być pojedyncze (Expires, Preferred-Languages), i naprawia przestarzałą pisownię "Acknowledgements" na "Acknowledgments". Nigdy nie wymyśla wartości Contact lub Expires, która nie jest już w Twoim pliku.
Czy pobierze mój aktywny security.txt z mojej domeny?
Nie. Wklej zawartość pliku sam — narzędzie nigdy nie wysyła żądania sieciowego, więc nie może potwierdzić, co jest faktycznie opublikowane pod adresem /.well-known/security.txt na Twojej stronie.
Czy mój plik security.txt jest gdzieś przesyłany?
Nie. Walidacja odbywa się całkowicie w Twojej przeglądarce. Ponieważ ten plik często zawiera rzeczywisty, jeszcze nieopublikowany adres kontaktu bezpieczeństwa, nic, co wklejasz, nigdy nie opuszcza Twojego urządzenia.