CSRF-защита нужна, когда браузер сам прикладывает учётные данные — cookie сессии. Для stateless API с токеном в заголовке Authorization её обычно отключают: браузер не подставит такой заголовок на чужом сайте.
А ещё JWT в cookie — CSRF снова актуален
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Атака: пользователь вошёл на ваш сайт (есть cookie сессии), открыл страницу злоумышленника, та отправила форму POST /transfer на ваш сайт. Браузер приложил cookie — запрос выполнен от имени пользователя.
Когда защита нужна: аутентификация через cookie — сессия, JWT в cookie, Basic auth в браузере. Spring Security требует CSRF-токен в изменяющих запросах (POST, PUT, PATCH, DELETE): токен выдаётся в форме или cookie и должен вернуться в параметре или заголовке.
SPA с cookie-сессией: CookieCsrfTokenRepository.withHttpOnlyFalse() — токен в cookie XSRF-TOKEN, JavaScript читает его и отправляет в заголовке X-XSRF-TOKEN. В Spring Security 6 токен по умолчанию маскируется (защита от BREACH) — для SPA нужен соответствующий обработчик запроса.
Когда отключают: API для мобильных и сервисных клиентов с токеном в заголовке Authorization: Bearer и без cookie-сессий (SessionCreationPolicy.STATELESS). Браузер такой заголовок на межсайтовый запрос сам не подставит — атаке нечего использовать.
Ошибка — отключить CSRF «потому что мешает», оставив аутентификацию по cookie.
Один верный вариант. Подумайте, потом откройте ответ.
SecurityFilterChain, аутентификация (UserDetailsService/PasswordEncoder), SecurityContext, авторизация запросов и CSRF/CORS/сессии.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto