Czym jest CSRF (Cross-Site Request Forgery)?

Ataki CSRF to jedno z klasycznych, a zarazem najbardziej niedocenianych zagrożeń w aplikacjach webowych. Ich istota polega na tym, że przeglądarka użytkownika, działając zgodnie ze specyfikacją i zapamiętanymi danymi uwierzytelniającymi, może wysłać do zaufanego serwisu żądanie, którego użytkownik wcale nie chciał zainicjować. Definicja jest prosta, ale konsekwencje bywają poważne: nieautoryzowane przelewy, zmiany adresu e‑mail, reset haseł, publikacje treści w imieniu ofiary czy modyfikacje ustawień bezpieczeństwa. To ataki szczególnie podstępne, bo często nie wymagają żadnego złośliwego kodu po stronie serwera ofiary – wykorzystują standardowe mechanizmy przeglądarki i protokołu HTTP. Dla twórców stron www jest to temat fundamentalny: zrozumienie warunków, w jakich przeglądarka dołącza dane logowania do żądania oraz poznanie uznanych wzorców obrony decyduje o praktycznej odporności serwisu na nadużycia.

Istota i definicja CSRF

CSRF (Cross‑Site Request Forgery) to atak, w którym napastnik skłania przeglądarkę zalogowanego użytkownika do wysłania żądania HTTP do legalnej aplikacji w taki sposób, aby ta uznała je za pochodzące od użytkownika i z jego intencją. Aby atak się powiódł, przeglądarka musi automatycznie dołączyć do żądania kontekst uwierzytelnienia: najczęściej cookie sesyjne, czasem nagłówki uwierzytelniające, rzadziej dane klienta w pamięci przeglądarki. Krytyczne jest to, że ofiara jest już zalogowana i ma aktywny kontekst po stronie serwera, przez co żądanie wygląda na autentyczne.

W praktyce napastnik przygotowuje treść w innym pochodzeniu niż zaufany serwis: może to być strona kontrolowana przez niego lub zainfekowana reklama osadzona na neutralnym portalu. Użytkownik ją odwiedza, a następnie – często bez klikania – zostaje wyzwolone żądanie skierowane do celu: przelew, zmiana hasła, dodanie klucza API. Pomyślne wykonanie zależy od wielu czynników: czy serwis akceptuje takie żądania metodą GET lub POST, czy zainstalowano skuteczne zabezpieczenia, czy przeglądarka dołączyła właściwe dane uwierzytelniające.

W definicji słownikowej warto wyraźnie podkreślić różnicę między podszywaniem się a odpowiedzialnością po stronie przeglądarki. Atak nie polega na przełamaniu haseł ani złamaniu kryptografii. To nakłonienie zgodnego z normą klienta do wykonania poprawnego z punktu widzenia protokołu żądania, którego użytkownik nie zainicjował świadomie. Dlatego wykrywanie i neutralizacja CSRF muszą być zaprojektowane jako element logiki serwera, który sprawdza zamiar i pochodzenie żądania zamiast polegać wyłącznie na uwierzytelnieniu użytkownika.

W kontekście słownikowym termin ten bywa również nazywany „atakiem polegającym na fałszowaniu żądań pomiędzy witrynami”. Jest to dosłowne tłumaczenie, ale warto pamiętać, że kluczową rolę odgrywa tu środowisko przeglądarki i automatyczne zarządzanie kontekstem użytkownika, a nie sama komunikacja pomiędzy domenami. Z tego względu metody obrony w przeważającej mierze opierają się na sprawdzeniu cech żądania, które nie są automatycznie dostępne dla strony trzeciej inicjującej atak, oraz na ograniczeniu automatycznego dołączania kontekstu przez przeglądarkę.

Termin CSRF zyskał trwałe miejsce w kanonie OWASP i audytów bezpieczeństwa. Klasyfikowany jest jako problem integralności żądania, w odróżnieniu od XSS (tam chodzi o integralność treści). Występuje w aplikacjach monolitycznych i SPA, w panelach administracyjnych, w systemach płatności, interfejsach API i wszędzie tam, gdzie serwer wnioskuje o tożsamości z danych sesyjnych i przyznaje uprawnienia do działań zmieniających stan.

