What Never to Store in the Browser

Browser data is not secret

Anything in localStorage can be inspected and edited by the person using that browser. A malicious script running on your page may also be able to read it. Storage is useful for convenience, but it does not make a value private or trustworthy. Hiding a key in a variable name or encoding it does not turn it into a secret.

That is why your persistence quest should save harmless interface state, not credentials. Never put passwords or secret API keys in localStorage. A browser app is delivered to users, so secrets embedded in client-side code or storage can be discovered.

Do not trust a browser value

A user can change localStorage with developer tools, and scripts may change it too. Therefore, do not use it as proof that someone earned a score, owns an item or paid for something. If the app decides access or rewards from an editable browser value, a user can simply alter that value.

For a practice calculator, localStorage can restore a draft or preference. It should not be the authority for a competitive score or purchase.

Put real progress on a server

When progress must be accurate, shared across devices or linked to an account, store it on a server-side database. The server can apply access rules and check requests before accepting changes. A browser can still display cached or draft information, but the server should remain the source of truth.

This distinction explains why a later full-stack activity uses a database rather than relying on localStorage: a server can hold shared records beyond one browser profile. It does not mean every server automatically makes data safe; authentication and access controls still matter.

Make safer choices in your activity

Keep localStorage limited to non-sensitive convenience data. Assume anyone with access to the browser can read or modify it, and design your app to recover if it is missing or altered. Never place passwords, secret keys or authoritative scores there.

When deciding where a value belongs, ask: must it be secret, accurate, or available on another device? If yes, browser storage alone is the wrong place. Use a server-backed design for real progress, and keep secrets out of client-side code altogether.

Make a concrete storage decision

A dark-mode preference can be restored from localStorage because changing it affects only the visitor's experience. A draft calculator quantity is also harmless convenience data. A value called paid=true or verifiedXP=9999 must never grant real access or rewards: the user can edit it as easily as the theme.

Rehearse this on your own disposable page, not your academy account. Save practice:theme as dark, change it to light in DevTools, then reload. The preference should follow the edited value. That visible change is the reason browser storage cannot prove a purchase or earned score.

A server response cached in the browser may help display a last-known value, but privileged actions must recheck the authoritative record server-side. Do not assume a value is trusted because your own code originally wrote it.

Authentication storage is a separate design problem

Do not hand-roll password or session-token storage. Established auth libraries may manage sessions in browser storage or secure cookies depending on their design; that does not make localStorage a safe place for arbitrary secrets. Follow the provider/framework's supported session handling, protect against script injection and avoid exposing session tokens in logs, prompts or screenshots. Where appropriate, server-managed HttpOnly cookies keep a session value out of JavaScript, but still require correct request protections.

Before leaving the branch, classify each item in your product: harmless local preference, editable draft, server-authoritative record or private credential. Explain what happens if a visitor changes it. If that change would unlock a paid or verified capability, the decision belongs on a protected server, not in localStorage.