Design session expiration around risk and usability

An operations dashboard and a shared service kiosk do not need identical session behavior. Long sessions reduce interruptions but extend the time an unattended account remains usable. Short sessions can disrupt legitimate work. Customers should request an explicit session policy for each important workflow instead of accepting an unexplained platform default.

Distinguish inactivity from total lifetime

OWASP separates idle timeout from absolute timeout. Idle timeout concerns inactivity, while absolute timeout limits a session regardless of activity.[8] Ask which server events count as activity. A background refresh should not silently determine the business policy.

Recommend recording the user environment, data sensitivity, expected task duration, and consequences of unattended access before choosing values. Shared devices deserve separate consideration from personal managed devices. Do not copy example timeout values from a reference into every application without reviewing the actual workflow.

Make the server authoritative

OWASP states that timeout management and expiration must be enforced server-side.[8] A countdown in the browser can warn the customer, but the customer’s browser must not decide whether an expired session remains valid.

Ask the team to distinguish session expiry, explicit logout, and reauthentication for a sensitive action. OWASP also warns that browser close events do not reliably enforce logout.[8] Do not accept closing a tab as the only way to end access. Require an explicit logout action and defined invalidation behavior.

Hypothetical example: a long inspection report

In a hypothetical inspection portal, a customer writes a detailed report and pauses to check equipment. The team chooses a warning before idle expiry and a controlled draft mechanism. The draft remains associated with the authorized account, not exposed as a public recovery link.

A rehearsal leaves the page open beyond expiry, then attempts submission. The server requires sign-in again, and the customer can recover only the permitted draft afterward. This hypothetical acceptance case does not prescribe universal timeout values or establish that draft storage is suitable for every data type.

Test the inconvenient boundaries

Client warnings can improve usability, but OWASP treats them as an addition to server controls.[8] Include warning failures and background behavior in acceptance evidence.

• Document idle and absolute limits for each supported user environment.
• Define which requests extend inactivity and which do not.
• Test server rejection after expiry with JavaScript disabled or interrupted.
• Check explicit logout across tabs and the supported session model.
• Inspect draft recovery for access control and sensitive local storage.

Protect work without preserving excess access

Autosave and longer timeouts solve different problems. Autosave creates retained data that needs its own protection and cleanup. A longer timeout retains access for longer. Review both choices with business owners. The desired outcome is a predictable return to work, not an invisible extension of authority whenever the interface becomes inconvenient.