Jak działa atak: wektory, scenariusze i warunki powodzenia

Klasyczny scenariusz: użytkownik jest zalogowany do banku w zakładce przeglądarki. W innej zakładce odwiedza stronę kontrolowaną przez napastnika. Ta strona zawiera ukryty element, który składa żądanie do banku, np. ukryty formularz z polami odbiorcy i kwoty, który samoczynnie wysyła się metodą POST. Przeglądarka, działając poprawnie, dołącza cookie sesyjne banku do tego żądania, przez co serwer je akceptuje i wykonuje operację, jeśli nie ma dodatkowych zabezpieczeń.

Wektory ataku są różnorodne: od prostych obrazków z parametrami w URL (wywołują żądanie GET), przez osadzone ramki iframe i auto‑submit formularzy, po requests wywołane przez skrypty działające w kontekście atakującej strony (np. linki z atrybutem ping lub mechanizmy nawigacyjne). Choć nowoczesne przeglądarki ograniczają niektóre metody, wiele prostych dróg pozostaje otwartych, zwłaszcza jeśli serwis wykonuje operacje zmieniające stan przy użyciu żądań GET lub dopuszcza POST bez dodatkowych walidacji.

Warto rozróżnić dwa istotne przypadki: operacje idempotentne i nieidempotentne. W dobrze zaprojektowanych aplikacjach zmiany stanu są wykonywane metodami POST/PUT/PATCH/DELETE, a żądania GET nie mają skutków ubocznych. Jednak historia sieci pokazuje, że wiele usług nie przestrzegało tej zasady, co umożliwiało ataki CSRF za pomocą zwykłego osadzenia obrazka z odpowiednio sparametryzowanym adresem. Nawet gdy zmiany stanu są przypisane do POST, wciąż wystarczy niewielka domieszka JavaScriptu lub mechanizmu auto‑submit, aby przeglądarka wysłała żądanie bez udziału świadomego działania użytkownika.

Szczególne miejsce zajmuje tzw. login CSRF, czyli wymuszenie zalogowania ofiary do cudzego konta. Nie jest to od razu przejęcie konta, ale prowadzi do mylących sytuacji: ofiara widzi cudze dane lub wykonuje działania, które później napastnik może skojarzyć z własnym kontem. W systemach pojedynczego logowania to zjawisko bywa zaskakująco realne, jeżeli aplikacja nie waliduje stanu po stronie serwera i nie wymusza odpowiednich parametrów przepływu logowania.

Bardzo często ataki CSRF są łączone z innymi wektorami: clickjackingiem (absolutnie odrębny problem, ale bywa używany do sprowokowania kliknięć potwierdzających), XSS (który może ominąć mechanizmy anty‑CSRF, jeśli jest w tej samej domenie) czy podatnościami CORS, które w wyjątkowych sytuacjach umożliwiają uzyskanie odpowiedzi i eskalację wpływu. Synergia zagrożeń sprawia, że sama jedna kontrola bywa niewystarczająca: potrzebna jest obrona warstwowa.

Powiązania z przeglądarką i mechaniką HTTP

Warunkiem powodzenia CSRF jest automatyczne dołączenie danych uwierzytelniających do żądania. Najczęściej chodzi o ciasteczka, ale w grę wchodzą też mechanizmy poziomu przeglądarki, takie jak transparentne przekazywanie nagłówków uwierzytelniania, mechanizmy podstawowe HTTP lub pamięć poświadczeń w menedżerach haseł. Serwer, widząc prawidłową sesję, ufa, że to użytkownik zainicjował żądanie. Dlatego kluczową poprawką jest rozróżnienie „kto?” od „czy chciał?” – samo uwierzytelnienie nie wystarcza, potrzebna jest walidacja intencji.

