более эффективный способ - это SameSite cookie, а не CSRF-токен.
А вот насчет запроса на запись-получения я не очень понял. Зачем это нужно в stateless приложении? CSRF токен как раз таки ломает концепт stateless: при неправильной реализации ломает кнопки "назад" и "обновить" или параллельные вкладки, а при правильной несет огромную лишнюю нагрузку на сервер
SameSite куки обязательный признак для куки сессии, но это опять про «определить что запрос пришёл с нужного домена», а я о других целях токенов говорю. Подумаю как объяснить, кажется с утра с формулировками плохо))
Попробую так сформулировать, если бы сейчас я писал защищенное приложение с чувствительными данными, то каждый запрос на запись я бы претворял обязательным запросов на получение разрешения на запись, типа пропуска. Собственно именно таким пропуском и является подобный токен. Иными словами чтобы выполнить запросы типа POST/PUT/PATCH/DELETE любым способом (ajax/form/server http) сервер бы требовал валидации токена выданного именно для этого запроса. Опять же всякие там Origin и другие заголовки не являются препятствием при формировании запроса на сервере, конечно только при условии если увели еще и куку сессии. Однако в этом смысле временный токен имеет огромный ряд преимуществ, потому что сессию в хочется делать как можно длинее и не мучать юзера перелогином.
Обсуждают сегодня