本節書摘來自華章計算機《web應用漏洞偵測與防禦：揭秘鮮為人知的攻擊手段和防禦技術》一書中的第1章，第1.4節,作者：(美) 希馬(shema, m.)著， 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
20世紀90年代末，許多網站被定性為大規模資料庫的html前端。google早期的首頁自豪地宣布已經收集了十億個頁面。今天，facebook已經存儲了大約一億人的資料。現代的網站能夠處理pb級規模的資料集，比十年前增長了幾個數量級。過去的口号是“網絡即計算機”，現在的趨勢是“雲計算”和“軟體即服務”，這都表明網絡為中心的資料存儲仍将持續。
這并不意味着web開發人員想要把所有資料儲存在以網絡伺服器為前端的資料庫中。把資料存儲轉移到浏覽器中有很多好處，包括帶寬、性能、存儲成本。http cookie一直是浏覽器存儲的主力，然而，cookie在數量（每個域最多20個）、大小（每個cookie 4kb）和安全性（沒有用處的path屬性）上有局限，這些限制主要是由浏覽器制造商所采納的，而不是标準規定的。
web存儲的目的是使用跨浏覽器的标準api來在浏覽器中為web開發人員提供存儲大量資料的機制。web存儲的主要特性類似于http cookie：資料通過鍵值對儲存，web存儲對象可以分為sessionstorage或者localstorage（類似于會話和持久cookie）。
存儲對象中的鍵和值是javascript字元串。sessionstroage對象與浏覽上下文綁定。例如，兩個不同的浏覽器标簽頁會有獨立的sessionstroage對象，對其中一個sessionstorage的修改不會影響另外一個。localstroage對象的内容對所有浏覽器标簽頁都是可通路的，在一個标簽頁中修改鍵值對将會影響每個标簽頁的存儲。在上述情況中，通路都受同源政策的限制。
web存儲安全性一個重要的方面是資料可以被使用者檢視和修改（參見圖1.1）。
下面的代碼示範了通過循環來枚舉存儲對象的鍵的常見模式。
最後，請記住下面這些安全方面的考慮。就像本章大部分内容一樣，重點在于web應用程式如何使用html5技術，而不是浏覽器在該技術的實作或設計中産生的漏洞。
有機會便清理資料，即為敏感資料設定适當的生命周期。因為浏覽器的關閉并不意味着sessionstorage對象中的資料會被删除。應用程式可能會在一段時間後（當然是在浏覽器運作期間）或在beforeunload事件中（或onclose事件，隻要确實是由浏覽器觸發的）删除資料。
記住放置在存儲對象中的資料和使用cookie的資料有着相同的暴露風險。它的安全性依賴于浏覽器的同源政策、浏覽器的更新檔程度、插件、底層作業系統。對存儲對象資料加密的安全性與對cookie加密的安全性一樣。把解密密鑰放置到存儲對象（或者發送到浏覽器）會降低被加密資料的安全性。
把sessionstorage對象的生命周期和“會話”的概念聯系在一起是一種弱安全依賴。現代浏覽器會在它們關閉之後甚至是系統重新開機後重建立立會話。是以，兩種類型的web存儲對象的生命周期在安全性方面就沒有多少差別。
考慮将要存儲到web存儲對象中的資料的隐私性和敏感性，不要把存儲大量資料的能力了解成存儲更敏感資料的能力。
做好被攻破的準備：在web存儲對象所位于的域内執行的html注入攻擊，将會有能力擷取該對象中的資料。當你選擇要儲存在浏覽器中的資料的種類時，要把這個因素考慮進去（第2章會介紹html注入攻擊）。
html5并不會使你的站點更加安全。像< iframe>沙盒和origin标頭等特性都是增進安全性設計的好方法。然而，配置不當的代理可能會将标頭去除，陳舊的浏覽器可能不支援上述特性，資料驗證不充分使得惡意内容能夠篡改web頁面，以上這些都會使得上述措施失效。
indexeddb
indexeddb api有自己的規範（<code>http://www.w3.org/tr/indexeddb/</code>），同webstorage api不同。它的狀态還不夠固定，而且支援它的浏覽器也比較少，但從概念角度而言，它同webstorage類似，都是為浏覽器提供資料存儲機制。是以，同webstorage相關的安全性和隐私性方面的考慮也适用于indexeddb。
indexeddb和webstorage的主要差別是indexeddb的鍵值對不局限于javascript字元串。鍵可以是類型為array、date、float或string的對象，值可以是html5的“按結構複制（structured clone）”算法所支援的任何對象。按結構複制是比json更加靈活的序列化方法。例如，它能夠處理blob對象（websocket的重要方面）以及遞歸的、自引用對象。在實際應用中，這意味着indexeddb可以存儲更複雜的資料類型。