Standardy HTTP i zachowania przeglądarek mają tu wielkie znaczenie. Przykładowo atrybuty cookies decydują o tym, kiedy są one wysyłane wraz z żądaniem. Atrybut SameSite pozwala ograniczyć wysyłanie cookie w kontekście nawigacji międzywitrynowej: ustawienie Lax domyślnie blokuje ich dołączanie do żądań POST z innych witryn, zachowując obsługę podstawowej nawigacji łączami GET; ustawienie Strict blokuje je niemal całkowicie w kontekście cross‑site; ustawienie None przywraca pełne wysyłanie, ale wymaga flagi Secure. Współcześnie wiele przeglądarek stosuje „Lax by default”, co redukuje, lecz nie eliminuje zagrożenia, zwłaszcza jeśli aplikacja nadużywa GET do zmiany stanu lub polega na mechanizmach wyłączających SameSite.

Innym sygnałem, który można sprawdzać, jest nagłówek Origin, a w drugiej kolejności Referer. Origin pojawia się w większości żądań modyfikujących, a jego poprawna weryfikacja po stronie serwera pozwala odsiać żądania wywołane spoza zaufanego pochodzenia. Referer bywa mniej niezawodny z racji polityk prywatności lub pośredników, ale nadal może wspierać decyzję. Nie należy jednak opierać się wyłącznie na tych nagłówkach: kombinacja tokenów i weryfikacji pochodzenia jest znacznie bezpieczniejsza.

Trzecim istotnym obszarem jest polityka CORS. Choć CSRF to coś innego niż CORS, oba tematy łączy to, jak przeglądarka traktuje żądania cross‑site. Preflight i ograniczenia nagłówków niestandardowych sprawiają, że nieautoryzowana strona ma trudność z przeczytaniem odpowiedzi. Nie zapobiega to jednak samemu wysłaniu żądania z dołączonym kontekstem, jeśli aplikacja na to pozwala i cookie jest przekazywane. Dlatego CORS nie jest obroną anty‑CSRF – co najwyżej ogranicza exfiltrację odpowiedzi. Projekt aplikacji powinien rozumieć różnicę: CORS jest o dostępie do danych z innych originów, a CSRF o integralności zlecanych operacji.

Na poziomie detali HTTP warto pamiętać o efektach przekierowań. Kody 301/302/303/307/308 różnią się tym, czy zachowują metodę i treść żądania. Źle zaprojektowane ścieżki przekierowań mogą nieoczekiwanie umożliwić skuteczne wymuszenia metod lub wysyłkę danych mimo zabezpieczeń, a w skrajnych konfiguracjach – ominięcie walidacji tokenów. Dodatkowo niektóre typy żądań i typy zawartości (np. application/json) nie kwalifikują się jako „simple requests”, co zmusza do preflight i komplikuje scenariusze CSRF przez zwykły HTML, ale wciąż są możliwe przez formularze z multipart/form-data czy x‑www‑form‑urlencoded, jeśli serwis je akceptuje.

Techniki obrony i wzorce

Najważniejszym mechanizmem obrony jest wprowadzenie niezależnego, trudnego do przewidzenia dowodu intencji użytkownika, który nie zostanie dołączony automatycznie przez przeglądarkę. Tym dowodem jest najczęściej token anty‑CSRF. Wzorzec „synchronizer token pattern” polega na generowaniu po stronie serwera nieprzewidywalnej wartości, wiązaniu jej z kontekstem użytkownika i weryfikacji jej poprawności przy każdym żądaniu zmieniającym stan. Token przekazywany jest w ciele formularza, w polu ukrytym, lub w nagłówku dla żądań AJAX, a serwer sprawdza jego zgodność i „świeżość”.

Popularny jest też wariant „double submit cookie”: aplikacja wysyła użytkownikowi dodatkowe cookie z losową wartością i wymaga, by ta sama wartość znalazła się w polu formularza lub nagłówku. Ponieważ strona trzecia nie może odczytać wartości cookie z innej domeny, nie jest w stanie poprawnie odtworzyć pary cookie‑formularz. Choć to rozwiązanie bywa sporne (ryzyka związane z subdomenami i scopingiem), stosowane poprawnie zapewnia solidną ochronę bez utrzymywania dodatkowej pamięci sesyjnej po stronie serwera.

