Web Bot Auth — jak zweryfikować tożsamość bota?
User-Agent mówi, za kogo podaje się klient, lecz sam nie potwierdza jego tożsamości. Web Bot Auth opisuje rozwijany mechanizm, który łączy podpisane żądanie HTTP z kluczem publikowanym pod wskazanym identyfikatorem.
Szybka odpowiedź
Web Bot Auth to rozwijany w IETF mechanizm, w którym automatyczny klient podpisuje wybrane elementy żądania HTTP, a serwis sprawdza podpis względem klucza powiązanego z identyfikatorem. Weryfikacja może potwierdzić powiązanie podpisanego żądania z opublikowanym kluczem, ale nie dowodzi celu ani uczciwości ruchu. Ten materiał opisuje zewnętrzne prace IETF i nie oznacza, że Bot Protection obecnie obsługuje weryfikację Web Bot Auth.
Dla zespołów technicznych, security, marketingu, wydawców, ecommerce i AI governance, które chcą odróżnić deklarowaną nazwę bota od silniejszego dowodu tożsamości żądania.
Dlaczego User-Agent i sama lista IP nie wystarczają
Rozpoznanie nazwy klienta, adresu IP albo domeny reverse DNS może dostarczyć przydatnego kontekstu, ale każdy z tych sygnałów ma inny poziom pewności. Deklarację trzeba odróżnić od weryfikacji infrastruktury i od kryptograficznego potwierdzenia podpisanego żądania.
Deklarację User-Agent można podszyć
User-Agent jest wartością przesyłaną przez klienta. Osoba wysyłająca żądanie może wpisać nazwę znanego crawlera, dlatego zgodny tekst nagłówka oznacza deklarowaną, a nie zweryfikowaną tożsamość.
Zakresy IP i DNS wymagają utrzymania i nie opisują celu
Listy adresów IP i kontrola DNS mogą wiązać ruch z określoną infrastrukturą, lecz zakresy zmieniają się, mogą należeć do dostawcy chmury i wymagają aktualizacji. Nawet prawidłowe powiązanie sieciowe nie wyjaśnia, po co klient pobiera konkretny zasób.
Jak działa podpisane żądanie HTTP — model pojęciowy
RFC 9421 opisuje ogólny mechanizm podpisywania wybranych elementów wiadomości HTTP oraz pola Signature-Input i Signature. Projekt Web Bot Auth stosuje ten mechanizm do ruchu automatycznego i dodaje identyfikator Signature-Agent wskazujący adres HTTPS powiązany z materiałem klucza.
W modelu projektu serwis pobiera katalog kluczy w formacie opartym na JWKS i sprawdza, czy opublikowany klucz weryfikuje podpis nad objętymi nim elementami żądania. Sam adres Signature-Agent przed rozwiązaniem i sprawdzeniem jest tylko deklaracją. Poprawny podpis oznacza, że posiadacz odpowiadającego klucza podpisał określony zakres wiadomości — nie potwierdza automatycznie operatora, celu ani autoryzacji działania.
Jaki jest status Web Bot Auth w IETF
Na dzień 24 sierpnia 2026 r. aktywny dokument protokołu to draft-meunier-webbotauth-httpsig-protocol-02, opublikowany jako indywidualny Internet-Draft z zamiarem ścieżki Standards Track. Nie ma przypisanego strumienia RFC i nie jest RFC ani sfinalizowanym standardem IETF; projekt może zostać zmieniony, zastąpiony lub wycofany.
Grupa robocza Web Bot Auth w IETF jest aktywna i ma zatwierdzoną kartę prac nad kryptograficznym uwierzytelnianiem klientów automatycznych. RFC 9421 ma osobny, dojrzały status Standards Track i dostarcza ogólny mechanizm HTTP Message Signatures. Status RFC 9421 nie przenosi się na projekt Web Bot Auth.
Poziomy dojrzałości tożsamości bota
Sygnały warto zapisywać warstwowo. Wyższy poziom może zwiększać pewność atrybucji, ale nie usuwa potrzeby oceny celu, zachowania i zgodności z polityką zasobu.
Deklaracja
Nazwa klienta, token User-Agent albo wartość nagłówka pokazują, jak żądanie przedstawia samo siebie. Bez niezależnego sprawdzenia pozostają deklaracją.
Weryfikacja sieciowa lub DNS
Opublikowane zakresy IP, ASN oraz kontrola forward i reverse DNS mogą powiązać żądanie z infrastrukturą. To silniejszy kontekst niż sama nazwa, lecz nadal zależy od aktualności danych i nie dowodzi celu ruchu.
Weryfikacja podpisu
Podpis kryptograficzny sprawdzony względem klucza powiązanego z rozwiązanym identyfikatorem może potwierdzić, że posiadacz tego klucza podpisał objęte elementy wiadomości. Zakres wniosku zależy od podpisanych komponentów, ważności klucza oraz ochrony przed powtórzeniem żądania.
Zachowanie, cel i polityka
Dopiero połączenie tożsamości z obserwowanym zachowaniem, deklarowanym lub ustalonym celem, typem zasobu i obowiązującą polityką pozwala wybrać właściwą reakcję. To odrębna ocena od technicznej poprawności podpisu.
Czego zweryfikowana tożsamość nie dowodzi
Zweryfikowana tożsamość usługi nie dowodzi, czy żądanie służy wyszukiwaniu, treningowi, działaniu agenta czy innemu celowi. Nie gwarantuje też, że ruch jest łagodny, potrzebny właścicielowi strony albo zgodny z limitem i regułami dostępu.
Poprawny podpis nie potwierdza przestrzegania robots.txt, zastrzeżenia TDM, autoryzacji użytkownika ani zgodności prawnej. Te pytania wymagają osobnych danych o celu, zachowaniu, polityce, zasobie i kontekście prawnym.
Ograniczenia wdrożenia i adopcji
Mechanizm działa tylko wtedy, gdy klient podpisuje odpowiedni zakres wiadomości, publikuje osiągalne i aktualne klucze, a odbiorca potrafi poprawnie zweryfikować podpis. Rotacja i unieważnianie kluczy, dostępność katalogu, czas ważności, ochrona przed replay oraz zmiany wprowadzane przez pośredników stają się częścią procesu operacyjnego.
Dokumentacja Cloudflare pokazuje przykład implementacji po stronie jednego operatora. Nie oznacza to powszechnej adopcji, zgodności wszystkich wdrożeń ani obsługi przez Bot Protection. Brak podpisu także nie dowodzi, że klient jest człowiekiem lub działa szkodliwie — może oznaczać brak uczestnictwa w mechanizmie.
Jak wykorzystać sygnał tożsamości w audycie polityki
W audycie należy osobno zapisać identyfikator zadeklarowany, wynik weryfikacji sieciowej, wynik ewentualnej weryfikacji kryptograficznej, poziom pewności oraz zakres objęty podpisem. Następnie dane o tożsamości trzeba zestawić z celem, zachowaniem klienta, żądanym zasobem i regułą polityki.
Dopiero taki zestaw pozwala uzasadnić obserwację, limitowanie, dopuszczenie lub blokadę. Web Bot Auth jest tu potencjalnym źródłem dowodu tożsamości, a nie kompletną oceną crawlera ani ofertą wdrożenia mechanizmu przez Bot Protection.
Zobacz wykrywanie botów z wielu sygnałówPrzejdź do modelu AI Crawler GovernanceRozróżnij cele AI Search, AI Agent i AI TrainingSprawdź zachowanie crawlera wobec polityki
Czytaj także
Źródła i dalsza weryfikacja
Prawo, dokumentacja platform i standardy techniczne mogą się zmieniać. Przed działaniem sprawdź aktualne źródła oraz kontekst swojej organizacji.