Wiki
Безопасность

CSRF — Cross-Site Request Forgery простыми словами

CSRF — атака, где злой сайт заставляет браузер жертвы отправить запрос на ваш сайт с её cookies. Пример: перевод денег по клику на картинку. Защита — CSRF-token, SameSite.

CSRF (Cross-Site Request Forgery) — атака, использующая то, что браузер автоматически шлёт cookies к домену при любом запросе. Жертва залогинена в bank.com. Заходит на evil.com. На evil.com скрытая форма: `<form action="https://bank.com/transfer" method=POST><input name=to value=attacker><input name=amount value=1000000></form>` + JS `document.forms[0].submit()`. Браузер отправляет POST с cookies bank.com → перевод.

Защита в 2026: (1) SameSite cookie — `Set-Cookie: sess=abc; SameSite=Lax; Secure`. `Lax` — не шлётся при cross-site POST/PUT/DELETE (по умолчанию в Chrome с 2020). `Strict` — не шлётся вообще при cross-site (жёстче, ломает redirect после login). (2) CSRF-токен — сервер вкладывает random-токен в форму, проверяет при submit. Классика (Django, Rails, Laravel — из коробки).

(3) Проверка Origin/Referer — сервер сверяет заголовок `Origin` с ожидаемым доменом. Не сработает при cross-origin — не пропускаем. (4) Custom header — SPA шлёт `X-Requested-With: XMLHttpRequest`, злой сайт не может (CORS запрещает custom headers без preflight). (5) Double-submit cookie — токен и в cookie, и в header, сервер сверяет.

GraphQL/REST-only приложения без cookies (Bearer JWT в LocalStorage) от классической CSRF защищены — нечего подделывать. Взамен уязвимы к XSS (JWT украден = аккаунт украден).

Частые вопросы

SameSite=Lax достаточно?
В 90 % случаев да, но старые Safari игнорируют, IE11 не знает. Токен как страховка — стандарт.
GET-запросы CSRF-уязвимы?
Только если GET меняет состояние (плохой REST). Правильный GET — идемпотентен и безопасен.

Смотрите также