Poza tokenami praktykujemy weryfikację pochodzenia: dopuszczamy tylko żądania, których Origin/Referer wskazuje nasze pochodzenie. Rozwiązanie to jest szczególnie skuteczne, gdy aplikacja stanowi pojedynczy origin i nie obsługuje cross‑site POST. W razie istnienia zaufanych integracji należy je enumerować i weryfikować jawnie. Warto mieć na uwadze przypadki braku tych nagłówków – polityka powinna definiować, czy żądanie w ogóle może być wówczas przetworzone.

Bardzo mocnym elementem obrony jest właściwa konfiguracja cookie sesyjnego: ustawienie SameSite=Lax lub Strict, flagi Secure i HttpOnly, ograniczenie Domain i Path do niezbędnego minimum. Odpowiednie ustawienie SameSite dramatycznie redukuje powierzchnię ataku, ponieważ przeglądarka po prostu nie wyśle ciasteczka sesyjnego w wielu scenariuszach cross‑site. Jednak projektant musi przewidzieć legalne ścieżki nawigacji i integracje – zbyt restrykcyjna konfiguracja może utrudnić logowanie przez zewnętrzne dostawce czy przepływy płatności.

Stosujmy też kontrolę metody i typów treści: żądania zmieniające stan powinny używać metod innych niż GET i oczekiwać konkretnego nagłówka Content‑Type. W żądaniach AJAX można wymuszać obecność niestandardowego nagłówka, którego strona trzecia nie wyśle bez preflight. Nie jest to pełna ochrona, ale utrudnia atak. Dodatkowe zabezpieczenia to: potwierdzenia krytycznych akcji (dialogi, re‑prompt hasła lub 2FA), limity wsadowe i rate limiting, a nawet „cooldowny” po logowaniu, aby utrudnić masowe wymuszenia tuż po uwierzytelnieniu.

Praktyczna lista dobrych praktyk obejmuje:

Generowanie silnych, nieprzewidywalnych tokenów powiązanych z kontekstem użytkownika i rotowanych w razie zmiany uprawnień.
Weryfikację Origin/Referer dla wszystkich akcji modyfikujących oraz jawne listy dozwolonych pochodzeń, jeśli istnieją.
Ustawienia ciasteczek: SameSite, Secure, HttpOnly, minimalny Domain i Path, brak dostępu z JavaScript, jeśli niepotrzebny.
Zakaz wykonywania operacji modyfikujących metodą GET oraz walidację Content‑Type dla POST/PUT/PATCH.
Oddzielenie interfejsów administracyjnych i użytkowych na różne subdomeny z osobnymi sesjami.
Dodatkowe potwierdzenia i step‑up auth przy operacjach finansowych, zmianie hasła, dodaniu kluczy API.
Rejestrowanie i alertowanie nietypowych żądań cross‑site, w tym niezgodności Origin/Referer i nieudanych weryfikacji tokenów.

CSRF w aplikacjach SPA, API i w procesach logowania

Aplikacje typu SPA i rozproszone API wnoszą specyfikę do tematu CSRF. Jeśli autoryzacja opiera się o cookie sesyjne, to ryzyko pozostaje takie jak w tradycyjnych aplikacjach, a mechanizmy ochrony są podobne. Problem komplikuje się, gdy poświadczenia są trzymane w pamięci przeglądarki lub w local/sessionStorage i wysyłane jako nagłówek Authorization. Taki model bywa odporny na klasyczne CSRF, bo przeglądarka nie dołącza automatycznie nagłówka, ale rodzi inny problem: ekspozycję na XSS, który może wyczytać i użyć tokenów. Ten „trade‑off” trzeba świadomie rozliczyć: albo mocne tokeny anty‑CSRF i bezpieczne cookie, albo rezygnacja z automatycznego dołączania poświadczeń kosztem konieczności uodpornienia interfejsu na skrypty.

W integracjach logowania przez zewnętrznych dostawców szczególnego znaczenia nabiera parametr „state”. W przepływach OAuth i OIDC jest on obowiązkowym środkiem przeciwko cross‑site tampering: aplikacja generuje wartość, którą otrzymuje z powrotem po przekierowaniu od dostawcy tożsamości i porównuje ją ze stanem oczekiwanym. Niepoprawna lub brakująca walidacja „state” skutkuje podatnością na login CSRF, mieszanie sesji i przekierowania do niezamierzonych końcówek.

