CyberCertPrepWeb App FundamentalsCookies & SessionsEASYFree question
An application uses server-side sessions and stores the full user object (including password hash) in the session. Why is this a bad practice?
- A.Session stores cannot serialize complex objects
- B.Storing sensitive data like password hashes in the session creates unnecessary exposure: session stores (Redis, memcached, files) become high-value targets, session serialization bugs could expose data, and the data becomes stale - if the password changes, the session holds the old hash. Sessions should store minimal data (user ID, role) and fetch current data from the database when needed
- C.Storing user objects in sessions increases latency
- D.Password hashes cause JSON serialization errors
Why B is correct
Sessions should be lean identifiers, not data stores. Storing a password hash in a session: (1) increases the attack value of session store compromise, (2) creates stale data if the password changes, (3) risks accidental exposure through session serialization bugs or logging. Best practice: store user ID and role in the session; fetch sensitive or frequently changing user data from the database per request when needed.
Know someone studying for Web App Fundamentals? Send them this one.