Jak działa ocena reCAPTCHA v3: niewidoczny silnik ryzyka i legitymacyjna automatyzacja w 2026

Jak działa ocena reCAPTCHA v3: podstawy silnika ryzyka

reCAPTCHA v3, wprowadzona przez Google w 2018 roku, odeszła od widocznych wyzwań („wybierz sygnalizację świetlną”) na rzecz niewidocznego silnika oceny ryzyka. Zamiast przerywać sesję użytkownika, system zwraca ciągły wynik od 0.0 do 1.0 dla każdej akcji wywołanej przez grecaptcha.execute(). Wynik bliski 1.0 oznacza ruch prawdopodobnie ludzki; bliski 0.0 — prawdopodobnie zautomatyzowany. To, jak działa ocena reCAPTCHA v3, sprowadza się do fuzji kilkunastu sygnałów w jeden liczbowy werdykt, który właściciel strony interpretuje według własnych progów.

W 2026 roku większość witryn e-commerce, finansowych i SaaS stosuje reCAPTCHA v3 jako pierwszą linię obrony, często łączoną z reCAPTCHA Enterprise dla dodatkowych sygnałów WAF. Dla inżynierów QA, badaczy anti-bot i zespołów automatyzacji zrozumienie tego mechanizmu jest warunkiem koniecznym — nie po to, aby oszukiwać system, ale aby legitymacyjny ruch testowy nie był blokowany przez fałszywe alarmy.

Wynik recaptcha v3 score nie jest binarny. Google grupuje go w jedenaście koszyków: 0.0, 0.1, 0.2, …, 0.9, 1.0. Typowe progi decyzyjne po stronie serwera to:

• Blokada — wynik < 0.3 (lub < 0.1 w trybie restrykcyjnym).
• Wyzwanie fallback — wynik 0.3–0.6 (wymaga reCAPTCHA v2, arkusza zadań lub weryfikacji SMS).
• Przepuszczenie — wynik > 0.6 (często > 0.8 dla operacji wysokiego ryzyka, np. reset hasła).

Te progi są konfigurowalne w konsoli Google reCAPTCHA Admin. Wartość recaptcha score 0.3 jest powszechnie cytowaną granicą, ponieważ Google w swojej dokumentacji sugeruje 0.5 jako punkt odniesienia, ale w praktyce większość witryn obniża próg blokady do 0.3, aby zredukować fałszywie pozytywne.

Kluczowa intuicja: reCAPTCHA v3 nie próbuje dowieść, że jesteś człowiekiem. Próbuje oszacować prawdopodobieństwo, że zachowujesz się jak człowiek w kontekście tego IP, tej przeglądarki i tej historii sesji. Każdy z tych komponentów może samodzielnie zepchnąć wynik poniżej progu.

Dlaczego ten problem istnieje: kontekst techniczny

Klasyczne CAPTCHA (tekstowe, obrazkowe) polegały na zadaniu, którego maszyna nie potrafi rozwiązać, a człowiek tak. To podejście zawiodło z trzech powodów:

1. Dostępność — użytkownicy z niepełnosprawnościami wzrokowymi nie mogli rozwiązać wizualnych wyzwań, co naruszało WCAG 2.1 i narażało witryny na skargi ADA.
2. AI rozwiązuje CAPTCHA — modele wizyjne osiągają >95% skuteczności na klasycznych obrazkach reCAPTCHA v2.
3. Tarcie użytkownika — każde wyzwanie to utrata konwersji. Google podawał, że reCAPTCHA v3 redukuje liczbę wyzwań o >90% w porównaniu do v2.

Stąd przesunięcie ku modelowi passive risk scoring. Zamiast pytać „rozwiąż to”, system pyta „jak prawdopodobne, że ta sesja jest zautomatyzowana, biorąc pod uwagę wszystko, co widziałem”. To jest fundamentalnie problem klasyfikacji anomalii zasilany sygnałami klienta, sygnałami sieciowymi i sygnałami grafu tożsamości.

Problem dla legitymacyjnej automatyzacji polega na tym, że sygnały sieciowe — w szczególności reputacja IP — są dyskryminujące z definicji. Ruch z adresów datacenter, znanych farm proxy i węzłów Tor otrzymuje z góry niski wynik, zanim jakikolwiek sygnał behawioralny zostanie oceniony. To zmusza zespoły QA do korzystania z infrastruktury proxy, która „wygląda” jak ruch konsumencki — czyli proxy rezydencyjne.

Sygnały, które Google fuzjonuje

