CSRF и CORS в Spring Security: где ломается защита веб-приложений

На первый взгляд сайт работает нормально: пользователь вошёл в личный кабинет, открыл вкладку с почтой и перешёл на стороннюю страницу. Дальше всё решают настройки браузера и сервера — и именно здесь чаще всего всплывают CSRF и ошибки в CORS.

Зачем вообще разбирать CSRF и CORS

Эти две проблемы часто путают, хотя бьют по разным местам. CSRF заставляет браузер отправить нежелательное действие от имени уже авторизованного пользователя, а ошибки в CORS могут открыть посторонним сайтам доступ к ответам сервера.

Для владельца веб-приложения это не академическая теория. Если защита настроена криво, злоумышленник может заставить пользователя отправить запрос или прочитать чувствительные данные через браузер жертвы.

CSRF: когда браузер сам тащит чужой запрос

CSRF (Cross-Site Request Forgery — подделка межсайтового запроса) работает на доверии браузера к cookie. Пользователь уже вошёл в сервис, браузер хранит сессию, а вредоносная страница подсовывает форму или скрипт, который отправляет запрос от его имени.

Проблема в том, что сервер видит знакомую сессию и считает запрос легитимным. Поэтому обычная авторизация через cookie без дополнительной проверки опасна там, где пользователь может менять данные, переводить деньги или удалять записи.

В таких случаях Spring Security обычно подключает CSRF-токен. Сервер кладёт его в cookie, фронтенд читает значение и добавляет его в заголовок запроса, а сервер сравнивает оба значения и режет подозрительные обращения.

Если нужен более широкий контекст по защите интерфейсов, посмотрите также наш разбор атаки на браузерные сессии — там хорошо видно, как вредоносное ПО цепляется за доверие браузера.

CORS: когда сервер слишком щедр к чужим сайтам

CORS (Cross-Origin Resource Sharing — междоменные запросы) отвечает не за защиту сервера, а за правила для браузера. Он говорит, каким внешним доменам можно читать ответы, а каким — нельзя.

Именно поэтому кривой CORS опасен. Если сервер без разбора разрешает чужим доменам читать ответы и ещё включил передачу cookie, посторонний сайт может вытащить чувствительные данные через браузер пользователя.

Здесь важна точная настройка: список разрешённых источников, методы, заголовки и флаг allowCredentials. Для локальной разработки это удобно, но в продакшене небрежность быстро превращается в утечку.

Подобные ошибки особенно неприятны в сервисах с личными кабинетами, внутренними панелями и админками. В заметке про дыры в сетевых устройствах мы уже показывали, как одна неверная настройка ломает всю модель доверия.

Три рабочих подхода в Spring Security

Первый вариант — stateless API с токеном в заголовке. Если приложение живёт на Bearer-токенах и не хранит сессию в cookie, риск CSRF резко падает. Браузер не подставляет такой токен автоматически, а значит, чужой сайт не сможет легко сымитировать запрос.

Плюс — простая модель и меньше зависимости от cookie. Минус — нужно аккуратно строить авторизацию и следить за хранением токена на клиенте.

Второй вариант — сессия и CSRF-токен. Это классическая схема для приложений, где нужна авторизация через cookie. Spring Security создаёт отдельный CSRF-токен, а фронтенд отправляет его в заголовке вместе с запросом.

Плюс — хорошая защита для форм и запросов с изменением данных. Минус — нужно правильно связать фронтенд и бэкенд, иначе можно получить ошибки 403 и сломанный сценарий входа.

Третий вариант — строгий CORS-профиль. Он нужен там, где фронтенд и бэкенд живут на разных доменах или портах. Сервер должен разрешать только свои источники, а не весь интернет.

Плюс — меньше шансов случайно открыть чужим сайтам доступ к ответам. Минус — любая ошибка в списке доменов тут же ломает интеграцию.

Четвёртый вариант — защита на уровне процесса. Проверка заголовков, ревью конфигов, тесты на регрессии и аудит маршрутов важны не меньше кода. Здесь хорошо работает правило: если конфигурацию никто не пересматривал полгода, она уже опасна.

Кому что подходит

Если у вас SPA, мобильный клиент или внутренний API, чаще всего удобнее держать авторизацию без cookie и не усложнять схему. Для классического веб-приложения с сессиями лучше сразу включать CSRF-проверку и не надеяться на удачу.

Если фронтенд и бэкенд разнесены по разным доменам, CORS надо настраивать отдельно и очень аккуратно. А если команда небольшая, полезно сразу завести чек-лист для ревью конфигов — это дешевле, чем потом искать, откуда утекли данные.

Для удалённой работы и тестов на внешних сетях иногда используют защищённое подключение для рабочих задач, чтобы уменьшить лишнюю видимость трафика и не тащить тестовую среду в публичные точки доступа. Но это не заменяет ни CSRF, ни CORS, ни нормальную проверку заголовков.

Практический вывод

Spring Security не спасает по умолчанию от всего подряд. Он даёт инструменты, но конфигурацию всё равно должен проверить человек: где сессия, где токен, какие источники разрешены, какие заголовки приходят с клиента.

Если коротко, то правило такое: cookie — значит CSRF-проверка; разные домены — значит строгий CORS; обычный браузерный трафик — значит никакой самодеятельности с доверенными источниками.

Чек-лист для проверки прямо сейчас

• Проверьте, использует ли приложение cookie-сессию или Bearer-токен.
• Если есть cookie-сессия, включите CSRF-защиту для запросов с изменением данных.
• Убедитесь, что фронтенд передаёт CSRF-токен в отдельном заголовке.
• Пересмотрите CORS-список: только нужные домены, без лишних wildcard.
• Не включайте allowCredentials(true) вместе с расплывчатой политикой доступа.
• Протестируйте ответы сервера на 403 и проверьте, что они появляются там, где надо.
• Разберите конфиг Spring Security на ревью, а не после инцидента.
• Если у вас есть личный кабинет или админка, проверьте сценарии с изменением данных вручную.