zgodność formularzy kontaktowych

Zgodność formularzy kontaktowych z przepisami wymaga informowania o zasadach przetwarzania podanych danych.

Zakres zgodności formularza kontaktowego

Zgodność formularza kontaktowego zaczyna się od ustalenia, jakie dane są rzeczywiście potrzebne do obsługi wiadomości. Formularz może zawierać na przykład pole imienia, adresu poczty elektronicznej, numeru telefonu, temat zgłoszenia i opis problemu. Każde pole powinno mieć określony cel techniczny oraz funkcjonalny. Jeżeli serwis odpowiada na zapytanie wyłącznie pocztą elektroniczną, wymaganie numeru telefonu nie wynika automatycznie z samego faktu uruchomienia formularza. Pola niepotrzebne do realizacji tego celu należy usunąć albo oznaczyć jako opcjonalne.

Użytkownik powinien przed wysłaniem wiadomości otrzymać dostęp do informacji o tym, kto odbiera dane, w jakim celu są one wykorzystywane, jak można się skontaktować z administratorem oraz jak długo dane będą przechowywane, jeżeli taki okres został określony. W praktyce formularz umieszcza się obok krótkiej informacji i odnośnika do pełnej polityki prywatności. Samo zdanie „wysyłając formularz, akceptujesz wszystko” nie opisuje precyzyjnie celu przetwarzania i nie zastępuje czytelnej informacji.

Trzeba rozróżnić wysłanie zapytania od zgody na dodatkową komunikację, na przykład newsletter lub kontakt marketingowy. Zgoda na taki dodatkowy cel nie powinna być domyślnie zaznaczona ani ukryta w jednym polu obejmującym kilka niezależnych działań. Formularz powinien również umożliwiać przesłanie wiadomości bez zbierania danych, które nie są potrzebne do odpowiedzi, a komunikaty o polach wymaganych muszą być zrozumiałe dla osoby korzystającej z witryny.

Bezpieczny przepływ danych od przeglądarki do skrzynki

Formularz powinien być dostępny przez HTTPS, a jego adres docelowy nie może przyjmować danych przez niezabezpieczone połączenie HTTP. Połączenie TLS szyfruje transmisję między przeglądarką a serwerem, ale nie szyfruje automatycznie wiadomości po zapisaniu jej w systemie pocztowym. Dlatego operator formularza musi wiedzieć, gdzie dane są zapisywane: w bazie, pliku, panelu administracyjnym, systemie zgłoszeń czy bezpośrednio w skrzynce pocztowej. Warto ograniczyć liczbę kopii, ponieważ każda dodatkowa kopia zwiększa zakres miejsc wymagających kontroli dostępu i retencji.

Walidacja danych powinna odbywać się zarówno w przeglądarce, jak i na serwerze. Atrybuty HTML, takie jak type="email" czy required, poprawiają obsługę formularza, lecz nie stanowią zabezpieczenia, ponieważ klient może je pominąć. Serwer powinien sprawdzać długość pól, kodowanie znaków, format adresu oraz dopuszczalne typy i rozmiary załączników. Treść użytkownika należy traktować jako dane nieufne: nie wolno bezpośrednio wstawiać jej do HTML bez kodowania wyjścia ani wykonywać jej jako polecenia.

Mechanizm wysyłki powinien chronić przed fałszowaniem żądań, automatycznym spamem i wstrzykiwaniem nagłówków pocztowych. Formularze zmieniające stan aplikacji zwykle korzystają z tokena CSRF, który serwer sprawdza przy odbiorze żądania. Przy wysyłce poczty nie należy budować nagłówków na podstawie surowej wartości wpisanej przez użytkownika, szczególnie pola adresu nadawcy. Bezpieczniejszym rozwiązaniem jest stały adres nadawcy skonfigurowany po stronie serwera oraz umieszczenie adresu użytkownika w kontrolowanym polu „Reply-To”, po uprzedniej walidacji.