Google nie publikuje pełnej listy sygnałów ani wag modelu, ale inżynieria odwrotna, dokumentacja Enterprise i prezentacje zespołu Trust & Safety pozwalają zrekonstruować główne kategorie. Dokumentacja Google Cloud opisuje reCAPTCHA Enterprise jako system analizujący ponad 100 sygnałów w czasie rzeczywistym.

Sygnały behawioralne

• Czas trwania sesji — jak długo użytkownik był na stronie przed akcją.
• Timing myszy i scrolla — rozkład odstępów między zdarzeniami mousemove, scroll, keydown. Ludzkie ruchy mają rozkład zbliżony do log-normalnego; skrypty generują rozkład równomierny lub brak zdarzeń.
• Telemetria interakcji — liczba kliknięć, zmiany fokusu, zdarzenia blur/focus, ruchy dotykowe na mobile.
• Wzorce wpisywania — czas między naciśnięciami klawiszy, poprawki, użycie autouzupełniania.

Sygnały przeglądarki i urządzenia

• User-Agent i nagłówki — spójność nagłówków z deklarowaną przeglądarką.
• Canvas fingerprint — hash z renderowania canvas, różny między przeglądarkami i systemami.
• WebGL renderer — ciąg znaków identyfikujący kartę graficzną.
• AudioContext fingerprint — różnice w przetwarzaniu audio.
• TLS fingerprint (JA3/JA4) — kolejność szyfrów i rozszerzeń TLS. Headless Chrome ma inny JA3 niż Chrome desktop, co jest sygnałem automatyzacji. Więcej o kryptografii w przeglądarkach znajdziesz w MDN.
• Obecność webdriver — navigator.webdriver === true, brak window.chrome, brak wtyczek.

Sygnały sieciowe i reputacji

• Reputacja IP — czy adres figuruje na listach abuse (Spamhaus, AbuseIPDB), czy jest oznaczony jako datacenter/VPN/proxy.
• ASN — ruch z ASN znanych dostawców chmurowych (AWS, DigitalOcean, Hetzner) otrzymuje zaniżony wynik.
• Geografia — zgodność geolokalizacji IP z deklarowanym językiem i strefą czasową przeglądarki.
• Historia IP — czy z tego adresu wcześniej widziano zautomatyzowany ruch.

Graf ciasteczek Google

To najbardziej niedoceniany sygnał. Jeśli użytkownik jest zalogowany do konta Google lub ma ciasteczko NID/SID z historią aktywności, reCAPTCHA v3 może skorelować sesję z profilem. Konto z wieloletnią historią legalnej aktywności podnosi wynik; nowa sesja bez historii — obniża. To wyjaśnia, dlaczego świeże profile incognito otrzymują często wynik 0.1–0.4 nawet przy perfekcyjnym zachowaniu.

Dlaczego datacenter i oflagowane IP załamują wynik

Niezależnie od tego, jak perfekcyjny jest twój fingerprint TLS, jak ludzki jest timing myszy i jak bogata jest historia ciasteczek — jeden sygnał może zepchnąć wynik poniżej progu. W praktyce tym sygnałem jest najczęściej reputacja IP.

Mechanizm jest brutalnie prosty: Google utrzymuje reputacyjną bazę ASN i podsieci. Jeśli twój ruch pochodzi z ASN oznaczonego jako hosting/cloud, model nakłada karę. W testach branżowych ruch z typowych datacenter proxies otrzymuje recaptcha v3 score w zakresie 0.1–0.3, nawet gdy przeglądarka i zachowanie są idealne. Ruch z adresów rezydencyjnych — przypisanych do ISP konsumenckich — otrzymuje 0.5–0.9 przy tym samym zachowaniu.

Wniosek: aby recaptcha v3 bypass w sensie legitymacyjnym — czyli aby testowy ruch QA nie był blokowany — musisz usunąć komponent kary za reputację IP. Proxy rezydencyjne ProxyHat rozwiążą ten problem, ponieważ ruch wychodzi z adresów przypisanych do konsumenckich ISP, a nie do dostawców chmurowych. Sprawdź dostępne lokalizacje ProxyHat, aby dopasować geografię do docelowej witryny.

Weryfikacja tokena po stronie serwera: siteverify

Po stronie klienta grecaptcha.execute() zwraca token (ciąg ~400 znaków). Frontend wysyła ten token do backendu, a backend wywołuje endpoint siteverify:

POST https://www.google.com/recaptcha/api/siteverify
Content-Type: application/x-www-form-urlencoded

