Web Bot Auth — kryptograficzne uwierzytelnianie botów (RFC 9421)

Web Bot Auth to eksperymentalny standard, w którym boty kryptograficznie podpisują swoje żądania HTTP, a operator strony weryfikuje ich tożsamość bez polegania na łatwym do podrobienia nagłówku User-Agent. Google testuje go już produkcyjnie z agentem Google-Agent, OpenAI publikuje swoje klucze publiczne dla ChatGPT, a prace standaryzacyjne prowadzą Cloudflare i Google w grupie IETF. To pierwszy mechanizm, który daje realny, niepodrabialny dowód, że bot pukający do drzwi Twojego serwisu naprawdę jest tym, kim się przedstawia.

W tym artykule wyjaśniamy, jak działa HTTP Message Signatures (RFC 9421), gdzie boty publikują klucze, jak wygląda przykładowe podpisane żądanie, jak to zweryfikować po stronie serwera oraz dlaczego — jako prawdopodobnie jedyne narzędzie na rynku — używamy tego standardu w Can AI See It do weryfikacji ruchu crawlerów AI.

Dlaczego user-agent i lista IP już nie wystarczają

Większość systemów wykrywania botów wciąż opiera się na trzech filarach: nagłówek User-Agent, lista znanych adresów IP operatora i odwrotny DNS (rDNS). Każdy z nich ma znane słabości:

• User-Agent jest tekstem — można w niego wpisać dowolny ciąg, w tym GPTBot/1.0 czy Googlebot/2.1. Spoofing user-agent to dosłownie jedna linijka w cURL lub bibliotece HTTP. Z analiz Cloudflare wynika, że znaczna część ruchu udającego znane boty AI w rzeczywistości pochodzi z innych źródeł.
• Listy IP są niestabilne — Google publikuje swoje zakresy w pliku googlebot.json, ale są aktualizowane bez ostrzeżenia. Trzymanie własnej listy oznacza dryf konfiguracji i ryzyko zablokowania prawdziwego ruchu Googlebota lub Bingbota.
• rDNS jest powolny — wymaga dodatkowych zapytań DNS przy każdym żądaniu, a nie każdy operator ma poprawnie skonfigurowane PTR i forward records. Dla ruchu z dziesiątek crawlerów AI staje się to wąskim gardłem.

Efekt: właściciele stron stoją przed paradoksem. Jeśli weryfikują boty zbyt rygorystycznie, blokują prawdziwych crawlerów AI (i tracą widoczność w generatywnych wyszukiwarkach). Jeśli weryfikują zbyt luźno, przepuszczają scrapery udające znane boty. Brakuje sygnału, którego nie da się sfałszować — i właśnie tę lukę wypełnia Web Bot Auth.

Web Bot Auth — co to jest i kto za tym stoi

Web Bot Auth to protokół, w którym bot dołącza do każdego żądania HTTP kryptograficzny podpis, a serwer weryfikuje go względem klucza publicznego opublikowanego pod znanym adresem URL operatora. Cała mechanika opiera się na dwóch dokumentach:

• RFC 9421 — HTTP Message Signatures (opublikowany w 2024 r. przez IETF). Definiuje, jak podpisywać i weryfikować wybrane elementy żądania HTTP — metodę, ścieżkę, host, wybrane nagłówki — używając pary kluczy asymetrycznych.
• draft-meunier-http-message-signatures-directory (aktualnie wersja 05, marzec 2026). Definiuje, jak operator botów publikuje swoje klucze publiczne — pod stałą ścieżką /.well-known/http-message-signatures-directory w formacie JSON Web Key Set (JWKS).

Autorami draftu są Thibault Meunier (Cloudflare) i Sandor Major (Google), a dyskusje toczą się na liście mailingowej Web Bot Auth Working Group. Mimo że dokument ma jeszcze status active Internet-Draft, dwie największe firmy w tym obszarze — Google i OpenAI — już wdrożyły go produkcyjnie dla części ruchu.

Jak technicznie działa podpisywanie żądań

Web Bot Auth wprowadza trzy nagłówki HTTP, które razem tworzą kompletny pakiet weryfikacyjny:

