CSRF na stronie internetowej: jak zabezpieczyć formularze, panel i koszyk

CSRF nie polega na włamaniu hasłem. Atakujący wykorzystuje fakt, że użytkownik jest już zalogowany i wysyła w jego imieniu żądanie do serwisu. Dlatego problem dotyczy nie tylko banków czy aplikacji SaaS, ale też paneli klienta, formularzy, koszyków, systemów rezerwacji i stron z kontem użytkownika.

Jeżeli endpoint akceptuje zmianę danych tylko dlatego, że przeglądarka dołączyła cookies sesyjne, to brakuje ważnej warstwy kontroli. Dobra ochrona CSRF sprawia, że samo posiadanie sesji nie wystarczy: żądanie musi jeszcze pochodzić z właściwego formularza, właściwej domeny i właściwego kontekstu.

Gdzie CSRF najczęściej robi szkody?

• formularze zmiany hasła, adresu e-mail i danych kontaktowych,
• checkout i koszyk, gdzie można zmienić adres dostawy albo metodę płatności,
• panel administratora CMS lub sklepu,
• formularze zapisu, wypisu i zgód marketingowych,
• endpointy API, które zmieniają stan konta lub zamówienia.

Minimalny zestaw zabezpieczeń

Warstwa	Co robi	Uwaga
Token CSRF	Dodaje unikalny sekret do formularza lub nagłówka.	Token musi być weryfikowany po stronie serwera.
SameSite cookies	Ogranicza wysyłanie cookies w żądaniach z obcych stron.	Ustawienia trzeba dobrać do logowania i płatności.
Origin/Referer check	Sprawdza, czy żądanie pochodzi z właściwej domeny.	To dodatkowa kontrola, nie jedyna ochrona.
POST dla zmian stanu	Nie pozwala zmieniać danych zwykłym linkiem GET.	GET zostaw dla odczytu.
Potwierdzenie działań krytycznych	Wymusza ponowne hasło, 2FA albo wyraźne potwierdzenie.	Przydatne dla płatności i ustawień konta.

Jak sprawdzić istniejącą stronę?

Najpierw wypisz wszystkie formularze i endpointy, które zmieniają dane. Potem sprawdź, czy każde żądanie ma metodę POST/PUT/PATCH/DELETE, token lub nagłówek anty-CSRF, walidację Origin oraz sensowną politykę cookies. Jeżeli formularz działa bez tokenu po skopiowaniu samego żądania, to jest sygnał do poprawki.

W WordPressie i WooCommerce część mechanizmów jest dostępna w core i wtyczkach, ale łatwo ją ominąć przez własny AJAX, niestandardowy formularz albo źle napisany endpoint REST API. W aplikacjach customowych problem często pojawia się przy szybkich panelach administracyjnych i integracjach z CRM.

CSRF a UX

Dobre zabezpieczenia nie muszą psuć doświadczenia użytkownika. Token może działać niewidocznie, a dodatkowe potwierdzenie warto zostawić tylko dla działań wysokiego ryzyka. Najgorsze rozwiązanie to strona, która co chwilę wyrzuca użytkownika z formularza, bo token wygasł bez komunikatu.

Co warto wdrożyć przy przebudowie strony?

• mapę formularzy i endpointów przed startem prac,
• jednolitą obsługę tokenów CSRF w komponentach formularzy,
• testy dla krytycznych akcji w panelu i koszyku,
• politykę cookies z `SameSite=Lax` lub mocniejszą tam, gdzie to możliwe,
• logowanie nietypowych prób zmiany danych.

Jeżeli strona generuje leady albo przyjmuje płatności, CSRF powinien być częścią normalnego technicznego odbioru serwisu. To nie jest dodatki „na później”, tylko podstawowa higiena formularzy i paneli użytkownika.