FlawOpen

flawopen.com/CSRF/GET-запросы

CSRF-токен для GET: когда он нужен?

Справочная страница
Краткий ответ

Если GET только получает данные, он не должен менять состояние сервера и обычно не нуждается в CSRF-токене. Браузеры, поисковые роботы, предпросмотр и встроенные ресурсы могут отправлять GET без намеренного клика. Используйте небезопасный метод для удаления или покупки и защищайте изменения с cookie-аутентификацией от CSRF. Старый GET, меняющий состояние, остаётся уязвимым и требует временной защиты на период миграции.

Почему GET должен оставаться безопасным методом

RFC 9110 определяет GET как безопасный: клиент не запрашивает изменение состояния. Это не означает отсутствие побочных эффектов на сервере, например записи в журнал. GET также идемпотентен, но это отдельное свойство. Браузеры, предварительная загрузка, поисковые роботы и предпросмотр ссылок могут отправлять безопасные запросы без осознанного действия пользователя. Сторонний тег <img src="..."> тоже может вызвать GET вместе с cookie пользователя. Если такой endpoint удаляет данные или меняет настройки, он нарушает семантику GET, и его может вызвать обычное содержимое страницы.

Защищайте CSRF-запросы, меняющие состояние

Частые вопросы о CSRF-токенах для GET

Что делать со старым GET-endpoint, меняющим состояние?

Считайте его уязвимым. Временно требуйте проверяемую на сервере CSRF-защиту (например, synchronizer token вместе с Origin или Fetch Metadata, если доступны), проверьте кэширование и Referer, затем перенесите действие на POST, PUT, PATCH или DELETE. Не помещайте токены в строку запроса: URL могут попасть в историю браузера, журналы и данные Referer. Проверка токена — только временная мера до перехода endpoint на безопасную семантику методов.

Источники

См. также Межсайтовая подделка запросов (CSRF, CWE-352): как работает и как предотвратить — flawopen.com JWT в localStorage или cookie HttpOnly: что безопаснее? — flawopen.com Next.js Server Actions CSRF: Origin и безопасная настройка Заменяет ли SameSite=Strict CSRF-токены?