• Signature-Agent — wskazuje, do kogo należy podpis. Wartość to URL bazowy, pod którym opublikowany jest katalog kluczy publicznych. Przykładowo Google wysyła Signature-Agent: "https://agent.bot.goog".
• Signature-Input — opisuje, co zostało podpisane: które elementy żądania (metoda, ścieżka, autorytet hosta, wybrane nagłówki), identyfikator klucza (keyid), algorytm (alg) oraz znacznik czasu utworzenia i wygaśnięcia podpisu.
• Signature — sam podpis w postaci Base64. Tworzy go bot, używając swojego klucza prywatnego, podpisując kanoniczną reprezentację elementów wskazanych w Signature-Input.

Wszystkie trzy nagłówki używają formatu HTTP Structured Fields (RFC 8941), więc parsowanie jest jednoznaczne i deterministyczne.

Przykładowe podpisane żądanie HTTP

Tak wygląda fragment żądania, które Google-Agent może wysłać do Twojego serwera:

GET /artykul HTTP/1.1
Host: example.com
User-Agent: Google-Agent/1.0
Accept: text/html
Signature-Agent: "https://agent.bot.goog"
Signature-Input: sig1=("@authority" "@method" "@path" "signature-agent");\
  created=1747200000;expires=1747203600;\
  keyid="NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw";\
  alg="ed25519";tag="web-bot-auth"
Signature: sig1=:MEYCIQDJ7nM…+5o4w==:

Trzy istotne rzeczy, które się tu dzieją:

• Signature-Agent wskazuje hosta agent.bot.goog — to tam serwer pójdzie po klucz publiczny.
• Signature-Input wymienia komponenty podpisu (@authority, @method, @path, signature-agent) — gwarantuje, że ktoś nie skopiuje tego samego podpisu na żądanie o innej ścieżce.
• keyid wskazuje konkretny klucz w katalogu, alg="ed25519" ustala algorytm, a expires wymusza ograniczony czas ważności podpisu (zwykle pojedyncze minuty do godziny).

Klucz publiczny w katalogu .well-known

Pod stałą ścieżką /.well-known/http-message-signatures-directory operator publikuje JWKS — JSON Web Key Set zgodny z RFC 7517. Typowy plik wygląda tak:

{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "kid": "NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw",
      "x":   "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs",
      "use": "sig",
      "nbf": 1735689600,
      "exp": 1779351925
    }
  ]
}

Najważniejsze pola:

• kty: "OKP" i crv: "Ed25519" — typ klucza i krzywa eliptyczna. Ed25519 (Curve25519, EdDSA) jest dziś standardem de facto: szybki, krótki klucz, szybka weryfikacja.
• kid — unikalny identyfikator klucza. Serwer wybiera klucz z katalogu po kid z nagłówka Signature-Input.
• x — sama część publiczna klucza, zakodowana Base64URL.
• nbf i exp — uniksowe znaczniki czasu, między którymi klucz jest ważny. Wymuszają rotację — nawet jeśli atakujący jakimś cudem zdobędzie klucz prywatny, jego okres użyteczności jest ograniczony.

Typ MIME dla tego pliku to application/http-message-signatures-directory+json. Sam katalog również powinien być podpisany (zgodnie z RFC 9421) tymi samymi kluczami, które zawiera — tworzy to self-verifying structure i zamyka łańcuch zaufania.

Proces weryfikacji po stronie serwera

Kiedy podpisane żądanie trafia do Twojego serwera, weryfikacja przebiega w pięciu krokach:

1. Odczytaj nagłówek Signature-Agent i wyciągnij URL bazowy operatora.
2. Pobierz katalog kluczy z ${Signature-Agent}/.well-known/http-message-signatures-directory — wynik trzeba cache'ować zgodnie z nagłówkiem Cache-Control z odpowiedzi (typowo kilka–kilkanaście godzin).
3. Z Signature-Input wyciągnij keyid i znajdź odpowiadający mu klucz w polu keys JWKS.
4. Zbuduj kanoniczną reprezentację podpisanych komponentów zgodnie z RFC 9421 i zweryfikuj podpis z nagłówka Signature przy użyciu klucza publicznego.
5. Sprawdź, czy created/expires mieszczą się w akceptowalnym oknie czasowym względem zegara serwera (przeciwdziała atakom replay).

Jeśli wszystko się zgadza — masz pewność, że żądanie naprawdę pochodzi od operatora, który kontroluje klucz prywatny odpowiadający kluczowi publicznemu pod podanym hostem. Tej gwarancji nie da nagłówek User-Agent ani analiza IP.

