Как защититься от CSRF-атаки?
DOM и браузер
От CSRF защищаются через `SameSite` cookie (основная мера), CSRF-токены (Synchronizer Token), проверку заголовков Origin/Referer и отказ от GET для изменяющих операций.
Основные меры защиты
SameSite cookie (главная современная защита)
Set-Cookie: session=abc; SameSite=Lax; Secure; HttpOnly- SameSite=Lax/Strict — cookie не отправляется при кросс-сайт запросах, поэтому поддельный запрос с чужого сайта не пройдёт с cookie.
Lax— разумный дефолт,Strict— строже.
CSRF-токены (Synchronizer Token Pattern)
Сервер выдаёт уникальный непредсказуемый токен, клиент прикладывает к изменяющим запросам:
POST /transfer
X-CSRF-Token: a1b2c3...Чужой сайт не знает токен (Same-Origin Policy не даёт его прочитать) → запрос отклоняется.
Проверка Origin/Referer
Сервер проверяет, что запрос пришёл с доверенного origin.
Double Submit Cookie
Токен и в cookie, и в заголовке — сервер сверяет.
Не использовать GET для изменений
Изменяющие операции — только POST/PUT/DELETE (GET не должен менять состояние).
Что НЕ защищает от CSRF
- HttpOnly — не защищает от CSRF (cookie всё равно отправляется автоматически). Он против XSS-кражи.
Комбинация
SameSite + CSRF-токены — надёжная защита.
Коротко для собеседования
От CSRF защищаются: SameSite cookie (Lax/Strict — cookie не шлётся при кросс-сайт запросах, главная мера), CSRF-токены (уникальный секрет в запросе, чужой сайт его не знает), проверка Origin/Referer, отказ от GET для изменений. HttpOnly от CSRF не спасает (cookie всё равно уходит). Комбинируют SameSite + токены.
Подробнее: MDN — CSRF