Na stronie internetowej znajduje się formularz logowania. Sprawdzenie, czy podane hasło zgadza się z hasłem zapisanym w bazie danych na serwerze, należy zrealizować
A. skryptem PHP wykonywanym na serwerze.
B. skryptem JavaScript wykonywanym w przeglądarce.
C. atrybutem pattern pola formularza HTML.
D. regułami arkusza stylów CSS.
Sprawdzenie hasła przy logowaniu powinno odbywać się po stronie serwera, czyli np. w skrypcie PHP wykonywanym na serwerze. Wynika to z tego, że tylko serwer ma bezpieczny dostęp do bazy danych z kontami użytkowników i to on powinien decydować, czy dane logowania są poprawne. W praktyce formularz HTML wysyła login i hasło metodą POST do skryptu PHP, a ten pobiera z bazy zapisany skrót hasła i porównuje go z hasłem podanym przez użytkownika, np. przy pomocy funkcji password_verify(). Dobra praktyka mówi, że w bazie nie zapisuje się haseł jawnie, tylko ich bezpieczne hashe, najczęściej tworzone przez password_hash(). Moim zdaniem to jeden z tych tematów, gdzie trzeba od razu myśleć o bezpieczeństwie, a nie tylko o tym, żeby formularz jakoś działał. JavaScript może poprawić wygodę użytkownika, HTML może sprawdzić format danych, ale faktyczna autoryzacja musi być wykonana na serwerze. Dzięki temu użytkownik nie ma dostępu do logiki weryfikacji ani do danych z bazy. To jest zgodne z typowym modelem klient-serwer stosowanym w aplikacjach WWW.
Weryfikowanie hasła w przeglądarce jest bardzo złym pomysłem, nawet jeśli na pierwszy rzut oka wydaje się wygodne. JavaScript działa po stronie klienta, czyli w środowisku kontrolowanym przez użytkownika. Każdy może podejrzeć kod skryptu, zmienić go w narzędziach deweloperskich albo całkiem pominąć jego działanie i wysłać własne żądanie HTTP do serwera. Z tego powodu JavaScript nadaje się co najwyżej do pomocniczej walidacji, na przykład sprawdzenia, czy pole nie jest puste albo czy hasło ma odpowiednią długość. Nie wolno mu powierzać decyzji o zalogowaniu użytkownika. CSS tym bardziej nie służy do przetwarzania danych. Arkusze stylów opisują wygląd elementów strony: kolory, marginesy, układ, czcionki i podobne rzeczy. Nie mają dostępu do bazy danych i nie wykonują logiki uwierzytelniania. Atrybut pattern w HTML też bywa mylący, bo faktycznie może sprawdzić zgodność wpisanej wartości z wyrażeniem regularnym, ale tylko na poziomie formularza. Można nim wymusić np. format kodu pocztowego albo minimalnie uporządkować dane wejściowe, jednak nie sprawdzi on, czy hasło pasuje do konta w bazie. Co ważne, walidację HTML również da się ominąć, choćby przez wyłączenie jej w przeglądarce albo wysłanie żądania narzędziem typu Postman. Typowy błąd myślowy polega tu na pomyleniu walidacji formularza z uwierzytelnianiem. Walidacja pomaga użytkownikowi poprawnie wypełnić formularz, a uwierzytelnianie to już operacja serwerowa, wymagająca dostępu do danych, sesji, zabezpieczeń i bezpiecznego porównania skrótu hasła. Dlatego właściwe miejsce na tę logikę to skrypt wykonywany na serwerze, np. PHP współpracujący z bazą danych.