Explain Codes LogoExplain Codes Logo

Can local storage ever be considered secure?

javascript
prompt-engineering
best-practices
web-development
Nikita BarsukovbyNikita Barsukov·Jan 7, 2025
TLDR

Local storage is not inherently secure; it's susceptible to cross-site scripting, XSS attacks, where any script on your domain has access to it. For non-critical data, this is acceptable. For sensitive data, use httpOnly Secure Cookies to prevent client-side access, thus enhancing your application's security. Alternatively, consider the Web Cryptography API for data encryption prior to storing in local storage.

Secure Cookies utilisation:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; // secure cookies, because normal cookies are too mainstream

Data encryption example:

window.crypto.subtle.encrypt({ name: "AES-GCM", iv: crypto.getRandomValues(new Uint8Array(12)) }, key, data) .then(encrypted => ...); // Encryption, making your data look like gibberish since the dawn of time

Enhancing security strategies for your app

Upgrading local storage safety

While your local storage won't thwart James Bond type adversaries, you can still provide basic safety with encryption libraries such as the Stanford Javascript Crypto Library.

Encrypt before storing:

sjcl.encrypt("password", "data"); // Makes your data harder to read than my handwriting

Integrating secure keystore and disk encryption

An encrypted local partition protects your offline data. Coupled with the use of a secure keystore, you add a layer of protection against prying eyes.

Partition encryption example:

sudo cryptsetup luksFormat /dev/sdx // Getting serious in here, encrypting the entire party house

Hacking 101: The physical access

Physical access to a device = total security disaster. Restricting network access while adding custom encryption strategies are good cards to hold up your sleeve.

Best safe coding practices

Your content should be served over SSL/TLS. Adhere to strict server-side validation practices. CP to remember are OWASP XSS cheat sheet and antisamy project for secure data handling.

Foolproof coding practices

Say NO to XSS

Use Content Security Policies to keep cross-site scripting risks at bay. Don't ever trust user input—validate and sanitize rigorously.

CSP headers in action:

Content-Security-Policy: script-src 'self'; // Because trust issues are real

Ditching local storage for better alternatives

Explore IndexedDB or secure cookies as alternatives. When paired with encryption, they potentially offer better security.

Example of IndexedDB with encryption:

const encryptedData = CryptoJS.AES.encrypt(JSON.stringify(data), password).toString(); // My data speaks encoded

Custom encryption for the overly paranoid

For highly confidential data, integrate custom encryption, just like Mission Impossible. AES-256 is highly recommended.

Example with Custom Encryption:

const encryptedData = CryptoJS.AES.encrypt(data, 'secret key 123').toString(); // My data speaks in whispers

Developer's arsenal for security

Your new friend: Web Cryptography API

The Web Cryptography API does a great job on sensitive data before storing in local storage, safeguarding it, just in case.

Web Cryptography API:

window.crypto.subtle.digest('SHA-256', new TextEncoder().encode(data)) .then(digest => ...); // Digesting data like a pro

Private functions: Safe and sound

Use JavaScript closures or modules to keep those nosy devs away from your private variables and functions.

Secured private variables:

const secureModule = (function() { let privateVariable = 'secret'; // Nothing to see here, move along ... return { publicMethod: () => privateVariable }; })();

Keyloggers are watching you. Practice safe typing

Rely on on-screen keyboards or two factor authentication to combat keyloggers.

Two-Factor Authentication:

// Two-Factor Authentication with services like Authy or Google Authenticator. Better safe than sorry!