Jak działa ta kontrola
Scanaris analizuje HTML Twojej strony głównej i szuka formularzy zawierających pole <input type="password">: logowanie, rejestrację, zmianę hasła. Jeśli nie ma żadnego, nic nie robi. Jeśli jest, sprawdza dwie rzeczy. Po pierwsze: jeśli sama strona została wysłana przez HTTP, otwiera ustalenie o wysokiej wadze, bo wszystko, co użytkownik wpisze, podróżuje bez szyfrowania. Po drugie: jeśli strona jest HTTPS, ale atrybut action formularza zaczyna się od http://, otwiera kolejne ustalenie o wysokiej wadze z tym adresem, bo samo wysłanie hasła wychodzi niezaszyfrowane, mimo że strona, która o nie prosi, była bezpieczna. Badana jest tylko skanowana strona; jeśli Twoje logowanie mieszka pod inną ścieżką, zeskanuj ją bezpośrednio.
Dlaczego to ważne
Hasło to najcenniejsza rzecz, jaką powierza Ci użytkownik, i to ją połączenia bez szyfrowania traktują najgorzej. Gdy formularz podróżuje przez HTTP, każdy po drodze (wifi w kawiarni, dostawca internetu, przejęty router) czyta login i hasło jak są, bez żadnej techniki. A ponieważ większość ludzi używa tych samych haseł w wielu miejscach, wycieka nie tylko dostęp do Twojej strony. Przeglądarki to wiedzą: Chrome i Firefox oznaczają na czerwono każde pole hasła na stronie HTTP i ostrzegają użytkownika, że „nie jest bezpieczna", więc oprócz realnego ryzyka to widoczna utrata zaufania.
Dlaczego tak się dzieje
Pierwszy przypadek pojawia się, gdy strona nie przekierowuje z HTTP na HTTPS i ktoś wchodzi przez stary link. Drugi to prawie zawsze action wpisany ręcznie podczas rozwoju (http://localhost:3000/login albo http://api.mojadomena.pl/auth), którego nikt nie zmienił, albo formularz skopiowany z przykładu. Zdarza się też, gdy logowanie wskazuje na zewnętrzną usługę, która nie ma jeszcze certyfikatu.
Jak to naprawić
- Serwuj całą stronę przez HTTPS i przekierowuj HTTP. To podstawa wszystkiego innego; kontrola przekierowanie HTTPS mówi Ci, czy ją masz. Na Vercel, Netlify czy Cloudflare jest gotowe; na własnym serwerze blok przekierowania w nginx lub Apache.
- Zmień action na ścieżkę względną (
action="/login"), która dziedziczy protokół strony, albo na pełny adres zhttps://. Jeśli używasz frameworka (Nuxt, Next.js, Laravel, Django), adres API powinien pochodzić ze zmiennej środowiskowej z wartością produkcyjną, a nie być wpisany w szablonie. - Jeśli logowanie obsługuje zewnętrzny dostawca (Auth0, Supabase, Firebase, Clerk), jego endpoint jest już HTTPS; ustalenie wskazuje wtedy na własny
action, który jest tam zbędny. - Dodaj HSTS, żeby przeglądarka nigdy więcej nie próbowała HTTP, nawet przy pierwszym skoku; mierzy to słaby HSTS.
Sprawdź, czy naprawione
curl -sI http://twojadomena.pl/login | grep -iE "^(HTTP|location)"
curl -s https://twojadomena.pl/login | grep -oE '<form[^>]*action="[^"]*"' Pierwsze musi zwrócić 301 na https://. W drugim żaden action nie może zaczynać się od http://; normalnie widać ścieżki względne albo nic (formularze bez action wysyłają na tę samą stronę).
Często zadawane pytania
Mój formularz wysyła przez JavaScript, nie przez action. Czy to mnie dotyczy?
Ta kontrola patrzy na atrybut action, więc formularz robiący fetch nie jest tą drogą oznaczany. Ale ryzyko jest takie samo, jeśli fetch wskazuje na http://: na stronie HTTPS przeglądarka zablokuje go jako mieszaną treść, a na stronie HTTP pójdzie jawnym tekstem. Sprawdź adres API tak czy inaczej.
To tylko środowisko testowe bez prawdziwych użytkowników.
W takim razie nie skanuj go jak produkcji albo zaakceptuj ustalenie. Ale uważaj na środowiska testowe, które trafiają do Google: jeśli ktoś założy tam konto ze swoim zwykłym hasłem, problem jest prawdziwy.
Czy pole hasła na stronie HTTPS z względnym action jest w porządku?
Tak. To poprawna konfiguracja i nie generuje ustalenia. Zostaje sprawdzić, jak potem przechowujesz sesję: niebezpieczne ciasteczka i token w pamięci przeglądarki pokrywają tę część.