Je souhaite 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 les mêmes fonctionnalités. Y a-t-il des avantages / inconvénients (en particulier en termes de performances) à utiliser le stockage local pour remplacer la fonctionnalité des cookies, à l'exception des problèmes de compatibilité évidents?

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

Si c'est votre client (votre JavaScript), changez certainement. 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 si utile parce que vous devrez transmettre les données en quelque sorte (avec Ajax ou des champs de formulaire cachés ou quelque chose). Cela peut être correct si le serveur n'a besoin que d'un petit sous-ensemble du total des données pour chaque demande.

Vous souhaiterez cependant 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 de sauvegarder les données, les cookies vous donnent une limite de 4096 octets (4095, en fait) - c'est par cookie. Le stockage local peut atteindre 5 Mo par domaine - SO Question le mentionne également.

2. localStorageest une implémentation de l' StorageInterface. Il stocke les données sans date d'expiration et est effacé uniquement via JavaScript ou en effaçant le cache du navigateur / les données stockées localement, contrairement à l'expiration des cookies.

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 liés à 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 serait mis hors ligne / leur site tomberait en panne.

Stockage local

Problèmes:

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

La prévention:

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

Que faire si un seul des scripts que vous utilisez est compromis? Un code JavaScript malveillant peut être intégré à 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 tas d'organisations conseillent de ne pas stocker quoi que ce soit de valeur ou de faire confiance à aucune information dans le stockage Web. Cela inclut les identifiants de session et les jetons.

En tant que mécanisme de stockage, Web Storage n'applique aucune norme sécurisée lors du transfert. Quiconque lit Web Storage et l'utilise doit faire preuve de diligence raisonnable pour s'assurer qu'il envoie toujours le JWT via 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 immunisés contre XSS. Vous pouvez également définir l'indicateur de cookie sécurisé pour garantir que le cookie est uniquement envoyé via HTTPS. C'est l'une des principales raisons pour lesquelles les cookies ont été exploités dans le passé pour stocker des jetons ou des données de session. Les développeurs modernes hésitent à utiliser des cookies car ils exigeaient traditionnellement que l'état soit stocké sur le serveur, ce qui enfreint les meilleures 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 demande.

Cependant, les cookies sont vulnérables à un autre type d'attaque: la contrefaçon de demande intersite (CSRF). Une attaque CSRF est un type d'attaque qui se produit lorsqu'un site Web, un e-mail ou un blog malveillant oblige le navigateur Web d'un utilisateur à effectuer une action indésirable sur un site de confiance sur lequel l'utilisateur est actuellement authentifié. Il s'agit d'un exploit de la façon dont le navigateur gère les cookies. Un cookie ne peut être envoyé qu'aux domaines dans lesquels il est autorisé. Par défaut, il s'agit du domaine qui a initialement défini le cookie. Le cookie sera envoyé pour une demande, que vous soyez sur galaxies.com ou hahagonnahackyou.com.

La prévention:

Les navigateurs modernes prennent en charge le SameSitedrapeau , en plus de HttpOnlyet Secure. Le but de cet indicateur est d'empêcher la transmission du cookie dans les requêtes intersites, empêchant de nombreux types d'attaques CSRF.

Pour les navigateurs qui ne prennent pas en charge SameSite, CSRF peut être empêché en utilisant des modèles de jetons synchronisés. Cela semble compliqué, mais tous les cadres Web modernes prennent en charge cela.

Par exemple, AngularJS a une solution pour valider que le cookie n'est accessible que 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 un en-tête HTTP (X-XSRF-TOKEN). Étant donné que seul JavaScript qui s'exécute sur votre domaine peut lire le cookie, votre serveur peut être assuré que le XHR provient de JavaScript exécuté sur votre domaine. Vous pouvez rendre cette protection CSRF apatride en incluant une xsrfTokenrevendication JWT:

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

Tirer parti de la protection CSRF de votre infrastructure d'application Web rend les cookies solides pour le stockage d'un JWT. CSRF peut également être partiellement empêché en vérifiant l'en-tête HTTP Referer et Origin de votre API. Les attaques CSRF auront des en-têtes Referer et Origin sans rapport avec votre 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/

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 demande de serveur. De grandes quantités de données peuvent être stockées localement, sans affecter les performances du site Web. Bien qu'il localStoragesoit plus moderne, les deux techniques présentent des avantages et des inconvénients.

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 rendre l'analyse des données difficile
• Les données ne sont pas cryptées, ce qui devient un problème car ... ... bien que 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
• Des règles de même origine 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 quoi que ce soit auparavant: 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 devez les envoyer à dessein.

localStoragel'utilisation est presque identique à celle de la session. Ils ont des méthodes à peu près exactes, donc passer de la session à localStorageest vraiment un jeu d'enfant. Cependant, si les données stockées sont vraiment cruciales pour votre application, vous utiliserez probablement des cookies comme sauvegarde au cas où ils localStoragene seraient pas disponibles. Si vous souhaitez vérifier la prise en charge du navigateur localStorage, il vous suffit 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 de localStorage sur les pages sécurisées (SSL) sont isolées», comme quelqu'un l'a remarqué, gardez à 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. Il est important de savoir si vous travaillez avec des protocoles sécurisés.

Eh bien, la vitesse de stockage local dépend grandement du navigateur que le client utilise, 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 les nouvelles API. Comme toujours, le test est votre ami (je n'ai pas trouvé de référence).

Je ne vois vraiment pas de différence énorme entre les cookies et le stockage local. De plus, 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, donc les cookies seraient votre meilleur pari pour la vitesse et la compatibilité.

Il convient également de mentionner qu'il 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 soumis à un nettoyage occasionnel, à la demande du système d'exploitation, généralement si l'espace est court. Le mode de navigation privée de Safari Mobile empêche également complètement l'écriture sur localStorage.

Le stockage local peut stocker jusqu'à 5 Mo de données hors ligne, tandis que la session peut également stocker jusqu'à 5 Mo de données. Mais les cookies ne peuvent stocker que des données de 4 Ko au format texte.

Données de stockage LOCAL et Session au format JSON, donc faciles à analyser. Mais les données des cookies sont au format chaîne.

Cookies :

1. Introduit avant HTML5.
2. A une date d'expiration.
3. Cleard par JS ou par Clear Browsing Data du navigateur ou après la date d'expiration.
4. Sera envoyé au serveur pour chaque demande.
5. La capacité est de 4 Ko.
6. Seules les chaînes peuvent stocker des cookies.
7. Il existe deux types de cookies: persistants et session.

Stockage local:

1. Introduit avec HTML5.
2. N'a pas de date d'expiration.
3. Cleard par JS ou par Clear Browsing Data du navigateur.
4. Vous pouvez sélectionner le moment où les données doivent être envoyées au serveur.
5. La capacité est de 5 Mo.
6. Les données sont stockées indéfiniment et doivent être une chaîne.
7. N'ont qu'un seul type.