security.txt, ads.txt i llms.txt: co potwierdza kontrola stałych ścieżek

Management Summary
Niektóre informacje witryny znajdują się pod stałymi adresami, aby ludzie i programy mogli łatwo je odnaleźć. security.txt wskazuje kontakt bezpieczeństwa, ads.txt upoważnionych sprzedawców reklam, a llms.txt wskazówki dla AI. Pliki pełnią różne zadania, zamiast tworzyć jedną listę bezpieczeństwa. Historyczny przegląd dwudziestu hostów pokazuje, że odpowiedź pod oczekiwanym adresem nie dowodzi poprawnej treści. Pliki opcjonalne nie zawsze są potrzebne, a opublikowane wskazówki nie wymuszają ograniczeń dostępu.
Spis treści
Znane ścieżki ułatwiają znalezienie wybranych informacji o witrynie. Sama odpowiedź pod takim adresem nie potwierdza poprawnego pliku. Historyczna próba opisuje wyniki ograniczonego kontrolera, a nie pełne badanie zgodności ze standardami.

Rejestr, konwencje i propozycja
RFC 8615 rezerwuje /.well-known/ dla zasobów określanych przez aplikacje. Nie oznacza to bezwarunkowej publicznej dostępności każdego zasobu ani ogólnego wyjątku zapory. Zakres i zasady pobierania zależą od konkretnego formatu.
Próba obejmuje również ścieżki główne. Nie wszystkie są starsze od /.well-known/: ads.txt powstał w 2017, a llms.txt zaproponowano we wrześniu 2024. Mapa witryny nie musi nazywać się sitemap.xml. Obecna propozycja llms.txt v2 dopuszcza też podścieżki, np. /docs/llms.txt. Kontrola samego katalogu głównego nie dowodzi braku pliku w całej witrynie.
Co policzyła historyczna próba
Zapis wyników ma datę 5 września 2026, 18:19:59 +02:00. Obejmuje dwadzieścia hostów i po trzynaście ścieżek, łącznie 260 wyników. Przekierowania mogą wymagać dodatkowych żądań HTTP. Tabela zlicza klasyfikację obecny, a dla change-password osobną klasyfikację przekierowany.
Liczby nie potwierdzają związku przyczynowego między wiekiem a popularnością formatu. Próba nie jest reprezentatywna, a powiązania aplikacji i pliki reklamowe służą konkretnym celom. Brak pliku nie jest więc automatycznie usterką.
| Ścieżka | Klasyfikacje na 20 |
|---|---|
/.well-known/security.txt |
14 |
/security.txt |
5 |
/robots.txt |
18 |
/ads.txt |
9 |
/app-ads.txt |
8 |
/.well-known/gpc.json |
2 |
/llms.txt |
4 |
/.well-known/change-password |
4 |
/.well-known/assetlinks.json |
11 |
/.well-known/apple-app-site-association |
7 |
/.well-known/traffic-advice |
1 |
/humans.txt |
4 |
/sitemap.xml |
10 |
Cztery części wspólne zamiast pięciu
Czternaście hostów sklasyfikowano jako posiadające /.well-known/security.txt, a pięć jako posiadające /security.txt. Tylko cztery należą do obu grup: nytimes.com, bbc.co.uk, gov.uk i onet.pl. Piąty przypadek główny, heise.de, zwrócił w tym zapisie 404 pod ścieżką well-known.
RFC 9116 umieszcza security.txt usług WWW pod /.well-known/. Przekierowanie z katalogu głównego wspiera starszych klientów bez utrzymywania dwóch kopii. Wymagania obejmują Contact, dokładnie jeden znacznik czasu Expires, HTTPS, text/plain i UTF-8. Pełna składnia oraz ewentualne pole Canonical wymagają dalszej kontroli. Znalezienie dwóch nazw pól nie jest pełną walidacją.
Przekierowanie nie dowodzi formularza zmiany hasła
Konwencja change-password prowadzi do strony zmiany hasła konta. Zapis zawiera cztery klasyfikacje przekierowania, ale dwie kończą się statusem 301 po trzech zapisanych krokach. Nie osiągnięto więc i nie potwierdzono docelowego formularza.
Nawet przekierowanie kończące się statusem 200 może prowadzić do logowania, strony głównej lub niewłaściwego celu. Poprawny endpoint wymaga właściwego celu i działającego procesu. Dowolne przekierowanie nie jest wystarczającym dowodem.
Odmowa i HTML wymagają interpretacji
Stack Overflow zwrócił jedno 418 i siedem odpowiedzi 429. Nie dowodzi to jednej reguły blokującej wszystkich nieznanych klientów ani nie rozstrzyga istnienia plików. Inne hosty również zwracały 403 lub 406.
Dwa wyniki oznaczono jako soft 404, ponieważ wykryto HTML zamiast oczekiwanego formatu. To uproszczona reguła oparta na treści odpowiedzi, a nie potwierdzona diagnoza: strona kontroli botów lub objaśniający HTML mogą wyglądać podobnie. Content-Type pozostaje istotny dla zgodności formatu. Sam status lub początek treści nie rozstrzyga każdego przypadku.
Ograniczenia inspektora
Narzędzie pobiera trzynaście ścieżek, dopuszcza do trzech przekierowań i odczytuje najwyżej 204 800 bajtów na zasób. Heurystyka HTML obejmuje tylko pierwsze 2000 znaków i pomija mapy witryny. Lokalne próby potwierdziły, że zwykły komunikat błędu oraz HTML pod sitemap.xml mogą nadal otrzymać klasyfikację obecny.
Parsery sprawdzają wybrane cechy, a nie całą specyfikację. Znacznik PGP nie oznacza weryfikacji podpisu, a licznik linków pomija względne odsyłacze Markdown, na przykład /kontakt zamiast pełnego adresu https://. Przekierowanie nie potwierdza przetestowanej zmiany hasła. Skrócone odpowiedzi i te ograniczenia są częścią interpretacji.
Deklaracje GPC i wskazówki dla AI
Dwa zapisy zawierają pozytywną deklarację GPC, lecz w jednym odnotowano brak daty aktualizacji. gpc.json jest opcjonalnym oświadczeniem zamiaru obsługi. Brak nie dowodzi odrzucenia, a obecność nie potwierdza faktycznego przetwarzania. Mała próba nie mierzy ogólnej popularności w przeglądarkach.
llms.txt zawiera uporządkowane wskazówki i linki dla agentów. Nie jest kontrolą dostępu ani gwarancją odczytu przez crawler. ads.txt wskazuje upoważnionych sprzedawców reklam; policzony rekord nie potwierdza niezależnie relacji handlowej.
Inspektor plików well-known i polityk
Pytania i odpowiedzi
Czy HEAD wystarcza do walidacji?
Nie. HEAD pozwala obejrzeć nagłówki, ale nie dostarcza treści potrzebnej do kontroli pól i składni. Więcej informacji daje GET z zapisem statusu, nagłówków, przekierowań i treści. Polecenie podążające za przekierowaniami może wykonać kilka żądań.
Czy wszystkie ścieżki well-known powinny omijać ochronę?
Nie. Dostęp powinien odpowiadać zasobowi i oczekiwanym klientom. Celowy wyjątek dla publicznych danych kontaktowych różni się od wyłączenia ochrony całego katalogu. Odpowiedzi 403 i 429 trzeba odróżniać od potwierdzonego 404.


