Local Storage vs Cookies

Question

I want to reduce load times on my websites by moving all cookies into local storage since they seem to have the same functionality  Are there any pros cons  especially performance-wise  in using local storage to replace cookie functionality except for the obvious compatibility issues

User · Answer

Well  local storage speed greatly depends on the browser the client is using  as well as the operating system   Chrome or Safari on a mac could be much faster than Firefox on a PC  especially with newer APIs   As always though  testing is your friend  I could not find any benchmarks    I really don t see a huge difference in cookie vs local storage   Also  you should be more worried about compatibility issues  not all browsers have even begun to support the new HTML5 APIs  so cookies would be your best bet for speed and compatibility

User · Answer

Cookies   Introduced prior to HTML5  Has expiration date  Cleared by JS or by Clear Browsing Data of browser or after expiration date  Will sent to the server per each request  The capacity is 4KB  Only strings are able to store in cookies  There are two types of cookies  persistent and session   Local Storage   Introduced with HTML5  Does not have expiration date  Cleared by JS or by Clear Browsing Data of the browser  You can select when the data must be sent to the server  The capacity is 5MB  Data is stored indefinitely  and must be a string  Only have one type

User · Answer

Local storage can store up to 5mb offline data   whereas session can also store up to 5 mb data  But cookies can store only 4kb data in  text format   LOCAl and Session storage data in JSON format  thus easy to parse  But cookies data is in string format

User · Answer

With localStorage  web applications can store data locally within the user s browser  Before HTML5  application data had to be stored in cookies  included in every server request  Large amounts of data can be stored locally  without affecting website performance  Although localStorage is more modern  there are some pros and cons to both techniques   Cookies  Pros   Legacy support  it s been around forever  Persistent data Expiration dates   Cons   Each domain stores all its cookies in a single string  which can make parsing data difficult Data is unencrypted  which becomes an issue because        though small in size  cookies are sent with every HTTP request Limited size  4KB  SQL injection can be performed from a cookie    Local storage  Pros   Support by most modern browsers Persistent data that is stored directly in the browser Same-origin rules apply to local storage data Is not sent with every HTTP request  5MB storage per domain  that s 5120KB     Cons   Not supported by anything before  IE 8  Firefox 3 5  Safari 4  Chrome 4  Opera 10 5  iOS 2 0  Android 2 0 If the server needs stored client information you purposely have to send it    localStorage usage is almost identical with the session one  They have pretty much exact methods  so switching from session to localStorage is really child s play  However  if stored data is really crucial for your application  you will probably use cookies as a backup in case localStorage is not available  If you want to check browser support for localStorage  all you have to do is run this simple script         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 values on Secure  SSL  pages are isolated    as someone noticed keep in mind that localStorage will not be   available if you switch from  http  to  https  secured protocol  where   the cookie will still be accesible  This is kind of important to   be aware of if you work with secure protocols

User · Answer

It is also worth mentioning that localStorage cannot be used when users browse in  private  mode in some versions of mobile Safari   Quoted from MDN  https   developer mozilla org en-US docs Web API Window localStorage       Note  Starting with iOS 5 1  Safari Mobile stores localStorage data in   the cache folder  which is subject to occasional clean up  at the   behest of the OS  typically if space is short  Safari Mobile s Private   Browsing mode also prevents writing to localStorage entirely

User · Answer

Cookies and local storage serve different purposes  Cookies are primarily for reading server-side  local storage can only be read by the client-side  So the question is  in your app  who needs this data  mdash  the client or the server   If it s your client  your JavaScript   then by all means switch  You re wasting bandwidth by sending all the data in each HTTP header   If it s your server  local storage isn t so useful because you d have to forward the data along somehow  with Ajax or hidden form fields or something   This might be okay if the server only needs a small subset of the total data for each request   You ll want to leave your session cookie as a cookie either way though   As per the technical difference  and also my understanding    Apart from being an old way of saving data  Cookies give you a limit of 4096 bytes  4095  actually   mdash  it s per cookie  Local Storage is as big as 5MB per domain  mdash  SO Question also mentions it  localStorage is an implementation of the Storage Interface  It stores data with no expiration date  and gets cleared only through JavaScript  or clearing the Browser Cache   Locally Stored Data  mdash  unlike cookie expiry

User · Answer

