Before the advent of Web Storage, developers have had to juggle between cookies, session, query strings, and HTML forms to manage data across stateless HTTP requests – with cookies being the only client-side, data storage mechanism. Working with all these different ways to get data from here to there is often tedious at best, but unavoidable, as most web applications do need to preserve state somewhere. At the same time, you also need to consider users who have turned off features like cookies, either knocking both cookies and session objects out of the question or making them harder to work with than they should be.
Enter…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 with (or should I say against?) stateless nature of HTTP. Web storage gives you, the developer a great deal of flexibility in how you deal with data. In the earlier days of the web, hardware constraints on both the server and client, coupled with low bandwidth, created an environment in which it was much harder to pass data around. Today however, hardware is cheaper, better, and faster, so most of the constraints have been lifted, but the supporting mechanisms to move data around haven’t changed much (e.g., cookies, session, query strings). That is, until the advent and adoption of Web Storage.
Today’s storage issues revolve around these points:
- Having a choice between storage on the server or client between HTTP requests
- The need to deal with larger sets of data, to provide a rich client side experience to users
- Optimize performance and scalability by not forcing data to travel with the HTTP requests, like cookies, form data or query strings.
- Cross browser friendliness
Web Storage helps solve these important issues, as you can add data to either server (session) storage or a local (client memory) storage.
Web Storage Browser Compatibility
As far as cross browser compatibility goes, all the major browsers support Web Storage.
Web Storage size limits
Web Storage also allows you to cram much more into storage than the traditional 4k that you get with cookies. So far, the value is 5MB; however, browsers can implement the limits they’d like. According to the W3C, here’s the official word on Web Storage size limits.
“A mostly arbitrary limit of five megabytes per origin is recommended. Implementation feedback is welcome and will be used to update this suggestion in the future.”
IE allows up to 10MB, as stated here in the DOM Storage documentation on MSDN.
“Storage size is calculated as the total length of all key names and values, and a single storage area can contain up to 10 million bytes. The remainingSpace property is used to determine the available storage space.”
Moving from a mere 4k to more than 5MB gives you far more space to work with than ever before. Of course, you still need to write the code to work with Web Storage.
Working with the Web Storage API
The Web Storage API is a really small and easy to use library to stash data wherever and whenever you need. However, Web Storage isn’t just a huge bag of cookies or over-bloated session variables. Because you can store data locally, without transmitting it back to the server, applications such as these are far easier to write and maintain.
- Wizards, multi-page applications
- Shopping cart data
- Local document storage, for online word processing, spreadsheets, or blogs
- Rich, UI heavy web applications that need to display large amounts of data
Applications like these will also perform much better, as bandwidth needs decrease when the data stays put, and doesn’t travel with the HTTP request, as cookies and form elements do.
There are two ways to deal with data in the Web Storage API:
- Local storage
- Long term data persistence
- The local storage object spans multiple windows and persists beyond the current session
- Values put into localStorage are shared across all windows from the same origin
- Data is stored on the client. Behaving similarly to cookies, values persist beyond when the browser’s session ends
- Session storage
- Short term data persistence
- Once the browser’s session ends (window/tab closed), sessionStorage ends
- Values put into sessionStorage are only visible in the window/tab that created them
- Data is stored on the server
Both objects are properties of the browser’s window object, and you can access them by using JavaScript/jQuery. Both local and session storage objects are of type
Implementing a simple hit counter will work with similar syntax between local and session storage, however, it will behave much differently in each. Take for example, the following code that sets a page count in local storage and outputs it to an element with an id of pageCount :
$(function () {
if (localStorage.pagecount) {
localStorage.pagecount = Number(localStorage.pagecount) + 1;
}
else {
localStorage.pagecount = 1;
}
$("#pageCount").text(localStorage.pagecount)
});
<div id="pageCount">Page Count</div>
The page count will increment each time this page is visited by the same user agent, regardless of whether or not it’s a different tab or window. Closing and reopening the browser will continue to show data in local storage, as it’s been saved to disk. Session storage, on the other hand, though similar in syntax, will vanish once the user has closed the browser. Below is a sample of the same code, but done with session storage:
$(function () {
if (sessionStorage.pagecount) {
sessionStorage.pagecount = Number(sessionStorage.pagecount) + 1;
}
else {
sessionStorage.pagecount = 1;
}
$("#pageCount").text(sessionStorage.pagecount)
});
<div id=”pageCount”>Page Count</div>
Due to JavaScript’s dynamic nature, you can create properties on either local or session storage on the fly, as is the case with the pagecount variable in the previous samples. This gives you a lot of flexibility when determining how and where to work with data. This flexibility does come at a price…
Web Storage and security
Security is important to all aspects of development, as where malicious users can gain access to sensitive information or cause damage. Any time that you involve and store data, an attacker will try to gain access to it.
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. The W3C provides these guidelines on Web Storage security, quoted here:
7.1 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.
7.2 Cross-directory attacks
Different authors sharing one host name, for example users hosting content on geocities.com, all share one local storage object. There is no feature to restrict the 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 bypass this protection and access the data from any path.
7.3 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.
Thus, strictly following the origin model described in this specification is important for user security.
As you can see, there is some thought needed before running off to use Web Storage. Additionally, this article from Network World describes HTML5 security issues in general and including specifics on Web Storage.
Summary
Web Storage has the support of all major browsers while promising to be a versatile technology that allows you to create more robust, data driven, client side sites with little code. However, Web Storage is very new and you need to use it with caution, especially when concerned with security.
MSDN Intro to DOM Storage http://msdn.microsoft.com/en-us/library/cc197062(VS.85).aspx
Rachel Appel 