secret=YOUR_SECRET_KEY&response=TOKEN_FROM_CLIENT&remoteip=USER_IP

Odpowiedź zawiera:

{
  "success": true,
  "score": 0.7,
  "action": "login",
  "challenge_ts": "2026-01-15T12:00:00Z",
  "hostname": "example.com",
  "error-codes": []
}

Dwa pola wymagają szczególnej uwagi:

1. Dopasowanie akcji

Pole action musi dokładnie odpowiadać akcji zadeklarowanej w grecaptcha.execute(siteKey, {action: 'login'}). Jeśli frontend wysyła action: 'login', a backend oczekuje 'signin', token zostaje odrzucony. To chroni przed atakami typu „token harvesting”, gdzie atakujący zbiera tokeny z akcji o niskim progu (np. homepage) i używa ich do akcji o wysokim progu (np. withdraw).

2. Dopasowanie hostname

Pole hostname musi odpowiadać domenie, na której wygenerowano token. Jeśli token z example.com jest wysyłany z backendu obsługuje api.example.com, Google odrzuci weryfikację (chyba że skonfigurowano wildcard). To zapobiega przenoszeniu tokenów między domenami.

Te dwa mechanizmy oznaczają, że nie można zrezygnować z renderowania reCAPTCHA na docelowej stronie. Każde podejście „legitymacyjnego przejścia” musi obejmować realną przeglądarkę ładującą realną stronę z realnym kluczem witryny.

Praktyczne podejście: ProxyHat + realna przeglądarka

Oto legitymacyjny scenariusz: zespół QA musi uruchomić testy E2E na stronie e-commerce chronionej reCAPTCHA v3. Testy używają Playwright z prawdziwym Chromium (nie headless), ProxyHat residential proxy z geotargetingiem US oraz opóźnień symulujących zachowanie człowieka.

Krok 1: Konfiguracja proxy ProxyHat

Użyj bramy HTTP ProxyHat z geotargetingiem kraju:

http://user-country-US:YOUR_PASSWORD@gate.proxyhat.com:8080

Dla sesji sticky (przydatne, gdy test wymaga utrzymania tej samej tożsamości IP przez wiele żądań):

http://user-country-US-session-qa01:YOUR_PASSWORD@gate.proxyhat.com:8080

Szczegóły konfiguracji znajdziesz w dokumentacji ProxyHat.

Krok 2: Skrypt Python z Playwright

from playwright.sync_api import sync_playwright
import time, random

PROXY = "http://user-country-US:YOUR_PASSWORD@gate.proxyhat.com:8080"
SITE_URL = "https://example.com/login"

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,  # real browser, nie headless
        proxy={"server": PROXY},
        args=[
            "--disable-blink-features=AutomationControlled",
            "--no-sandbox",
        ]
    )
    context = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                   "AppleWebKit/537.36 (KHTML, like Gecko) "
                   "Chrome/120.0.0.0 Safari/537.36",
        viewport={"width": 1920, "height": 1080},
        locale="en-US",
        timezone_id="America/New_York",
    )
    page = context.new_page()

    # 1. Załaduj stronę i odczekaj (symuluj czytanie)
    page.goto(SITE_URL, wait_until="networkidle")
    time.sleep(random.uniform(2.0, 4.0))

    # 2. Symuluj ruchy myszy przed interakcją
    for _ in range(random.randint(3, 7)):
        page.mouse.move(
            random.randint(100, 1800),
            random.randint(100, 900),
            steps=random.randint(5, 15)
        )
        time.sleep(random.uniform(0.2, 0.8))

    # 3. Wypełnij formularz z naturalnym opóźnieniem
    page.fill("#email", "qa-test@example.com", delay=random.randint(50, 120))
    time.sleep(random.uniform(0.5, 1.5))
    page.fill("#password", "test-password", delay=random.randint(50, 120))
    time.sleep(random.uniform(0.5, 1.5))

    # 4. Kliknij przycisk logowania
    page.click("#login-button")

    # 5. Poczekaj na wynik
    page.wait_for_load_state("networkidle")
    print(f"Tytuł strony po logowaniu: {page.title()}")
    browser.close()

Ten skrypt celowo używa headless=False, ponieważ headless Chrome ma inny JA3/JA4 fingerprint i wykrywalny brak window.chrome. Opóźnienia delay w page.fill() symulują ludzkie tempo wpisywania (50–120 ms między znakami, co odpowiada badaniom ergonomii klawiatury). Ruchy myszy przed interakcją dostarczają telemetrii, której reCAPTCHA v3 oczekuje od prawdziwego użytkownika.

