Ochrona przed CSRF w konfiguracjach React i API

Cross-Site Request Forgery (CSRF), czyli fałszowanie żądań między witrynami, to atak, w którym złośliwa witryna nakłania przeglądarkę użytkownika do wysłania uwierzytelnionego żądania do Państwa API. Ponieważ przeglądarka automatycznie dołącza pliki cookie do żądań, serwer nie może odróżnić prawidłowego żądania z Państwa aplikacji od sfałszowanego żądania ze strony atakującego.

Pliki cookie są główną przyczyną podatności na CSRF. Gdy użytkownik jest zalogowany do aplikacji, jego plik cookie sesji jest przechowywany w przeglądarce. Gdy użytkownik odwiedzi stronę atakującego, atakujący może wywołać wysłanie formularza lub żądanie fetch do Państwa API, a przeglądarka automatycznie dołączy plik cookie sesji, uwierzytelniając złośliwe żądanie.

Atrybut pliku cookie SameSite informuje przeglądarki, kiedy dołączać pliki cookie do żądań między witrynami. Ma trzy wartości: Lax (domyślna w nowoczesnych przeglądarkach — blokuje żądania POST między witrynami, ale zezwala na żądania GET), Strict (blokuje wszystkie żądania między witrynami, w tym nawigację GET) oraz None (zezwala na żądania między witrynami, ale wymaga HTTPS i flagi Secure).

SameSite=Lax blokuje żądania między witrynami typu POST, PUT, DELETE i PATCH — czyli metody używane do modyfikacji danych. Jeśli Państwa API używa GET wyłącznie do odczytu, a POST do wszystkich modyfikacji, SameSite=Lax skutecznie zapobiega CSRF w aplikacjach SPA w nowoczesnych przeglądarkach. To podstawowe zabezpieczenie, na którym opiera się dziś większość aplikacji.

Wzorzec Double Submit Cookie to zabezpieczenie przed CSRF, w którym serwer ustawia losowy token CSRF w pliku cookie bez flagi HttpOnly. Klient odczytuje wartość tego pliku cookie i dołącza ją jako niestandardowy nagłówek żądania, na przykład X-CSRF-Token. Serwer sprawdza, czy wartość nagłówka odpowiada wartości pliku cookie. Atakujący nie może odczytać pliku cookie z innego źródła, więc nie może ustawić prawidłowego nagłówka.

Wzorzec Synchronizer Token generuje na serwerze unikatowy token CSRF dla każdej sesji użytkownika. W przypadku formularzy HTML token jest umieszczany w ukrytym polu. W przypadku wywołań API aplikacji SPA token jest udostępniany za pośrednictwem punktu końcowego lub znacznika meta i wysyłany w niestandardowym nagłówku. Serwer sprawdza token przy każdym żądaniu zmieniającym stan.

Aplikacja SPA w React, która przechowuje JWT w pamięci lub w localStorage i wysyła go w nagłówku Authorization: Bearer, nie jest podatna na klasyczny CSRF. Ataki CSRF wykorzystują uwierzytelnianie oparte na plikach cookie — strona atakującego nie może ustawiać niestandardowych nagłówków w żądaniach między źródłami z powodu ograniczeń CORS, więc nie może sfałszować nagłówka Authorization.

Proste żądania między źródłami (wysłanie formularza POST, załadowanie obrazu) nie pozwalają na używanie niestandardowych nagłówków. Tylko żądania przechodzące wstępną kontrolę CORS mogą zawierać niestandardowe nagłówki — a takie żądania wymagają wyraźnej zgody serwera. API, które wymaga niestandardowego nagłówka, takiego jak X-Requested-With: XMLHttpRequest, dla wszystkich operacji zmieniających dane jest z natury chronione przed prostymi atakami CSRF.

CORS kontroluje, które originy mogą odczytać odpowiedź na żądanie między originami. CSRF dotyczy tego, które originy mogą wysyłać żądania zmieniające stan. Konfiguracja CORS w celu ograniczenia originów nie zapobiega CSRF — przeglądarka nadal wysyła żądanie i cookie, a CORS kontroluje tylko to, czy odpowiedź jest widoczna dla kodu JavaScript. Atak CSRF nie wymaga odczytania odpowiedzi.

Session cookie należy skonfigurować z użyciem: HttpOnly: true (uniemożliwia kodowi JavaScript odczytanie cookie, blokując kradzież tokenu za pomocą XSS), Secure: true (cookie jest wysyłane wyłącznie przez HTTPS), SameSite: Lax lub Strict (zapobiega CSRF) oraz odpowiedniej wartości Max-Age lub daty wygaśnięcia. Te cztery atrybuty razem znacząco zwiększają bezpieczeństwo zarządzania sesją.

Next.js App Router używa Server Actions, które są żądaniami POST. Next.js implementuje ochronę przed CSRF, porównując nagłówek Origin z hostem — żądania z nieoczekiwanych originów są odrzucane. To wbudowane sprawdzanie w połączeniu z cookie sesji SameSite=Lax zapewnia solidną ochronę przed CSRF w przypadku mutacji opartych na Server Actions.

Jaka wartość cookie SameSite blokuje żądania POST między witrynami, ale zezwala na nawigację GET między witrynami?

CSRF wykorzystuje uwierzytelnianie oparte na cookie, nakłaniając przeglądarkę do wysyłania uwierzytelnionych żądań między witrynami. SameSite=Lax to podstawowa ochrona we współczesnych przeglądarkach. Wzorce Double Submit Cookie i Synchronizer Token zapewniają dodatkową ochronę. React SPA używające JWT w nagłówkach Authorization są z natury odporne na CSRF. Wymagane niestandardowe nagłówki i wstępne żądania CORS również ograniczają ryzyko CSRF. W przypadku cookie sesji należy zawsze łączyć HttpOnly + Secure + SameSite.