Logi, retencja i obsługa błędów formularza

Logi aplikacji powinny rejestrować zdarzenia techniczne potrzebne do diagnozy, takie jak czas żądania, identyfikator operacji, kod odpowiedzi HTTP i wynik przekazania wiadomości do kolejnego systemu. Nie należy bez potrzeby zapisywać w logach pełnej treści zgłoszenia, haseł, tokenów, kluczy dostępowych ani całych nagłówków zawierających dane kontaktowe. Jeżeli adres e-mail jest potrzebny do korelacji zdarzeń, można rozważyć ograniczenie zakresu zapisu, na przykład przez identyfikator zgłoszenia albo kontrolowane maskowanie.

Po pomyślnym przekazaniu formularza użytkownik powinien zobaczyć jednoznaczny komunikat, a system nie powinien ponownie wysyłać tej samej wiadomości po odświeżeniu strony. Stosuje się do tego wzorzec POST-Redirect-GET: dane są wysyłane metodą POST, serwer przetwarza żądanie, a następnie przekierowuje przeglądarkę na stronę wyniku. W przypadku błędu serwer powinien odróżnić problem walidacji, brak konfiguracji poczty, przekroczenie limitu i chwilową niedostępność usługi. Komunikat dla użytkownika może być ogólny, natomiast szczegóły techniczne powinny trafić do bezpiecznego logu.

Okres przechowywania wiadomości, załączników, logów i kopii zapasowych powinien być zdefiniowany osobno dla każdego rodzaju danych. Usunięcie wpisu z panelu formularza nie musi oznaczać usunięcia kopii z bazy, skrzynki pocztowej, systemu archiwizacji lub backupu. Kontrola zgodności wymaga więc sprawdzenia całego przepływu, a nie tylko wyglądu strony. Należy również testować uprawnienia: osoba nieuprawniona nie powinna móc odczytać zgłoszeń przez zmieniony identyfikator rekordu, adres API ani niechroniony plik eksportu.

Testy techniczne przed uruchomieniem formularza

Przed wdrożeniem warto sprawdzić formularz na komputerze i urządzeniu mobilnym, z włączoną obsługą oraz bez obsługi skryptów JavaScript. Test powinien obejmować puste pola, zbyt długą treść, nieprawidłowy adres e-mail, znaki specjalne, wielokrotne kliknięcie przycisku, odświeżenie po wysłaniu i próbę bezpośredniego wywołania endpointu. Należy zweryfikować, czy błędy są przypisane do właściwych pól, czy dane nie znikają po zwykłym błędzie walidacji oraz czy formularz nie ujawnia ścieżek plików, stosu wywołań ani konfiguracji serwera.

Ważnym elementem jest kontrola dostępności. Każde pole powinno mieć powiązaną etykietę, kolejność przechodzenia klawiszem Tab powinna być logiczna, a komunikaty błędów powinny być możliwe do odczytania przez technologie asystujące. Pole wyboru dotyczące dodatkowego celu komunikacji nie może być zaznaczone domyślnie. Odnośnik do informacji o przetwarzaniu danych powinien działać przed wysłaniem formularza, a jego treść nie powinna być dostępna wyłącznie po przejściu przez skrypt blokowany przez przeglądarkę.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego podczas diagnostyki stanowiska można również sprawdzić, czy problemy z przeglądarką, certyfikatami TLS, dodatkami blokującymi skrypty albo lokalną konfiguracją poczty nie zakłócają wysłania zgłoszenia. Sama naprawa komputera nie zastępuje jednak przeglądu konfiguracji serwera formularza, uprawnień do skrzynki, logów aplikacji i zasad przechowywania wiadomości. Zgodność należy potwierdzić na podstawie faktycznego działania całego procesu: od wpisania danych, przez transmisję i zapis, aż po dostęp osoby obsługującej zgłoszenie.