Stockage local vs cookies
Je souhaite réduire les temps de chargement de mes sites Web en déplaçant tous les cookies dans le stockage local, car ils semblent avoir les mêmes fonctionnalités. Existe-t-il des avantages/inconvénients (notamment en termes de performances) dans l'utilisation du stockage local pour remplacer la fonctionnalité de cookie, à l'exception des problèmes de compatibilité évidents?
Les cookies et le stockage local servent différents objectifs. Les cookies servent principalement à lire côté serveur , la mémoire de stockage locale ne peut être lue 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), alors passez à tout moment. Vous gaspillez de la bande passante en envoyant toutes les données de chaque en-tête HTTP.
S'il s'agit de votre serveur, le stockage local n'est pas très utile car vous devez transférer les données (avec des champs de formulaire Ajax ou masqués ou autre). Cela peut convenir si le serveur n'a besoin que d'un petit sous-ensemble du total des données pour chaque demande.
Cependant, vous souhaiterez laisser votre cookie de session en tant que cookie.
Selon la différence technique, et aussi ma compréhension:
En plus d'être une ancienne manière de sauvegarder des données, les cookies vous donnent une limite de 4096 octets (4095, en fait) - c'est par cookie. Le stockage local est aussi grand que 5 Mo par domaine - Question SO le mentionne également
localStorageest une implémentation de l'interfaceStorage. Il stocke les données avec 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 du cookie.
Dans le contexte de JWTs , Stormpath a écrit un article plutôt utile décrivant les moyens possibles de les stocker, ainsi que les avantages et les inconvénients de chaque méthode.
Il présente également un bref aperçu des attaques XSS et CSRF, ainsi que des moyens de les combattre.
J'ai joint quelques extraits de l'article ci-dessous, au cas où leur article serait mis hors ligne/leur site Web serait 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 en cours d'exécution sur votre site aura accès au stockage Web, ce qui le rend 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 sera exécuté sur votre page. Les attaques XSS de base tentent d’injecter du code JavaScript via des entrées de formulaire, l’attaquant mettant alert ("Vous êtes piraté"); dans un formulaire pour voir s’il est exécuté par le navigateur et peut être visualisé par d’autres utilisateurs.
Prévention:
Pour empêcher XSS, la réponse commune 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 des infrastructures externes. Les applications Web modernes incluent des bibliothèques JavaScript tierces pour les tests A/B, l'analyse de l'entonnoir/du 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? Un code JavaScript malveillant peut être intégré à la page et le stockage Web est compromis. Ces types d’attaques XSS peuvent amener le stockage Web de tout le monde à visiter votre site, à leur insu. C’est probablement la raison pour laquelle un groupe d’organisations déconseillent de stocker des informations de valeur ou de faire confiance aux informations stockées sur le Web. Cela inclut les identificateurs de session et les jetons.
En tant que mécanisme de stockage, Web Storage n'applique aucune norme sécurisée pendant le transfert. Quiconque lit Web Storage et l’utilise doit faire preuve de diligence raisonnable pour s’assurer qu’il envoie toujours le fichier 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 des 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 des cookies car ils ont traditionnellement requis que l'état soit stocké sur le serveur, enfreignant ainsi les meilleures pratiques RESTful. Les cookies en tant que mécanisme de stockage ne nécessitent pas que l'état soit stocké sur le serveur si vous stockez un fichier JWT dans le cookie. En effet, JWT encapsule tout ce dont le serveur a besoin pour répondre à la demande.
Cependant, les cookies sont vulnérables à un type d'attaque différent: la falsification de requête intersite (CSRF). Une attaque CSRF est un type d’attaque qui se produit lorsqu’un site Web, un courrier électronique ou un blog malveillant force le navigateur Web d’un utilisateur à exécuter une action indésirable sur un site approuvé sur lequel l’utilisateur est actuellement authentifié. Ceci est 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 défini le cookie à l'origine. Le cookie sera envoyé pour une demande, que vous soyez sur galaxies.com ou hahagonnahackyou.com.
Prévention:
Vous pouvez empêcher CSRF en utilisant des modèles de jeton synchronisés. Cela semble compliqué, mais tous les frameworks Web modernes ont un support pour cela.
Par exemple, AngularJS a une solution pour valider que le cookie est uniquement accessible par votre domaine. Directement de la documentation AngularJS:
Lors de l'exécution de requêtes XHR, le service $ http lit un jeton dans un cookie (par défaut, XSRF-TOKEN) et le définit comme un en-tête HTTP (X-XSRF-TOKEN). Étant donné que seul le JavaScript qui s'exécute sur votre domaine peut lire le cookie, votre serveur peut être assuré que le XHR provient de l'exécution de JavaScript sur votre domaine. Vous pouvez rendre cette protection CSRF sans état en incluant une revendication
xsrfTokenJWT:{ "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["Explorer", "solar-harvester", "seller"], "sub": "[email protected]", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }En exploitant la protection CSRF de votre infrastructure d’applications Web, les cookies sont extrêmement solides pour stocker un fichier JWT. CSRF peut également être partiellement évité en vérifiant les en-têtes HTTP Referer et Origin de votre API. Les attaques CSRF auront des en-têtes Referer et Origin qui ne sont pas liés à 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 d’implémenter 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 des applications devaient être stockées dans des cookies, inclus dans chaque requête du serveur. De grandes quantités de données peuvent être stockées localement, sans affecter les performances du site Web. Bien que localStorage soit plus moderne, il existe des avantages et des inconvénients aux deux techniques.
Biscuits
Avantages
- Support hérité (ça fait toujours longtemps)
- Données persistantes
- Dates de péremption
Les inconvénients
- Chaque domaine stocke tous ses cookies dans une seule chaîne, ce qui peut compliquer l'analyse des données.
- Les données ne sont pas cryptées, ce qui pose problème car ... ... bien que de petite taille, les cookies sont envoyés avec chaque demande HTTP Taille limitée (4 Ko)
- L'injection SQL peut être effectuée à partir d'un cookie
Stockage local
Avantages
- Support par la plupart des navigateurs modernes
- Données persistantes stockées directement dans le navigateur
- Les règles de même origine s'appliquent aux données de stockage locales
- N'est pas envoyé avec chaque requête HTTP
- ~ 5 Mo de stockage par domaine (5120 Ko)
Les inconvénients
- Aucune autre solution n’a été prise en charge 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.
localStorage l'utilisation est presque identique à celle de la session. Ils ont des méthodes à peu près exactes, passer de session à localStorage est donc 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ù localStorage ne serait pas disponible. Si vous souhaitez vérifier la prise en charge du navigateur pour 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" si quelqu'un remarque, 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 être accessible. C’est important de savoir si vous travaillez avec des protocoles sécurisés.
Il convient également de noter que localStorage ne peut pas être utilisé lorsque les utilisateurs naviguent en mode "privé" dans certaines versions de Safari pour mobile.
Cité de MDN ( https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage ):
Remarque: à partir de iOS 5.1, Safari Mobile stocke les données localStorage dans le dossier de cache, qui est sujet à un nettoyage occasionnel, à la demande du système d'exploitation, généralement si l'espace est insuffisant. Le mode de navigation privée de Safari Mobile empêche également l’écriture sur le stockage local.
Le stockage local peut stocker jusqu'à 5 Mo de données hors connexion, alors 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 de cookies sont au format chaîne.
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 pourraient être beaucoup plus rapides que Firefox sur un PC, en particulier avec les nouvelles API. Comme toujours, les tests sont votre ami (je n’ai trouvé aucun point de repère).
Je ne vois vraiment pas une énorme différence entre les cookies et le stockage local. En outre, vous devriez vous inquiéter davantage des problèmes de compatibilité: tous les navigateurs n’ayant même pas commencé à prendre en charge les nouvelles API HTML5, les cookies sont votre meilleur atout en termes de rapidité et de compatibilité.