Почему рекомендуется хранить токены API в файлах cookie для SPA, когда XSS отменяет CSRF

Question

Много написано о безопасном способе хранения токенов в типичных одностраничных приложениях (куки-файлы против локального хранилища), и использование куки-файлов часто представляется как лучший вариант. [1] [2] [3]

Причина заключается в том, что хранение данных sesssion в локальном хранилище подвержено атакам XSS.Куки имеют проблему с CSRF, но из текстов, кажется, не должно быть проблем с реализацией защиты CSRF.

Однако я не могу представить CSRF-защиту REST API для SPA, которая не была бы уязвима для XSS(если мы не говорим о повторной аутентификации и CAPTCHA) и даже в OWASP упоминается в Шпаргалке по предотвращению CSRF :

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

Поэтому, если у файлов cookie нет проблем с XSS, но есть проблема с CSRF, но CSRF бесполезен, если присутствует XSSпочему они считаются лучшим вариантом? В случае, если это не так, какова будет защита CSRF, невосприимчивая к XSS?

Answer 1

Утверждение о том, что сохранение токена аутентификации в файле cookie httpOnly "неуязвимо" только для xss, означает, что сам токен не может быть доступен через xss. Это никоим образом не означает, что приложение не может быть уязвимым.

Если приложение уязвимо для XSS (которое оно все еще может иметь), на клиенте можно получить доступ ко всему, включая токен csrf или любые данные, показанные или обработанные на клиенте. Только маркер входа / аутентификации в файле cookie httpOnly недоступен, что означает, что злоумышленник не может хотя бы украсть сеанс. Но это далеко не безопасно от xss.