What are the key security principles for user sessions?

Keep secrets on the server, encrypt them in transit, and store passwords as salted hashes — each rule closes a specific way an attacker would otherwise break in.

These principles aren't an arbitrary checklist; each one exists because of a concrete attack it prevents. Walking through why each matters is the best way to remember them:

1. Cookies are client-side storage — handy because the browser sends them automatically with every request to the domain, but the user can read and edit them in dev tools. So treat cookie contents as untrusted, never as proof of anything.
2. Sessions are server-side storage — the actual data (user id, role, cart) lives on the server; the client only holds an opaque session ID. The user can see the ID but it reveals nothing and can't be tampered into someone else's data.
3. Use sessions, not cookies, for identity — if you put userId=123 in a cookie, a user can change it to 124 and impersonate someone. Putting identity behind a session ID makes that impossible, because flipping the ID just points at no valid session (or a random one they can't guess).
4. Always use HTTPS for passwords — a login posts the password in the request body. Over plain HTTP, anyone sharing the network (open Wi-Fi, a malicious router) can read it in transit. HTTPS encrypts the whole exchange so eavesdroppers see only ciphertext.
5. Never store passwords in plaintext — hash with a salt (bcrypt) — databases get breached eventually. A hash is a one-way transform: easy to compute forward, infeasible to reverse, so a stolen hash can't be turned back into the password. The salt is a random per-user value mixed in, so two users with the same password get different hashes — this defeats precomputed "rainbow table" lookups. bcrypt bundles salting and a tunable cost factor so you can make each guess deliberately slow for attackers.
6. Check authorization on every protected request — authentication ("who are you") happens once at login; authorization ("are you allowed to touch this") must be re-checked each time, e.g. confirming the logged-in user actually owns the record they're editing. Skipping it lets a logged-in user reach other people's data just by guessing IDs.

A useful mental split: rules 1-3 decide where state lives (server, not client), rules 4-5 protect the password itself (in transit, then at rest), and rule 6 guards every door after login.

Go deeper:

• OWASP Session Management Cheat Sheet — turns rules 1-3 into concrete practice: session-ID entropy, HttpOnly/Secure/SameSite, and regenerating the ID after login to stop session fixation.
• OWASP Password Storage Cheat Sheet — the authoritative backing for rule 5: which slow, salted hash to use and how to tune it.