In the context of JWTs  Stormpath have written a fairly helpful article outlining possible ways to store them  and the  dis- advantages pertaining to each method   It also has a short overview of XSS and CSRF attacks  and how you can combat them   I ve attached some short snippets of the article below  in case their article is taken offline their site goes down   Local Storage  Problems      Web Storage  localStorage sessionStorage  is accessible through JavaScript on the same domain  This means that any JavaScript running on your site will have access to web storage  and because of this can be vulnerable to cross-site scripting  XSS  attacks  XSS in a nutshell is a type of vulnerability where an attacker can inject JavaScript that will run on your page  Basic XSS attacks attempt to inject JavaScript through form inputs  where the attacker puts alert  You are Hacked    into a form to see if it is run by the browser and can be viewed by other users    Prevention      To prevent XSS  the common response is to escape and encode all untrusted data  But this is far from the full story  In 2015  modern web apps use JavaScript hosted on CDNs or outside infrastructure  Modern web apps include 3rd party JavaScript libraries for A B testing  funnel market analysis  and ads  We use package managers like Bower to import other peoples    code into our apps       What if only one of the scripts you use is compromised  Malicious   JavaScript can be embedded on the page  and Web Storage is   compromised  These types of XSS attacks can get everyone   s Web Storage   that visits your site  without their knowledge  This is probably why a   bunch of organizations advise not to store anything of value or trust   any information in web storage  This includes session identifiers and   tokens       As a storage mechanism  Web Storage does not enforce any secure   standards during transfer  Whoever reads Web Storage and uses it must   do their due diligence to ensure they always send the JWT over HTTPS   and never HTTP    Cookies  Problems      Cookies  when used with the HttpOnly cookie flag  are not accessible through JavaScript  and are immune to XSS  You can also set the Secure cookie flag to guarantee the cookie is only sent over HTTPS  This is one of the main reasons that cookies have been leveraged in the past to store tokens or session data  Modern developers are hesitant to use cookies because they traditionally required state to be stored on the server  thus breaking RESTful best practices  Cookies as a storage mechanism do not require state to be stored on the server if you are storing a JWT in the cookie  This is because the JWT encapsulates everything the server needs to serve the request       However  cookies are vulnerable to a different type of attack    cross-site request forgery  CSRF   A CSRF attack is a type of attack   that occurs when a malicious web site  email  or blog causes a user   s   web browser to perform an unwanted action on a trusted site on which   the user is currently authenticated  This is an exploit of how the   browser handles cookies  A cookie can only be sent to the domains in   which it is allowed  By default  this is the domain that originally   set the cookie  The cookie will be sent for a request regardless of   whether you are on galaxies com or hahagonnahackyou com    Prevention      Modern browsers support the SameSite flag  in addition to HttpOnly and Secure  The purpose of this flag is to prevent the cookie from being transmitted in cross-site requests  preventing many kinds of CSRF attack       For browsers that do not support SameSite  CSRF can be prevented by using synchronized token patterns  This   sounds complicated  but all modern web frameworks have support for   this       For example  AngularJS has a solution to validate that the cookie is   accessible by only your domain  Straight from AngularJS docs       When performing XHR requests  the  http service reads a token from a   cookie  by default  XSRF-TOKEN  and sets it as an HTTP header    X-XSRF-TOKEN   Since only JavaScript that runs on your domain can   read the cookie  your server can be assured that the XHR came from   JavaScript running on your domain  You can make this CSRF protection   stateless by including a xsrfToken JWT claim        iss    http   galaxies com      exp   1300819380     scopes     explorer    solar-harvester    seller       sub    tom andromeda com      xsrfToken    d9b9714c-7ac0-42e0-8696-2dae95dbc33e          Leveraging your web app framework   s CSRF protection makes cookies rock   solid for storing a JWT  CSRF can also be partially prevented by   checking the HTTP Referer and Origin header from your API  CSRF   attacks will have Referer and Origin headers that are unrelated to   your application    The full article can be found here  https   stormpath com blog where-to-store-your-jwts-cookies-vs-html5-web-storage   They also have a helpful article on how to best design and implement JWTs  with regards to the structure of the token itself  https   stormpath com blog jwt-the-right-way

[html] Local Storage vs Cookies

Examples related to html

Examples related to cookies

Examples related to httprequest

Examples related to local-storage