Krok 3: Monitorowanie wyniku

W konsoli Google reCAPTCHA Admin możesz obserwować rozkład wyników w czasie rzeczywistym. Jeśli twoje testy QA generują wyniki < 0.3, oznacza to, że któryś sygnał jest flagowany — najczęściej IP lub fingerprint. Diagnostyka:

• Wynik 0.1–0.2 z datacenter IP → przejdź na ProxyHat residential.
• Wynik 0.3–0.5 z residential IP, ale headless → przełącz na headless=False lub użyj playwright-stealth.
• Wynik 0.5–0.7 z residential + real browser → dodaj ruchy myszy i opóźnienia.
• Wynik 0.7–0.9 → legitymacyjny ruch testowy powinien przejść.

Najczęstsze błędy i przypadki brzegowe

Błąd 1: Użycie headless Chrome bez modyfikacji

Headless Chrome ustawia navigator.webdriver = true i ma inny fingerprint TLS niż Chrome desktop. reCAPTCHA v3 wykrywa to natychmiast. Rozwiązanie: użyj headless=False lub rozważ headless: 'new' w Chrome 112+, który częściowo łagodzi ten problem, ale nadal nie jest idealny.

Błąd 2: Rotacja IP na każde żądanie

Niektóre proxy rotacyjne zmieniają IP na każde żądanie HTTP. reCAPTCHA v3 kumuluje sygnały w ramach sesji; jeśli IP zmienia się mid-session, model traktuje to jako anomalię. Używaj sesji sticky (flaga session- w ProxyHat), aby utrzymać to samo IP przez całą sesję testową.

Błąd 3: Brak interakcji przed akcją

Skrypt, który ładuje stronę i natychmiast klika „Zaloguj”, generuje brak telemetrii behawioralnej. reCAPTCHA v3 interpretuje to jako automatyzację. Dodaj 2–5 sekund losowego ruchu myszy i scrolla przed akcją.

Błąd 4: Niezgodność timezone i geolokalizacji

Jeśli ProxyHat geotargeting ustawia IP w USA, ale timezone_id w Playwright jest ustawione na Europe/Warsaw, reCAPTCHA v3 flaguje niezgodność. Ustaw timezone zgodnie z geolokalizacją IP.

Błąd 5: Ponowne użycie tokenów

Token reCAPTCHA v3 jest jednorazowy i wygasa po ~2 minutach. Nie buforuj tokenów ani nie używaj ich ponownie. Każda akcja wymaga świeżego grecaptcha.execute().

Kiedy to jest odpowiednie — a kiedy nie

Ten przewodnik jest skierowany do legitymacyjnych przypadków użycia:

• Testy QA i E2E — weryfikacja, że twoja własna aplikacja poprawnie integruje reCAPTCHA v3 i że legitymacyjni użytkownicy nie są blokowani.
• Badania anti-bot — analizowanie mechanizmów detekcji w celu ich ulepszenia (red teaming własnej infrastruktury).
• Automatyzacja dostępności — testowanie zgodności WCAG dla użytkowników korzystających z czytników ekranu, którzy nie mogą rozwiązać wizualnych CAPTCHA.
• Monitorowanie własnych usług — scraping cen lub dostępności własnych produktów na platformach partnerskich.

To NIE jest odpowiednie dla:

• Tworzenia kont na masową skalę (account farming).
• Obejścia zabezpieczeń cudzych witryn bez autoryzacji.
• Kupowania ograniczonych produktów (sneaker bots, ticket bots) w sposób naruszający ToS.
• Spamowania formularzami cudzych witryn.

W Stanach Zjednoczonych Computer Fraud and Abuse Act (CFAA) karanie nieautoryzowany dostęp do systemów komputerowych, w tym omijanie mechanizmów kontroli dostępu. W UE RODO (GDPR) ogranicza przetwarzanie danych osobowych, w tym adresów IP. Przed każdą automatyzacją cudzej witryny upewnij się, że masz autoryzację właściciela lub działasz w ramach wyraźnie dozwolonego przypadku (np. testowanie własnej usługi).

Dla autoryzowanego scrapowania własnych danych lub danych publicznych, ProxyHat oferuje proxy do web scrapingu oraz SERP tracking. Cennik znajdziesz na stronie ProxyHat pricing.

Kluczowe wnioski

1. reCAPTCHA v3 to klasyfikator prawdopodobieństwa, nie bramka tak/nie. Wynik 0.0–1.0 jest ciągły i interpretowany przez progi po stronie serwera. Typowa blokada: <0.3; przepuszczenie: >0.6.