Rotacja kluczy

Draft rekomenduje konkretny model rotacji, który minimalizuje ryzyko nieważnych podpisów:

• Dodaj nowy klucz do katalogu przed datą jego użycia (nbf ustawione w przyszłości).
• Zachowaj stary klucz w katalogu aż do daty wygaśnięcia (exp) — pozwala to klientom dokończyć weryfikację żądań podpisanych poprzednim kluczem, których nagłówki TTL jeszcze nie wygasły.
• Usuwaj wygasłe klucze. Operator strony musi również usuwać z cache'a stare klucze, które zniknęły z pliku.

Google testuje Web Bot Auth produkcyjnie — Google-Agent i agent.bot.goog

W oficjalnej dokumentacji Google Crawlers and Fetchers (developers.google.com) firma pisze wprost:

"Web Bot Auth is currently a draft specification developed by the IETF WBA Working Group, and it may change over time. (…) Not all Google user agents are using Web Bot Auth. (…) A subset of requests made by the Google-Agent are signed with Web Bot Auth."

W praktyce oznacza to:

• Google podpisuje część żądań agenta o nazwie Google-Agent — to nowsza klasa agentów hostowanych w infrastrukturze Google, używanych m.in. przez funkcje AI w produktach Google.
• Klucz publiczny tego agenta jest dostępny pod https://agent.bot.goog/.well-known/http-message-signatures-directory.
• Nagłówek wysyłany w żądaniu to Signature-Agent: "https://agent.bot.goog".
• Google zaleca utrzymanie weryfikacji opartej o adres IP jako fallback — bo nie każde żądanie ma jeszcze podpis. Lista adresów IP Google jest publikowana w plikach takich jak special-crawlers.json i googlebot.json.

Z punktu widzenia operatora strony: jeśli widzisz żądanie z User-Agent: Google-Agent i jednocześnie ma ono ważny podpis zgodny z kluczem z agent.bot.goog — masz dziś najmocniejszy możliwy dowód, że to faktycznie ruch z Google. Żaden scraper udający ten ciąg user-agent nie będzie w stanie wygenerować poprawnego podpisu, bo nie ma dostępu do klucza prywatnego.

OpenAI używa Web Bot Auth regularnie — klucz ChatGPT jest publicznie weryfikowalny

OpenAI nie ogłaszało tego z fanfarami, ale Web Bot Auth jest u nich w produkcji dziś, w tej chwili. Możesz to sprawdzić samodzielnie jednym poleceniem:

# Sprawdź własnoręcznie klucz publiczny ChatGPT
curl -s https://chatgpt.com/.well-known/http-message-signatures-directory | jq

# Sprawdź klucz Google Agent
curl -s https://agent.bot.goog/.well-known/http-message-signatures-directory | jq

Pod adresem https://chatgpt.com/.well-known/http-message-signatures-directory serwowany jest publiczny JWKS z kluczem Ed25519 o identyfikatorze otMqcjr17mGyruktGvJU8oojQTSMHlVm7uO-lrcqbdg, oznaczony etykietą "Signature Agent: https://chatgpt.com, Purpose: AI", z okresem ważności sięgającym 2026 roku. To nie jest dokument koncepcyjny — to klucz, którym OpenAI regularnie podpisuje żądania wychodzące z ChatGPT.

Skutek jest istotny dla każdego, kto pisze o ruchu z botów OpenAI. Jeśli widzisz w logach żądanie podszywające się pod ChatGPT-User czy GPTBot i nie niesie ono podpisu z kluczem ChatGPT — masz coraz mocniejszą poszlakę, że to nie jest prawdziwy ruch OpenAI. Im więcej operatorów wdroży Web Bot Auth, tym łatwiej będzie odróżniać autentycznych crawlerów od podszywaczy.

Co to zmienia dla SEO i strategii blokowania crawlerów

Web Bot Auth wpływa na trzy obszary, które dotąd były obarczone niepewnością:

1. Decyzje o blokowaniu crawlerów AI

Jeśli rozważasz blokowanie konkretnych crawlerów AI w robots.txt, dotąd zawsze wisiało nad tym pytanie: "A skąd wiem, że ten ruch to faktycznie GPTBot, a nie scraper?". Web Bot Auth daje twardą odpowiedź. Decyzję o przepuszczeniu lub odrzuceniu możesz oprzeć na zweryfikowanej tożsamości, a nie na samym ciągu user-agent.

