Question Stockage local vs cookies


Je veux réduire les temps de chargement sur mes sites Web en déplaçant tous les cookies dans le stockage local, car ils semblent avoir la même fonctionnalité. Existe-t-il des avantages / inconvénients (en particulier en termes de performances) d'utiliser le stockage local pour remplacer les fonctionnalités des cookies, à l'exception des problèmes de compatibilité évidents?


796
2017-07-10 20:02


origine


Réponses:


Les cookies et le stockage local servent des objectifs différents. Les cookies sont principalement destinés à la lecture du côté serveur, le stockage local ne peut être lu que par côté client. Donc, la question est, dans votre application, qui a besoin de ces données - le client ou le serveur?

Si c'est votre client (votre JavaScript), alors changez tout simplement. Vous gaspillez de la bande passante en envoyant toutes les données dans chaque en-tête HTTP.

Si c'est votre serveur, le stockage local n'est pas très utile car vous devez transférer les données d'une manière ou d'une autre (avec des champs de formulaire Ajax ou masqués ou autre). Cela peut être correct si le serveur n'a besoin que d'un petit sous-ensemble du total des données pour chaque requête.

Cependant, vous devrez laisser votre cookie de session en tant que cookie.

Selon la différence technique, et aussi ma compréhension:

  1. En plus d'être une ancienne façon d'enregistrer des données, les cookies vous donnent une limite de 4096 octets (4095, en fait) - son par cookie. Le stockage local est aussi grand que 5 Mo par domaine - SO Question mentionne aussi

  2. localStorage est une mise en œuvre de la Storage Interface. Il stocke les données avec pas de date d'expiration, et est effacé seulement via JavaScript, ou en effaçant le cache du navigateur / les données stockées localement - contrairement à l'expiration des cookies.


988
2017-07-10 20:54



Dans le contexte des JWT, Stormpath a écrit un article assez utile décrivant les moyens possibles de les stocker, et les (dés) avantages relatifs à chaque méthode.

Il a également un bref aperçu des attaques XSS et CSRF, et comment vous pouvez les combattre.

J'ai joint quelques courts extraits de l'article ci-dessous, au cas où leur article est mis hors ligne / leur site tombe en panne.

Stockage local

Problèmes:

Le stockage Web (localStorage / sessionStorage) est accessible via JavaScript sur le même domaine. Cela signifie que tout code JavaScript exécuté sur votre site aura accès au stockage Web et, de ce fait, peut être vulnérable aux attaques par script intersite (XSS). XSS en un mot est un type de vulnérabilité où un attaquant peut injecter JavaScript qui s'exécutera sur votre page. Les attaques XSS de base tentent d'injecter du JavaScript via des entrées de formulaire, où l'attaquant met en alerte ('Vous êtes piraté'); dans un formulaire pour voir si elle est exécutée par le navigateur et peut être consulté par d'autres utilisateurs.

La prévention:

Pour empêcher XSS, la réponse commune est d'échapper et de coder toutes les données non fiables. Mais c'est loin de toute l'histoire. En 2015, les applications Web modernes utilisent JavaScript hébergé sur CDN ou sur une infrastructure externe. Les applications Web modernes incluent des bibliothèques JavaScript tierces pour les tests A / B, l'analyse entonnoir / marché et les annonces. Nous utilisons des gestionnaires de paquets comme Bower pour importer le code d'autres personnes dans nos applications.

Que se passe-t-il si un seul des scripts que vous utilisez est compromis? Mal intentionné   JavaScript peut être intégré sur la page, et le stockage Web est   compromis. Ces types d'attaques XSS peuvent obtenir le stockage Web de tout le monde   qui visite votre site, à leur insu. C'est probablement pourquoi un   groupe d'organisations conseillent de ne pas stocker quelque chose de valeur ou de confiance   toute information dans le stockage web. Cela inclut les identifiants de session et   jetons.

En tant que mécanisme de stockage, Web Storage n'impose aucune sécurité   normes lors du transfert. Celui qui lit Web Storage et l'utilise doit   faire leur diligence raisonnable pour s'assurer qu'ils envoient toujours le JWT sur HTTPS   et jamais HTTP.

Biscuits

Problèmes:

Les cookies, lorsqu'ils sont utilisés avec l'indicateur de cookie HttpOnly, ne sont pas accessibles via JavaScript et sont protégés contre XSS. Vous pouvez également définir l'indicateur Secure cookie pour garantir que le cookie est uniquement envoyé via HTTPS. C'est l'une des principales raisons pour lesquelles les cookies ont été utilisés dans le passé pour stocker des jetons ou des données de session. Les développeurs modernes hésitent à utiliser les cookies car ils exigent traditionnellement que l'état soit stocké sur le serveur, ce qui brise les bonnes pratiques RESTful. Les cookies en tant que mécanisme de stockage n'exigent pas que l'état soit stocké sur le serveur si vous stockez un JWT dans le cookie. En effet, le JWT encapsule tout ce dont le serveur a besoin pour répondre à la requête.

Cependant, les cookies sont vulnérables à un type d'attaque différent:   falsification de requête inter-site (CSRF). Une attaque CSRF est un type d'attaque   Cela se produit lorsqu'un site Web, un e-mail ou un blog malveillant provoque la   navigateur Web pour effectuer une action indésirable sur un site de confiance sur lequel   l'utilisateur est actuellement authentifié. Ceci est un exploit de la façon dont le   le navigateur gère les cookies. Un cookie ne peut être envoyé qu'aux domaines   ce qui est autorisé. Par défaut, c'est le domaine qui à l'origine   Définir le cookie. Le cookie sera envoyé pour une demande indépendamment de   si vous êtes sur galaxies.com ou hahagonnahackyou.com.