2. Reputacja IP jest sygnałem dyskryminującym. Datacenter i oflagowane VPN otrzymują karę niezależnie od zachowania. Proxy rezydencyjne są warunkiem koniecznym, aby legitymacyjny ruch testowy otrzymał wynik powyżej progu.

3. Fingerprint przeglądarki ma znaczenie. Headless Chrome, niezgodności TLS JA3/JA4, brak window.chrome i navigator.webdriver === true to natychmiastowe flagi. Używaj realnej przeglądarki lub narzędzi stealth.

4. Zachowanie jest sygnałem, ale nie jedynym. Timing myszy, scrolla i wpisywania musi być zbliżony do ludzkiego (log-normalny rozkład odstępów, 50–120 ms między znakami).

5. Tokeny są jednorazowe i związane z akcją oraz hostname. Nie buforuj, nie przenoś między domenami i zawsze weryfikuj action oraz hostname po stronie serwera.

6. Używaj tylko w legitymacyjnych celach. Autoryzowane testy QA, badania anti-bot i automatyzacja dostępności. Nigdy fraud, account abuse ani nieautoryzowane omijanie zabezpieczeń cudzych witryn.

FAQ: Jak działa ocena reCAPTCHA v3

Czym jest ocena reCAPTCHA v3 i jak działa?

reCAPTCHA v3 to niewidoczny system oceny ryzyka, który zwraca ciągły wynik od 0.0 do 1.0 dla każdej akcji wywołanej przez grecaptcha.execute(). Google fuzjonuje sygnały behawioralne (timing myszy, interakcje), sygnały przeglądarki (TLS fingerprint, canvas, WebGL), sygnały sieciowe (reputacja IP, ASN) oraz graf ciasteczek Google w jeden liczbowy werdykt. Witryna interpretuje wynik według własnych progów — typowo blokada poniżej 0.3, wyzwanie 0.3–0.6, przepuszczenie powyżej 0.6.

Dlaczego ocena reCAPTCHA v3 ma znaczenie dla użytkowników proxy?

Reputacja IP jest jednym z najsilniejszych sygnałów w modelu reCAPTCHA v3. Ruch z adresów datacenter, VPN i znanych farm proxy otrzymuje zaniżony wynik (często 0.1–0.3) niezależnie od jakości zachowania i fingerprintu przeglądarki. To oznacza, że legitymacyjny ruch testowy QA lub badawczy może być blokowany, jeśli korzysta z niewłaściwego typu proxy. Proxy rezydencyjne i mobile, przypisane do konsumenckich ISP, usuwają tę karę i pozwalają na osiągnięcie wyniku powyżej progu.

Który typ proxy najlepiej współpracuje z reCAPTCHA v3?

Proxy rezydencyjne z sesją sticky są optymalne dla większości legitymacyjnych przypadków użycia. Adresy rezydencyjne są przypisane do konsumenckich ISP, więc nie otrzymują kary za reputację IP. Sesja sticky utrzymuje to samo IP przez całą sesję testową, co zapobiega flagowaniu anomalii „zmiana IP mid-session”. Proxy mobile (4G/5G) dają jeszcze wyższe wyniki (0.7–0.9), ale są droższe. Proxy datacenter są nieodpowiednie — wynik zazwyczaj poniżej 0.3.

Jak unikać blokad przy implementacji testów z reCAPTCHA v3?

Używaj realnej przeglądarki (nie headless bez modyfikacji), proxy rezydencyjnego z geotargetingiem zgodnym z timezone przeglądarki, dodaj ruchy myszy i opóźnienia przed akcją (2–5 sekund), symuluj ludzkie tempo wpisywania (50–120 ms między znakami) i utrzymuj sesję sticky na proxy. Nigdy nie buforuj tokenów (są jednorazowe, wygasają po ~2 minutach) i zawsze weryfikuj zgodność action oraz hostname po stronie serwera.

Czy omijanie reCAPTCHA v3 jest legalne?

Omijanie zabezpieczeń cudzych witryn bez autoryzacji może naruszać CFAA w USA i przepisy o nieuczciwej konkurencji w UE. Legitymacyjne przypadki obejmują: testowanie własnej aplikacji, autoryzowane badania anti-bot (red teaming), automatyzację dostępności dla użytkowników z niepełnosprawnościami oraz monitorowanie własnych usług. Zawsze uzyskaj autoryzację właściciela witryny lub działaj w ramach wyraźnie dozwolonego przypadku.