2. Pomiar Crawl-to-Referral Ratio

Metryka Crawl-to-Referral Ratio (CRR) tylko wtedy ma sens, gdy potrafisz odróżnić prawdziwe wizyty bota od fałszywych. Liczenie crawli, w których znaczna część "GPTBot" to scrapery, zafałszowuje wskaźnik. Weryfikacja przez Web Bot Auth eliminuje ten szum.

3. Zaufanie do logów serwera vs. Search Console

Logi serwera są jedynym źródłem prawdy o ruchu botów — ale tylko wtedy, gdy masz pewność, kto Cię odwiedza. Web Bot Auth podnosi jakość tych danych do poziomu, na którym można je traktować jak dowód, a nie poszlakę.

Jak zaimplementować weryfikację Web Bot Auth na własnej stronie

Implementacja sprowadza się do trzech rzeczy: parsowanie nagłówków zgodnie z RFC 8941, pobranie i cache'owanie katalogu kluczy oraz weryfikacja podpisu zgodnie z RFC 9421. Dostępne biblioteki to m.in.:

• Node.js / TypeScript: http-message-signatures (npm),
• Python: http-message-signatures (PyPI),
• Rust: http-sig,
• Go: implementacje społecznościowe RFC 9421.

Poniżej uproszczony szkic weryfikacji w Cloudflare Worker — pokazuje całą pętlę bez wchodzenia w detale parsera RFC 8941:

// Cloudflare Worker — uproszczona weryfikacja Web Bot Auth
import { httpbis } from 'http-message-signatures';

const KEY_CACHE = new Map(); // URL → { jwks, fetchedAt }

async function getDirectory(url) {
  const cached = KEY_CACHE.get(url);
  if (cached && Date.now() - cached.fetchedAt < 3_600_000) return cached.jwks;

  const res = await fetch(`${url}/.well-known/http-message-signatures-directory`, {
    headers: { Accept: 'application/http-message-signatures-directory+json' }
  });
  if (!res.ok) throw new Error('directory fetch failed');

  const jwks = await res.json();
  KEY_CACHE.set(url, { jwks, fetchedAt: Date.now() });
  return jwks;
}

export async function verifyBot(request) {
  const agentHeader = request.headers.get('Signature-Agent');
  if (!agentHeader) return { trusted: false, reason: 'no-signature-agent' };

  // Signature-Agent: "https://agent.bot.goog"
  const directoryUrl = agentHeader.replace(/^"|"$/g, '');
  const jwks = await getDirectory(directoryUrl);

  // 1. wyciągnij keyid z Signature-Input
  // 2. znajdź klucz w jwks.keys po kid
  // 3. zweryfikuj podpis zgodnie z RFC 9421
  const result = await httpbis.verifyMessage({
    keyLookup: ({ keyid }) => jwks.keys.find(k => k.kid === keyid),
  }, request);

  return { trusted: result.verified, agent: directoryUrl };
}

Kilka rzeczy, które łatwo przeoczyć przy własnej implementacji:

• Cache katalogu kluczy — bez tego każde podpisane żądanie pociąga za sobą dodatkowe żądanie HTTP do operatora bota, co potrafi zniszczyć latencję.
• Walidacja nbf i exp — i klucza, i samego podpisu. Atak replay polega na powtórzeniu poprawnie podpisanego żądania; bez sprawdzenia ważności podpisu byłby niewykrywalny.
• Walidacja typu MIME odpowiedzi katalogu (application/http-message-signatures-directory+json) — odsiewa przypadkowe zwroty np. strony 404 z JSON-em.
• Tolerancja niezgodności zegarów — uznaj okno ±300 sekund, żeby drobne dryfy NTP nie odrzucały poprawnych podpisów.

Can AI See It — prawdopodobnie jedyne narzędzie monitoringu botów weryfikujące Web Bot Auth

W Can AI See It weryfikujemy ruch crawlerów AI dwutorowo. Dla każdego znanego nam bota — z katalogu 800+ profili — uruchamiamy klasyczne mechanizmy: dopasowanie wzorców user-agent, reverse DNS, sprawdzenie zakresów IP publikowanych przez operatora. Ale tam, gdzie operator opublikował klucz pod /.well-known/http-message-signatures-directory — Google, OpenAI i kolejne firmy w drodze — weryfikujemy również kryptograficzny podpis zgodnie z Web Bot Auth.

