---
title: "CSRF"
description: "CSRF to atak, w którym przeglądarka ofiary wysyła sfałszowane żądanie do serwisu, w którym jest zalogowana. Poznaj mechanizm i skuteczne zabezpieczenia."
url: "https://nodea.pl/pl/slownik-pojec/csrf"
lang: "pl"
updated: "2026-07-13"
---

# CSRF

> CSRF (Cross-Site Request Forgery) to atak polegający na zmuszeniu przeglądarki zalogowanego użytkownika do wysłania sfałszowanego żądania — np. zmiany hasła czy przelewu — bez jego wiedzy.

**CSRF** (ang. *Cross-Site Request Forgery*, fałszowanie żądań międzywitrynowych) to atak, w którym przestępca zmusza przeglądarkę zalogowanego użytkownika do wysłania spreparowanego żądania do serwisu, w którym ofiara ma aktywną sesję. Serwer widzi poprawne [ciasteczka](https://nodea.pl/pl/slownik-pojec/cookies) sesyjne — dołączane przez przeglądarkę automatycznie — więc wykonuje operację tak, jakby zleciła ją sama ofiara: zmianę adresu e-mail, hasła, dodanie administratora czy przelew.

## Jak działa atak CSRF

Scenariusz jest prosty. Użytkownik jest zalogowany w banku lub panelu administracyjnym. W innej karcie otwiera stronę podstawioną przez atakującego, która zawiera ukryty formularz automatycznie wysyłany JavaScriptem albo obrazek z adresem wykonującym akcję (*GET /transfer?to=atakujacy&kwota=1000*). Przeglądarka, wysyłając to żądanie, dokleja ciasteczka sesji ofiary — i serwer bez dodatkowych zabezpieczeń nie ma jak odróżnić żądania sfałszowanego od prawdziwego. Atak nie wymaga wykradzenia hasła ani sesji; wykorzystuje samo zaufanie serwera do uwierzytelnionej przeglądarki.

## Metody ochrony

- **Tokeny CSRF (synchronizer token)** — serwer osadza w każdym formularzu unikalny, nieprzewidywalny token powiązany z sesją i odrzuca żądania bez poprawnej wartości. Frameworki mają to wbudowane: Laravel (*@csrf* i middleware weryfikujący), Django, Rails, Spring Security.
- **Atrybut SameSite ciasteczek** — *Lax* lub *Strict* ogranicza dołączanie ciasteczek do żądań inicjowanych z innych witryn.
- **Weryfikacja nagłówków Origin/Referer** — odrzucanie żądań modyfikujących z obcych domen.
- **Ponowne uwierzytelnienie lub 2FA** przy operacjach krytycznych (zmiana hasła, przelew).
- **Poprawna semantyka HTTP** — operacje zmieniające stan wyłącznie przez POST/PUT/DELETE, nigdy przez GET.

## Zastosowanie w praktyce

Dla dewelopera aplikacji webowej ochrona przed CSRF to dziś głównie niewyłączanie mechanizmów frameworka — problemy zaczynają się przy własnych endpointach AJAX, API przyjmujących ciasteczka sesyjne oraz przy „upraszczaniu” formularzy. Testy podatności warto włączyć do przeglądów bezpieczeństwa razem z kontrolą [XSS](https://nodea.pl/pl/slownik-pojec/xss) i [SQL injection](https://nodea.pl/pl/slownik-pojec/sql-injection) — te trzy klasy ataków od lat tworzą kanon zagrożeń aplikacji internetowych.

### Czym różni się CSRF od XSS?

XSS polega na wstrzyknięciu złośliwego skryptu do zaufanej strony i wykonaniu go w przeglądarce ofiary. CSRF nie wykonuje kodu w atakowanym serwisie — jedynie wykorzystuje fakt, że przeglądarka automatycznie dołącza ciasteczka sesji do żądań. Co istotne, podatność XSS potrafi obejść zabezpieczenia anty-CSRF, bo skrypt może odczytać token.

### Czy same ciasteczka SameSite wystarczą jako ochrona przed CSRF?

SameSite=Lax (domyślne w nowoczesnych przeglądarkach) blokuje większość klasycznych wektorów, ale nie wszystkie — np. żądania GET nawigacyjne przechodzą, a starsze przeglądarki atrybutu nie respektują. OWASP zaleca traktować SameSite jako obronę wspierającą, a tokeny CSRF jako podstawową.

## Powiązane

- [XSS](https://nodea.pl/pl/slownik-pojec/xss)
- [SQL injection](https://nodea.pl/pl/slownik-pojec/sql-injection)
- [Cookies](https://nodea.pl/pl/slownik-pojec/cookies)
- [HTTPS](https://nodea.pl/pl/slownik-pojec/https)
- [Dwuskładnikowe uwierzytelnianie (2FA)](https://nodea.pl/pl/slownik-pojec/dwuskladnikowe-uwierzytelnianie)

---

Wersje językowe: [en](https://nodea.io/en/glossary/csrf-cross-site-request-forgery.md)  
Spis treści witryny: [llms.txt](https://nodea.pl/pl/llms.txt)