W świecie API często przywołuje się CORS jako środek ochrony. Trzeba podkreślić, że CORS reguluje możliwość odczytu odpowiedzi przez skrypt w innej domenie, a nie sam fakt wysłania żądania. Jeśli API pozwala na operacje zmieniające stan z cookie uwierzytelniającym i nie egzekwuje tokenów anty‑CSRF ani weryfikacji pochodzenia, pozostaje podatne. Warto rozważyć architekturę, w której operacje uprzywilejowane są możliwe wyłącznie z zaufanego frontendu i przechodzą dodatkowe walidacje, a integracje maszynowe korzystają z odrębnych mechanizmów, takich jak podpisywane żądania czy klucze z ograniczeniami zakresu.

Również WebSockety, choć nie są klasycznymi żądaniami HTTP po zestawieniu połączenia, rozpoczynają się od handshake’u HTTP, który zawiera nagłówek Origin. Serwer powinien go weryfikować i odrzucać połączenia inicjowane spoza zaufanych originów. W przeciwnym razie możliwy jest wariant CSRF polegający na nieuprawnionym nawiązaniu połączenia przy użyciu ciasteczek sesyjnych, po którym dalsza komunikacja odbywa się już w uwierzytelnionym kanale.

GraphQL i inne uniwersalne endpointy koncentrują ruch w jednym miejscu. To wygodne, ale zwiększa stawkę pojedynczej kontroli. Jeśli endpoint przyjmuje mutacje i używa ciasteczek do uwierzytelnienia, tokeny anty‑CSRF oraz weryfikacja pochodzenia muszą być stosowane konsekwentnie na poziomie warstwy transportowej lub w middleware, a nie pozostawione pojedynczym resolverom.

Typowe błędy implementacyjne i antywzorce

Najczęstszy błąd to przekonanie, że logowanie użytkownika automatycznie rozwiązuje problem. Tymczasem logowanie umożliwia atakującemu nadużycie, jeśli nie ma rozróżnienia intencji. Kolejny błąd: umieszczanie tokenu w URL lub poleganie na tym samym tokenie przez długi czas. Tokeny w URL trafiają do logów, historii, nagłówków Referer i mogą zostać przechwycone. Zbyt trwałe tokeny zwiększają okno ataku. Prawidłowa praktyka to krótkie życie, powiązanie z konkretną sesją i ewentualnie rotacja po krytycznych zdarzeniach.

Wielu twórców przecenia też skuteczność CAPTCHA jako ochrony przed CSRF. CAPTCHA utrudnia automatyzację, ale nie zapobiega wysłaniu żądania przez przeglądarkę ofiary – może co najwyżej spowolnić masowe nadużycia. Niewystarczające jest też filtrowanie na podstawie adresów IP lub User‑Agent: napastnik korzysta z przeglądarki ofiary, więc te atrybuty wyglądają normalnie.

Niebezpieczne są konfiguracje, w których domena cookie obejmuje cały nadrzędny zakres (np. .example.com), podczas gdy w jednym z subserwisów występuje XSS lub możliwość przejęcia subdomeny. Atakujący może ustawić lub odczytać cookie na poziomie domeny i użyć ich do obejścia „double submit cookie” lub do przejęcia sesji w innych aplikacjach. Zalecane jest zawężanie Domain, a jeszcze lepiej utrzymywanie odrębnych domen dla stref o różnym poziomie zaufania.

Pułapką bywa też poleganie wyłącznie na nagłówku Referer. W środowiskach prywatności i przy przejściach HTTPS/HTTP (których i tak należy unikać) Referer może być obcięty lub brakować go całkowicie. Decyzja „brak Referer = pozwól” tworzy tylną furtkę. Z kolei nadmierne zaufanie do Origin bez wyjątków dla specyficznych flows może utrudnić integracje. Właściwa polityka powinna jasno określać, jakie źródła są dozwolone i jak obsługiwać brakujące nagłówki.