Z naszego rozeznania rynkowego, jesteśmy prawdopodobnie jedynym narzędziem monitoringu botów AI, które dziś wspiera pełen łańcuch weryfikacji oparty o RFC 9421 i draft IETF. Większość konkurencyjnych rozwiązań ogranicza się do dopasowania user-agent i list IP — dokładnie tego, czego Web Bot Auth ma zastąpić, bo jest niepełne i niepewne.

Co to oznacza w praktyce dla użytkowników:

• Widzisz, ile żądań od bota OpenAI ma faktyczny podpis, a ile to ruch udający.
• Twoje statystyki crawli z Google-Agent są oczyszczone z hałasu generowanego przez scrapery.
• Twoje decyzje w robots.txt opierają się na zweryfikowanych danych — nie na sygnałach, które każdy może podrobić.

Najczęstsze pytania o Web Bot Auth

Czy Web Bot Auth zastępuje rDNS i listę IP?

Nie zastępuje, uzupełnia. Skoro nie każdy bot podpisuje wszystkie swoje żądania (zarówno Google, jak i OpenAI są na etapie wdrożenia), tradycyjne metody są nadal potrzebne jako fallback. Web Bot Auth jest jednak najmocniejszym dostępnym sygnałem — kryptograficzny dowód tożsamości jest niepodrabialny, w odróżnieniu od nagłówka User-Agent czy zakresu IP.

Jakie algorytmy są wspierane?

Wszystkie algorytmy zarejestrowane w IANA HTTP Signature Algorithms z RFC 9421. W praktyce dominuje Ed25519 (OKP/EdDSA). Używają go zarówno Google, jak i OpenAI. Klucze RSA są dopuszczalne, ale rzadziej spotykane ze względu na rozmiar i wolniejszą weryfikację.

Czy boty muszą podpisywać każde żądanie?

Specyfikacja nie wymaga 100% podpisanego ruchu. Google wprost pisze, że podpisywany jest "subset of requests". To realistyczne — wdrożenie kryptograficzne wymaga zarządzania kluczami, rotacji i zgodności klientów HTTP. Z czasem udział podpisanego ruchu będzie rosnąć.

Jak długo cache'ować katalog kluczy?

Zgodnie z nagłówkami Cache-Control z odpowiedzi serwera. Typowo godziny do dnia. Trzeba jednak usuwać z cache'a klucze, które zniknęły z pliku — sam upływ TTL nie wystarczy, jeśli operator skrócił życie klucza po incydencie.

Czy Web Bot Auth zapobiega atakom replay?

Tak, pod warunkiem prawidłowej implementacji. Każdy podpis zawiera created i expires; serwer musi je sprawdzać. Dodatkowo komponenty podpisane (@authority, @path, @method) wiążą podpis z konkretnym żądaniem — nie da się go skopiować na żądanie do innej ścieżki.

Czy mogę dziś zacząć implementować to na swojej stronie?

Tak. RFC 9421 jest opublikowane, draft katalogu kluczy jest stabilny od kilku wersji, a biblioteki do Node.js, Pythona, Rust i Go są w użyciu produkcyjnym. Na większości platform (Cloudflare Workers, NGINX z OpenResty, middleware Express/Fastify/Django/FastAPI) integracja sprowadza się do kilkudziesięciu linii kodu. Najszybszy start — wpiąć weryfikację do warstwy CDN.

Podsumowanie

Web Bot Auth jest pierwszym mechanizmem, który daje operatorowi strony niepodrabialny dowód tożsamości bota. Zamiast ufać deklaracji w nagłówku User-Agent, weryfikujesz podpis kryptograficzny przeciw kluczowi publicznemu publikowanemu przez operatora. To zmiana jakościowa — z weryfikacji opartej o poszlaki na weryfikację opartą o dowód.

Standard ma jeszcze status draftu, ale Google, OpenAI i Cloudflare już zbudowali na nim produkcyjne wdrożenia. Im więcej operatorów dołączy, tym mniej miejsca dla scraperów udających prawdziwe boty AI. Dla każdego, kto poważnie traktuje wykrywanie ruchu botów i mierzenie wpływu crawlerów AI — Web Bot Auth nie jest opcją "kiedyś w przyszłości". Jest dostępny dziś i już oddziela autentyczny ruch od podszywaczy.