Blog

Tips, guides, and privacy advice

← Back to Blog
Wskazówki dla deweloperów

Jak testować przepływy resetowania hasła bez używania prawdziwej skrzynki odbiorczej

7 stycznia 2026·6 min read

Dlaczego testowanie resetowania hasła jest zaniedbywane

Większość deweloperów testuje przepływ resetowania hasła raz na własnym adresie e-mail i uważa sprawę za zakończoną. Po piątym uruchomieniu testu skrzynka odbiorcza jest wypełniona identycznie wyglądającymi wiadomościami "Zresetuj hasło". Tracisz ślad, który link należy do którego uruchomienia, i ostatecznie przestajesz dokładnie testować, bo stało się to zbyt irytujące. Właśnie taki rodzaj niefrasobliwości pozwala poważnym błędom trafić do produkcji.

Co musisz faktycznie testować w przepływie resetowania hasła

Prosta weryfikacja "czy wysyła e-mail?" nie wystarczy. OWASP Authentication Cheat Sheet opisuje kompleksowy zestaw wymagań:

  • Dostarczanie e-maila — czy e-mail resetujący dociera, i szybko?
  • Poprawność linku — czy link prowadzi do właściwej strony z właściwym tokenem?
  • Wygaśnięcie tokena — czy wygasły token jest poprawnie odrzucany po 25 godzinach?
  • Jednorazowe użycie — czy ten sam link resetujący może być użyty dwukrotnie? Nie powinien.
  • Unieważnienie przy nowym żądaniu — czy pierwszy token staje się nieważny, jeśli użytkownik ponownie prosi o reset?
  • Konta SSO — co się dzieje z użytkownikami zarejestrowanymi przez OAuth?
  • Ograniczanie częstotliwości — czy istnieje limit żądań resetowania na adres?

Podejście z tymczasowym e-mailem — krok po kroku

Najczystszym rozwiązaniem jest świeży adres tymczasowego e-maila dla każdego uruchomienia testu. Otwórz tymczasową skrzynkę, skopiuj adres, zarejestruj konto testowe w aplikacji, uruchom reset i obserwuj e-mail przychodzący w czasie rzeczywistym. Kliknij link, zweryfikuj cały przepływ i potwierdź, że logowanie działa. Dla kolejnego scenariusza po prostu otwórz nową kartę przeglądarki.

Nigdy nie wpisuj na stałe testowego adresu e-mail w kodzie. Używaj świeżej skrzynki tymczasowego maila za każdym razem — gwarantuje to testowanie prawdziwego dostarczania i zawsze zaczynasz od czystego stanu.

Lista kontrolna bezpieczeństwa tokenów

Tokeny resetowania hasła to powszechna powierzchnia ataku. Według OWASP, bezpieczna implementacja powinna spełniać:

  • Co najmniej 32 znaki, generowane kryptograficznie losowo
  • Wygasa w ciągu 24 godzin, najlepiej w ciągu 1 godziny
  • Jednorazowe użycie — unieważniane natychmiast po wykorzystaniu
  • Unieważniane przy nowym żądaniu resetu
  • Ograniczone częstotliwością na adres e-mail
  • Nigdy nie logowane w postaci zwykłego tekstu

Uwzględnij resetowanie hasła w zestawie regresji

Resetowanie hasła po cichu psuje się, gdy aktualizowane są biblioteki uwierzytelniania. Dodaj co najmniej podstawowy test end-to-end: utwórz programatycznie konto testowe, uruchom reset, przechwyć wychodzący e-mail i zweryfikuj token. Sprawdź konfigurację uwierzytelniania domeny za pomocą MXToolbox i zajrzyj do Troy Hunta w celu uzyskania dogłębnej perspektywy na temat rzeczywistych naruszeń bezpieczeństwa.