Projekty z wieloetapowymi formularzami często zapominają o weryfikacji tokenu na wszystkich etapach. Jeśli tylko ostatni krok weryfikuje token, ale wcześniejsze kroki coś zmieniają (np. zapisują draft), wciąż możliwy jest częściowy atak. Bezpieczna realizacja zakłada weryfikację na każdym kroku, a przynajmniej brak efektów ubocznych przed ostatnim potwierdzeniem.

Wreszcie częsty antywzorzec: przyjęcie, że „JSON nas chroni”. To nie typ danych chroni przed CSRF, lecz sposób, w jaki żądanie może zostać zainicjowane z obcej strony. Jeśli endpoint przyjmuje multipart/form‑data i interpretuje je jako mutacje, atakujący może użyć zwykłego HTML bez konieczności wywoływania fetch. Bez poprawnej walidacji tokenu i pochodzenia taki endpoint pozostaje podatny.

Testowanie, audyt i aspekty operacyjne

Testy bezpieczeństwa w obszarze CSRF powinny łączyć przegląd architektury i próbę praktycznego wykonania ataku. Zaczyna się od inwentaryzacji operacji zmieniających stan i sprawdzenia, czy którakolwiek z nich używa GET lub nie weryfikuje tokenu. Następnie audytuje się ustawienia cookies (SameSite, Secure, HttpOnly, Domain, Path), a także politykę CORS i walidację Origin/Referer. Wreszcie przygotowuje się proof‑of‑concept: prosta strona z auto‑submit formularza i osadzonymi ramkami, która próbuje wykonać podejrzane działania.

Narzędzia typu proxy (np. przeglądarkowe devtools, Burp) ułatwiają obserwację nagłówków, przekierowań i treści. Audytor zmienia pochodzenie, symuluje różne przeglądarki, sprawdza zachowanie przy i bez preflight, a także warianty z 301/302/307. Dla endpointów JSON testuje się, czy aplikacja akceptuje również x‑www‑form‑urlencoded lub multipart, oraz czy tokeny są wymagane i poprawnie weryfikowane w tych formatach.

Od strony operacyjnej ważne są logowanie i telemetria. Aplikacja powinna rejestrować nieudane weryfikacje tokenów, niespodziewane pochodzenia, liczbę prób z jednego IP oraz ciągi zdarzeń wskazujące na automatyzację. Alerty o wzrostach nieudanych weryfikacji w krótkim czasie mogą wskazywać na aktywny atak lub niekompatybilną zmianę w kliencie. Warto też posiadać funkcje natychmiastowego unieważniania tokenów i sesji w razie incydentu oraz procedury komunikacji z użytkownikami.

Proces wytwórczy powinien wymuszać poprawne zabezpieczenia domyślne. Frameworki zwykle posiadają wbudowane mechanizmy anty‑CSRF, ale ich skuteczność zależy od właściwego użycia: wyłączenie ich „na chwilę”, nieprawidłowe uwzględnianie tokenu przy żądaniach AJAX lub mieszanie subdomen potrafi otworzyć drzwi. Code review i testy automatyczne mogą sprawdzać obecność tokenu w kluczowych widokach i wymuszać weryfikację po stronie serwera. Dobrą praktyką jest też checklist przed releasem, obejmująca CSRF, CORS, cookies, logowanie i potwierdzenia krytycznych akcji.

Nie należy zapominać o edukacji użytkowników i administratorów: rozumienie, że otwieranie nieznanych linków podczas pracy w panelach administracyjnych powiększa ryzyko, oraz że przeglądarka może w tle wykonywać akcje, pomaga ograniczać skutki ataku. Jednak to tylko wsparcie – ciężar odpowiedzialności za ochronę spoczywa na architekturze i implementacji po stronie serwera.

Na koniec warto wspomnieć, że polityka bezpieczeństwa treści (CSP) nie jest bezpośrednią ochroną przed CSRF, ale pomaga ograniczyć skutki połączonych ataków (np. XSS, który mógłby obejść tokeny). Z kolei nagłówki typu Same-Origin-Policy i mechanizmy izolacji dokumentów ograniczają pewne techniki redressingu UI, co pośrednio utrudnia ataki wymagające interakcji użytkownika.

FAQ

