HTML5 Web Storage

HTML5 Web Storage, also known as DOM Storage, is a way to preserve state on either the client or server, making it much easier to work against the stateless nature of HTTP.
Browser Support
Web storage is supported in all major browsers such as Internet Explorer 8+, Firefox, Opera, Chrome, and Safari.
Note: Internet Explorer 7 and earlier versions, do not support web storage.

Web Storage Strengths and Weaknesses

Strengths
Weaknesses

HTML5 Web Storage Methods

Setting a Key/Value

There are two different methods for setting the information in sessionStorage:
  1. sessionStorage.setItem('someKey','someValue');
  2. sessionStorage.someKey = 'someValue';
    Getting a Value
    There are two methods to retrieve a key/value pair as well:
    1. sessionStorage.getItem('someKey'); //returns 'someValue'
    2. sessionStorage.someKey; //returns 'someValue'

    Removing a Key/Value

    What we need to do is to provide the key to the removeItem method, as in the following:
    1. sessionStorage.removeItem('someKey');//returns 'undefined' for someKey
    2. Clearing Storage
    3. sessionStorage.clear(); //everything gone!
    HTML5 Web Storage Properties HTML5 Web Storage has the following properties:

    Advantages of Web Storage in comparison to Cookies

    Web storage can be viewed simplistically as an improvement of cookies.
    The two types of Web Storage Objects to store the data is:
    Web Storage data is, in both cases, not available between different browsers. For example, storage objects created in Firefox cannot be accessed in Internet Explorer, exactly like cookies.
    You can add data to either server (session) storage or a local (client memory) storage by using Web Storage.

    localStorage

    localStorage is kept even among browser sessions. It is used to store the data locally. It stores the data with no expiration date, in other words if the browser is closed then it will not delete the data and we can view the data any time and even after a year.
    Points to remember about localStorage are:
    Example of localStorage
    1. <!DOCTYPE html>
    3. <html lang="en" xmlns="http://www.w3.org/1999/xhtml">
    4. <head>
    5. <meta charset="utf-8" />
    6. <title>HTML5 Web localStorage</title>
    7. <script>
    8. function clickCounter() {
    9. if (typeof (Storage) !== "undefined") {
    10. if (localStorage.clickcount) {
    11. localStorage.clickcount = Number(localStorage.clickcount) + 1;
    12. }
    13. else {
    14. localStorage.clickcount = 1;
    15. }
    16. document.getElementById("result").innerHTML = "You have clicked the HTML5 button " + localStorage.clickcount + " time(s).";
    17. }
    18. else {
    19. document.getElementById("result").innerHTML = "Sorry, your browser does not support web storage...";
    20. }
    21. }
    22. </script>
    23. </head>
    24. <body>
    25. <p>
    26. <button onclick="clickCounter()" type="button">HTML5</button></p>
    27. <div id="result"></div>
    28. <p>Click the HTML5 button to see the counter increase.</p>
    29. <p>Close the browser tab (or window), and try again, and the HTML5 button will continue counting with previous result.</p>
    30. </body>
    31. </html>
    Output
    localstorage.jpg

    sessionStorage

    It also stores the browser's data locally, but it is for a limited period (for one session). When we close the browser, it will automatically delete the stored data and we can't see the browser's stored data again.
    The Session Storage is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time. A common use case could be a shopping basket that persists across page views but is emptied when the user closes the browser window.
    Points to remember about Session storage are:
    Example of sessionStorage
    Output
    sessionstorage.jpg

    Difference between localStorage and sessionStorage

    Local Session
    Local storage exists until it is removed or expired. So if the browser is closed, the information will still be there when the browsers reopened. It's also available across multiple tabs Session storage is only available for the lifetime of a specific tab or window.once that window is closed, the information stored is erased

    Security Features

    Security is important to all aspects of development, such as where malicious users can gain access to sensitive information or cause damage.
    Please be aware that using Web Storage is really not more secure than cookies. In any case, do not store sensitive data (like words and credit card numbers) on the client-side, nor send this kind of data to the client.
    Web Storage is more public than cookies, and you'll need to take special precautions to ensure security if Web Storage isn't compromised by attackers.
    DNS spoofing attacks
    Because of the potential for DNS spoofing attacks, one cannot guarantee that a host claiming to be in a certain domain really is from that domain. To mitigate this, pages can use TLS. Pages using TLS can be sure that only the user, software working on behalf of the user, and other pages using TLS that have certificates identifying them as being from the same domain, can access their storage areas.

    Cross-directory attacks

    Different authors sharing one hostname, for example, users hosting content on geocities.com, all share one local storage object. There is no feature to restrict access by pathname. Authors on shared hosts are therefore recommended to avoid using these features, as it would be trivial for other authors to read the data and overwrite it.
    Even if a path-restriction feature was made available, the usual DOM scripting security model would make it trivial to by this protection and access the data from any path.

    Implementation risks

    The two primary risks when implementing these persistent storage features are letting hostile sites read information from other domains, and letting hostile sites write information that is then read from other domains.
    Letting third-party sites read data that is not supposed to be read from their domain causes information leakage, For example, a user's shopping wishlist on one domain could be used by another domain for targeted advertising; or a user's work-in-progress confidential documents stored by a word-processing site could be examined by the site of a competing company.
    Letting third-party sites write data to the persistent storage of other domains can result in information spoofing, which is equally dangerous. For example, a hostile site could add items to a user's wishlist; or a hostile site could set a user's session identifier to a known ID that the hostile site can then use to track the user's actions on the victim site.