Файлы cookie и локальное хранилище служат разным целям. Файлы cookie предназначены в первую очередь для чтения на стороне сервера, локальное хранилище может быть прочитано только на стороне клиента. Итак, вопрос в том, кому в вашем приложении нужны эти данные - клиенту или серверу?

Если это ваш клиент (ваш JavaScript), то обязательно переключайтесь. Вы тратите пропускную способность, отправляя все данные в каждом заголовке HTTP.

Если это ваш сервер, локальное хранилище не так полезно, потому что вам придется каким-то образом пересылать данные (с помощью Ajax или скрытых полей формы или чего-то еще). Это может быть нормально, если серверу требуется только небольшое подмножество общих данных для каждого запроса.

В любом случае вы захотите оставить файл cookie сеанса в качестве файла cookie.

Согласно технической разнице, а также моему пониманию:

1. Помимо того, что файлы cookie являются старым способом сохранения данных, они предоставляют ограничение в 4096 байт (фактически 4095) на один файл cookie. Размер локального хранилища составляет 5 МБ на домен SO Вопрос также упоминает об этом.

2. localStorage - это реализация Storage Интерфейса. Он хранит данные с без срока действия и очищается только с помощью JavaScript или очистки кеша браузера / локально сохраненных данных, в отличие от истечения срока действия файлов cookie.

Что касается JWT, Stormpath написал довольно полезную статью, в которой описываются возможные способы их хранения и (не) преимущества каждого метода.

В нем также есть краткий обзор атак XSS и CSRF и способов борьбы с ними.

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

Локальное хранилище

Проблемы:

Веб-хранилище (localStorage / sessionStorage) доступно через JavaScript в том же домене. Это означает, что любой JavaScript, запущенный на вашем сайте, будет иметь доступ к веб-хранилищу и из-за этого может быть уязвим для атак межсайтового скриптинга (XSS). Вкратце, XSS - это тип уязвимости, при которой злоумышленник может внедрить JavaScript, который будет работать на вашей странице. Базовые XSS-атаки пытаются внедрить JavaScript через входные данные формы, где злоумышленник ставит предупреждение («Вы взломаны»); в форму, чтобы узнать, запущен ли он браузером и доступен ли он другим пользователям.

Профилактика:

Чтобы предотвратить XSS, общий ответ - ускользнуть и закодировать все ненадежные данные. Но это далеко не все. В 2015 году современные веб-приложения используют JavaScript, размещенный в CDN или внешней инфраструктуре. Современные веб-приложения включают сторонние библиотеки JavaScript для A / B-тестирования, анализа воронки / рынка и рекламы. Мы используем менеджеры пакетов, такие как Bower, для импорта кода других людей в наши приложения.

Что делать, если скомпрометирован только один из используемых вами скриптов? Вредоносный код JavaScript может быть встроен на страницу, и веб-хранилище будет скомпрометировано. Эти типы XSS-атак могут поразить любое веб-хранилище, которое посещает ваш сайт без его ведома. Вероятно, поэтому группа организаций советует не хранить ничего ценного и не доверять какой-либо информации в веб-хранилище. Сюда входят идентификаторы сеанса и токены.

В качестве механизма хранения веб-хранилище не требует соблюдения каких-либо стандартов безопасности во время передачи. Тот, кто читает и использует веб-хранилище, должен проявлять должную осмотрительность, чтобы гарантировать, что они всегда отправляют JWT через HTTPS, а не через HTTP.

Печенье

Проблемы:

Файлы cookie при использовании с флагом cookie HttpOnly недоступны через JavaScript и неуязвимы для XSS. Вы также можете установить флаг Secure cookie, чтобы гарантировать, что cookie будет отправляться только по HTTPS. Это одна из основных причин того, что файлы cookie использовались в прошлом для хранения токенов или данных сеанса. Современные разработчики не решаются использовать файлы cookie, потому что они традиционно требовали, чтобы состояние сохранялось на сервере, тем самым нарушая передовой опыт RESTful. Файлы cookie как механизм хранения не требуют сохранения состояния на сервере, если вы сохраняете JWT в файле cookie. Это потому, что JWT инкапсулирует все, что нужно серверу для обслуживания запроса.

Однако файлы cookie уязвимы для другого типа атак: подделки межсайтовых запросов (CSRF). Атака CSRF - это тип атаки, который происходит, когда вредоносный веб-сайт, электронная почта или блог заставляет веб-браузер пользователя выполнять нежелательное действие на надежном сайте, на котором пользователь в настоящее время аутентифицирован. Это эксплойт того, как браузер обрабатывает файлы cookie. Файл cookie может быть отправлен только в те домены, в которых он разрешен. По умолчанию это домен, в котором изначально был установлен файл cookie. Файл cookie будет отправлен для запроса независимо от того, находитесь ли вы на сайте galaxies.com или hahagonnahackyou.com.

Профилактика:

Современные браузеры поддерживают SameSite flag в дополнение к HttpOnly и Secure. Назначение этого флага - предотвратить передачу файлов cookie в межсайтовых запросах, предотвращая многие виды атак CSRF.

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

Например, в AngularJS есть решение для проверки того, что файл cookie доступен только для вашего домена. Прямо из документов AngularJS:

При выполнении запросов XHR служба $ http считывает токен из файла cookie (по умолчанию XSRF-TOKEN) и устанавливает его в качестве заголовка HTTP (X-XSRF-TOKEN). Поскольку только JavaScript, который работает в вашем домене, может читать cookie, ваш сервер может быть уверен, что XHR поступил из JavaScript, запущенного в вашем домене. Вы можете сделать эту защиту CSRF без сохранения состояния, включив xsrfToken JWT:

{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "[email protected]",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

Использование защиты CSRF вашего фреймворка веб-приложений делает файлы cookie надежными для хранения JWT. CSRF также можно частично предотвратить, проверив заголовки HTTP Referer и Origin из вашего API. Атаки CSRF будут иметь заголовки Referer и Origin, не связанные с вашим приложением.

Полную версию статьи можно найти здесь: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

У них также есть полезная статья о том, как лучше всего разработать и реализовать JWT, в отношении структуры самого токена: https://stormpath.com/blog/jwt-the-right-way/

С localStorage веб-приложения могут хранить данные локально в браузере пользователя. До HTML5 данные приложения должны были храниться в файлах cookie, включенных в каждый запрос сервера. Большие объемы данных можно хранить локально, не влияя на производительность веб-сайта. Хотя localStorage более современный, у обоих методов есть свои плюсы и минусы.

Печенье

Плюсы

• Поддержка устаревших версий (существует всегда)
• Постоянные данные
• Срок годности

Минусы

• Каждый домен хранит все свои файлы cookie в одной строке, что может затруднить анализ данных.
• Данные не зашифрованы, что становится проблемой, потому что ... ... хотя и имеют небольшой размер, файлы cookie отправляются с каждым HTTP-запросом. Ограниченный размер (4 КБ)
• SQL-инъекция может быть выполнена из файла cookie

Локальное хранилище

Плюсы

• Поддержка большинством современных браузеров
• Постоянные данные, которые хранятся прямо в браузере
• К данным локального хранилища применяются правила одинакового происхождения.
• Не отправляется с каждым HTTP-запросом
• ~ 5 МБ хранилища на домен (это 5120 КБ)

Минусы

• Раньше ничего не поддерживалось: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0.
• Если серверу нужна сохраненная информация о клиенте, вам придется ее отправить.

localStorage использование практически идентично сессионному. У них есть довольно точные методы, поэтому переключение с сеанса на localStorage действительно детская игра. Однако, если сохраненные данные действительно важны для вашего приложения, вы, вероятно, будете использовать файлы cookie в качестве резервной копии на случай, если localStorage недоступен. Если вы хотите проверить поддержку браузером localStorage, все, что вам нужно сделать, это запустить этот простой скрипт:

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}

«Значения localStorage на защищенных (SSL) страницах изолированы», как заметил кто-то, имейте в виду, что localStorage не будет доступен, если вы переключитесь с защищенного протокола 'http' на 'https', при этом файл cookie будет по-прежнему быть доступным. Это важно знать, если вы работаете с безопасными протоколами.

Файлы cookie:

1. Представлен до HTML5.
2. Имеет срок годности.
3. Удаляется JS или Очисткой данных просмотра браузера или по истечении срока действия.
4. Будет отправлено на сервер по каждому запросу.
5. Емкость - 4 КБ.
6. В файлах cookie могут храниться только строки.
7. Есть два типа файлов cookie: постоянные и сеансовые.

Локальное хранилище:

1. Представлено в HTML5.
2. Не имеет срока годности.
3. Удаляется JS или Очисткой данных просмотра браузера.
4. Вы можете выбрать, когда данные должны быть отправлены на сервер.
5. Емкость составляет 5 МБ.
6. Данные хранятся неограниченное время и должны быть строкой.
7. Есть только один тип.

Также стоит упомянуть, что localStorage нельзя использовать, когда пользователи просматривают в "частном" режиме в некоторых версиях мобильного Safari.

Цитируется из MDN (https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage):

Примечание. Начиная с iOS 5.1, Safari Mobile хранит данные localStorage в папке кэша, которая периодически очищается по требованию ОС, как правило, при нехватке места. Режим приватного просмотра Safari Mobile также полностью предотвращает запись в localStorage.

Что ж, скорость локального хранилища сильно зависит от браузера, который использует клиент, а также от операционной системы. Chrome или Safari на Mac могут быть намного быстрее, чем Firefox на ПК, особенно с новыми API. Как всегда, тестирование - ваш друг (тестов я не нашел).

Я действительно не вижу большой разницы в файлах cookie и локальном хранилище. Кроме того, вам следует больше беспокоиться о проблемах совместимости: не все браузеры даже начали поддерживать новые API-интерфейсы HTML5, поэтому файлы cookie будут вашим лучшим выбором для скорости и совместимости.

Локальное хранилище может хранить до 5 МБ автономных данных, тогда как сеанс также может хранить до 5 МБ данных. Но файлы cookie могут хранить только 4 КБ данных в текстовом формате.

Данные хранилища LOCAl и Session в формате JSON, поэтому их легко анализировать. Но данные файлов cookie имеют строковый формат.

Ключевые отличия:

Вместимость:

• Локальное хранилище: 10 МБ
• Файлы cookie: 4 КБ

Поддержка браузера:

• Локальное хранилище: HTML5.
• Файлы cookie: HTML4, HTML5.

Место хранения:

• Локальное хранилище: только браузер
• Файлы cookie: браузер и сервер

Отправить с запросом:

• Локальное хранилище: да
• Файлы cookie: нет

Доступ с:

• Локальное хранилище: любое окно
• Файлы cookie: любое окно.

Срок годности:

• Локальное хранилище: никогда не истекает, пока не будет выполнено с помощью javascript.
• Файлы cookie: Да, срок годности истекает.

Примечание: используйте то, что вам подходит.