1. Сессия в cookie. Браузер сам добавляет cookie к запросам на тот же сайт, если политика (SameSite, Secure) это допускает.
2. Чужой документ. Страница злоумышленника не читает cookie напрямую, но может заставить браузер отправить запрос на банк с теми cookie, что уже есть.
3. SameSite. Lax по умолчанию в Chromium не шлёт cookie на «опасные» cross-site POST и на подресурсы; top-level GET по ссылке — отдельный случай. Strict режет все cross-site запросы с cookie.
4. Токен. Секрет в теле или в заголовке, который нельзя подставить с чужой страницы без XSS или утечки, ломает классический CSRF.
5. API и CORS. JSON + credentials требует явной политики на сервере; иначе браузер не даёт приложению на evil.com завершить сценарий так же, как простую форму.

Пересчитайте сценарий на вкладке «Практика»: шаги справа синхронизированы с моделью.

CSRF — непреднамеренное выполнение действия на сайте, где у жертвы уже есть сессия, инициированное другим сайтом.

POST не лечит. Метод сам по себе не защита: форму можно отправить автоматически.

SameSite=None требует Secure; иначе браузер отвергает cookie — в симуляторе это отдельная ветка.

XSS сильнее CSRF-защиты. Если злоумышленник выполняет JS в контексте банка, он может читать DOM и подставлять токены — защита от CSRF не заменяет защиту от XSS.

Login CSRF — отдельный класс: жертву сажают в чужую сессию на слабом входе; SameSite и строгий OAuth-поток снижают риск.

Double-submit cookie работает, если схема криптографически связана с сессией и нет утечки cookie (HttpOnly и т.д.).