La prévention:

CSRF peut être évité en utilisant des modèles de jetons synchronisés. Ce   semble compliqué, mais tous les cadres web modernes ont un support pour   ce.

Par exemple, AngularJS a une solution pour valider que le cookie est   accessible uniquement par votre domaine. Directement à partir des documents AngularJS:

Lors de l'exécution de requêtes XHR, le service $ http lit un jeton à partir d'un   cookie (par défaut, XSRF-TOKEN) et le définit comme en-tête HTTP   (X-XSRF-JETON). Puisque seul le JavaScript qui s'exécute sur votre domaine peut   lire le cookie, votre serveur peut être assuré que le XHR est venu de   JavaScript en cours d'exécution sur votre domaine. Vous pouvez faire cette protection CSRF   apatride en incluant un xsrfToken JWT réclamation:

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

En tirant parti de la protection CSRF de votre infrastructure Web, les cookies   solide pour stocker un JWT. CSRF peut également être partiellement empêché par   vérifier l'en-tête HTTP Referer et Origin de votre API. CSRF   les attaques auront des en-têtes Referer et Origin qui ne sont pas liés à   ton application.

L'article complet peut être trouvé ici: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

Ils ont également un article utile sur la meilleure façon de concevoir et de mettre en œuvre des JWT, en ce qui concerne la structure du jeton lui-même: https://stormpath.com/blog/jwt-the-right-way/


121
2018-04-02 00:23



Avec localStorage, les applications Web peuvent stocker des données localement dans le navigateur de l'utilisateur. Avant HTML5, les données d'application devaient être stockées dans des cookies, inclus dans chaque requête du serveur. localStorage est plus sécurisé, et de grandes quantités de données peuvent être stockées localement, sans affecter les performances du site. Bien que localStorage est plus moderne, il y a quelques avantages et inconvénients aux deux techniques.

Biscuits

Avantages

  • Support hérité (il existe depuis toujours)
  • Données persistantes
  • Dates de péremption

Les inconvénients

  • Chaque domaine stocke tous ses cookies dans une seule chaîne, ce qui peut faire analyse des données difficiles
  • Les données ne sont pas cryptées, ce qui pose problème car ... ... De petite taille, les cookies sont envoyés avec chaque requête HTTP Taille limitée (4 Ko)
  • L'injection SQL peut être effectuée à partir d'un cookie

Stockage local

Avantages

  • Prise en charge par la plupart des navigateurs modernes
  • Données persistantes stockées directement dans le navigateur
  • Les règles d'origine identique s'appliquent aux données de stockage local
  • N'est pas envoyé avec chaque requête HTTP
  • ~ 5 Mo de stockage par domaine (soit 5120 Ko)

Les inconvénients

  • Non pris en charge par n'importe quoi avant: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
  • Si le serveur a besoin d'informations client stockées, vous avez volontairement pour l'envoyer.

localStorage l'utilisation est presque identique à celle de la session. Ils ont des méthodes à peu près exactes, donc passer de la session à localStorage est vraiment un jeu d'enfant. Cependant, si les données stockées sont vraiment cruciales pour votre application, vous utiliserez probablement des cookies en tant que sauvegarde en cas localStorage n'est pas disponible. Si vous voulez vérifier le support du navigateur pour localStorage, tout ce que vous avez à faire est d'exécuter ce script simple:

/* 
* 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
}

"Les valeurs localStorage sur les pages sécurisées (SSL) sont isolées"   comme quelqu'un a remarqué garder à l'esprit que localStorage ne sera pas   disponible si vous passez du protocole sécurisé 'http' au protocole 'https', où   le cookie sera toujours accessible. C'est assez important pour   Sachez si vous travaillez avec des protocoles sécurisés.


55
2018-04-01 02:50



Eh bien, la vitesse de stockage local dépend grandement du navigateur utilisé par le client, ainsi que du système d'exploitation. Chrome ou Safari sur un Mac pourrait être beaucoup plus rapide que Firefox sur un PC, en particulier avec des API plus récentes. Comme toujours, le test est votre ami (je n'ai pas trouvé de repères).

Je ne vois vraiment pas de différence énorme entre le cookie et le stockage local. En outre, vous devriez être plus préoccupé par les problèmes de compatibilité: tous les navigateurs n'ont même pas commencé à prendre en charge les nouvelles API HTML5, les cookies seraient donc votre meilleur choix pour la vitesse et la compatibilité.


6
2017-07-10 20:13



Le stockage local peut stocker jusqu'à 10 Mo de données hors connexion, tandis que la session peut stocker jusqu'à 5 Mo de données. Mais les cookies peuvent stocker seulement 4kb de données au format texte.


6
2017-08-05 09:04



Il est également important de mentionner que localStoragene peut pas être utilisé lorsque les utilisateurs naviguent en mode "privé" dans certaines versions de Safari mobile.

Cité de MDN (https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage):

Remarque: À partir d'iOS 5.1, Safari Mobile stocke les données localStorage dans   le dossier de cache, qui est sujet à un nettoyage occasionnel, au   l'ordre de l'OS, généralement si l'espace est court. Safari Mobile's Private   Le mode de navigation empêche également l'écriture dans localStorage entièrement.


2
2017-11-21 22:16