How do you handle sensitive data?

The first rule is that nothing on the client is secret. Anything shipped to the browser — bundled code, environment variables inlined at build time, data in a state store — is readable by anyone who opens devtools. There is no obfuscation that changes this.

Where secrets live

API keys, database credentials and signing secrets belong on the server, in environment variables, and never in a client bundle. Note that a prefix like NEXT_PUBLIC_ or VITE_ deliberately exposes a variable to the browser — putting a real secret behind one is a common and serious mistake. If a third-party API requires a key, proxy the call through your own backend.

Storage in the browser

Keep session tokens in HttpOnly cookies, not localStorage, which any script on the page can read. Do not cache personal data in storage that survives a reload; if you must hold it, keep it in memory for the session only.

In transit

HTTPS everywhere, with HSTS so downgrades are refused. Never put sensitive values in a URL — query strings end up in server logs, browser history, and the Referer header sent to other sites. Use a POST body.

Do not leak it accidentally

• Logs. Redact tokens, passwords and personal fields before logging, on both client and server. This is where leaks most often happen.
• Error reporting. Configure Sentry and similar tools to scrub request bodies and headers.
• API responses. Return only the fields the client needs; sending a whole user row and hiding fields in the UI still ships them.
• Git. A committed .env stays in history after you delete it — rotate the secret, do not just remove the file.

Handling it at rest

Hash passwords with bcrypt or Argon2, never encrypt or hash-with-SHA them. Encrypt sensitive columns. Collect only what you actually need — data you never stored cannot leak.