IndexedDB is a low-level API for client-side storage of significant amounts of structured data. While powerful, it requires careful security consideration as stored data could be vulnerable to XSS attacks. Proper data sanitization, access controls, and encryption of sensitive data are essential when using IndexedDB in web applications.
IndexedDB is a low-level, transactional database built into the browser for storing large amounts of structured data on the client. Unlike the simple string key-value model of Local Storage, it holds structured JavaScript objects and files, supports indexes for efficient lookups, and groups operations into transactions. Its API is asynchronous and event or promise driven, so large reads and writes do not block the main thread. Storage quotas are much larger than Web Storage, often hundreds of megabytes or more depending on disk space. Like other client storage it is partitioned per origin, and it underpins offline-first web apps, progressive web apps, and any feature that needs a queryable local dataset.
IndexedDB is bound by the same-origin policy and is not shared across origins, but within an origin it is fully readable and writable by any executing script, including injected or third-party code. It offers no built-in encryption, so anything stored there sits in plaintext on the user's disk and is exposed to a cross-site scripting payload that can open the database and read every record. Because it is designed to hold far more data than Local Storage, a breach can leak much larger volumes, including cached personal data or offline copies of records. Data also read back from IndexedDB and rendered without sanitization is a classic path to DOM-based XSS.
Store only what the application genuinely needs offline, and avoid keeping raw secrets or tokens in IndexedDB. If sensitive data must be cached, encrypt it in the application layer, ideally with keys derived through the Web Crypto API and never persisted alongside the data. Treat every value read from the database as untrusted input: validate it and encode it before inserting into the DOM. A strict Content Security Policy limits which scripts can run and reach the database. cside's role is on the third-party-script side; its Script method and payload analysis can detect and block an external script that starts opening and exfiltrating IndexedDB contents in real time.
No, not by default. IndexedDB stores data in plaintext on the user's disk, and any script on the origin can read it. If you need confidentiality you must encrypt values yourself in the application, for example with the Web Crypto API, before writing them to the database.
Far more. Local Storage is typically capped around 5 to 10 MB per origin, while IndexedDB quotas commonly run to hundreds of megabytes or a percentage of available disk, making it suitable for offline datasets. The larger capacity also means a compromise can expose a much bigger volume of data.
We answer client-side security questions every day. Bring yours.