Czym w skrócie jest CSRF? To wymuszenie przez zewnętrzną stronę wysłania przez przeglądarkę ofiary żądania do zaufanej aplikacji, z dołączonym kontekstem uwierzytelnienia, tak aby serwer uznał je za działanie użytkownika.
Czy ustawienie SameSite=Lax rozwiązuje problem? W dużym stopniu ogranicza ataki z użyciem POST, ale nie chroni, jeśli aplikacja modyfikuje stan w odpowiedzi na GET lub jeśli konieczne są nawigacje cross‑site. Dlatego traktuj to jako ważny element, lecz nie jedyną barierę.
Dlaczego nie wystarczy sprawdzanie Referer? Ten nagłówek bywa obcinany lub ukrywany przez polityki prywatności i pośredników. Może wspierać decyzję, ale samodzielnie nie zapewnia pełnej ochrony. Lepiej łączyć go z Origin i tokenami.
Czy CORS jest ochroną anty‑CSRF? Nie. CORS kontroluje odczyt odpowiedzi przez skrypt w innym originie. Nie blokuje samego wysłania żądania przez przeglądarkę z dołączonymi poświadczeniami, dlatego nie zastępuje mechanizmów anty‑CSRF.
Jakie metody HTTP są najbardziej ryzykowne? Najbardziej ryzykowne jest używanie GET do operacji zmieniających stan. Dla POST/PUT/PATCH/DELETE należy zawsze stosować tokeny i weryfikację pochodzenia.
Czy CAPTCHA ochroni przed CSRF? Nie w pełni. Może spowolnić automatyzację, ale nie zapobiega wysłaniu żądania w imieniu ofiary. Stanowi co najwyżej uzupełnienie, nie podstawę ochrony.
Jak działa „double submit cookie”? Serwer ustawia dodatkowe cookie z losową wartością. Klient wysyła tę samą wartość w polu formularza lub nagłówku, a serwer porównuje obie kopie. Strona trzecia nie odczyta wartości cookie, więc nie odtworzy poprawnej pary.
Co z atakami login CSRF? To wymuszenie zalogowania ofiary do cudzego konta. Chronią przed tym poprawna walidacja parametrów przepływu logowania (np. „state” w OIDC) oraz weryfikacja pochodzenia żądań logowania.
Czy trzymanie tokenów w localStorage eliminuje CSRF? Zmniejsza ryzyko klasycznego CSRF, bo przeglądarka nie dołącza automatycznie nagłówków autoryzacji, ale zwiększa ekspozycję na XSS. Decyzję należy podjąć świadomie, biorąc pod uwagę profil zagrożeń.
Jak testować podatność? Zidentyfikuj akcje zmieniające stan, przygotuj stronę testową z auto‑submit i spróbuj wykonać akcję z innego originu. Obserwuj nagłówki, sprawdzaj, czy serwer wymaga tokenu i czy weryfikuje Origin/Referer, a cookies mają właściwe atrybuty.
Czy WebSockety są podatne na CSRF? Handshake WebSocket używa HTTP i zawiera Origin. Jeśli serwer go nie weryfikuje, możliwe jest nieuprawnione zestawienie połączenia przy użyciu ciasteczek sesyjnych.
Czy jeden globalny token na użytkownika jest OK? Lepiej wiązać token z sesją, a nawet z kontekstem widoku czy akcją i okresowo rotować. Zbyt trwałe, globalne tokeny zwiększają ryzyko nadużyć po ich wycieku.
Co z aplikacjami mobilnymi? Mobilne WebView i komponenty przeglądarkowe dziedziczą wiele zachowań desktopu, w tym wysyłanie cookies. Zasady ochrony pozostają podobne: tokeny, weryfikacja pochodzenia (na ile to możliwe) i właściwe ustawienia ciasteczek.
Czy walidacja Content‑Type coś daje? Utrudnia ataki, bo ogranicza możliwość wysłania żądania tylko zwykłym HTML. Nie zastępuje jednak tokenów i weryfikacji pochodzenia.
Jakie logi zbierać? Nieudane weryfikacje tokenów, niespójności Origin/Referer, wskaźniki błędów 403 przy akcjach modyfikujących, nietypowe sekwencje żądań oraz metadane sesji bez danych wrażliwych.