Session Defences in Full

Keep authority on the server. Store the user's identity, role and any trust-bearing value in the server-side session and look them up; never trust them from the cookie; sign any value that must live in a cookie. This defeats manipulation.

Limit the life of a token. Apply an inactivity timeout (the session ends after a period of no activity) and an absolute timeout (the session ends after a maximum duration regardless), so a stolen token is useful only briefly. Invalidate the session fully on logout, server-side, so the token points to nothing. Consider rotation of the token periodically during a long session.

Re-authenticate for sensitive actions. Require the password again for the most damaging operations (changing email, large transfers), so that a hijacked session cannot perform them unchallenged, which limits the damage of any token compromise that slips through.

Bind and monitor where appropriate. Some applications bind a session to attributes such as a consistent client, and monitor for anomalies (a session suddenly used from a new location or device), raising an alert or requiring re-authentication. This is defence in depth for high-value sessions.

Why "all of them" is the answer

The examinable synthesis: the defences are independent, each closing a route the others do not, so the security of the session is the security of its weakest missing measure.

• A site with HTTPS, Secure and HttpOnly but weak tokens is hijacked by prediction.
• A site with strong tokens and HTTPS but no HttpOnly is hijacked via XSS.
• A site with everything but no regeneration at login is vulnerable to fixation.
• A site with everything but no CSRF defence allows forged actions.
• A site with everything but a token that never expires turns any single theft into permanent access.

So the correct answer to "how do you secure a session" is the whole checklist, and the correct assessment finding is which measures are missing, each mapped to the attack it would have prevented. That mapping is the block's contribution and the shape of a strong examination answer.

A worked example, framed defensively

An assessor produces the session-security section of a report, applying the checklist.

• Tokens are strong and random. Good.
• HTTPS is used everywhere, but the session cookie lacks Secure and HttpOnly. Findings: sniffing exposure on any HTTP endpoint, and script-theft exposure given a known XSS flaw. Fix: set both flags.
• The token is not regenerated at login. Finding: fixation. Fix: regenerate at authentication and on privilege change.
• No SameSite and no anti-forgery tokens on state-changing actions. Finding: cross-site request forgery. Fix: set SameSite and add tokens.
• The role is read from a cookie. Finding: cookie manipulation and broken access control. Fix: move it server-side.
• The session never times out. Finding: a stolen token is useful indefinitely. Fix: inactivity and absolute timeouts, and server-side invalidation on logout.

The report presents the findings as the checklist with the gaps marked, each gap mapped to its attack, and closes by noting that the application had strong tokens and HTTPS and was nonetheless hijackable five different ways, which is the block's thesis: session security is a set, not a single measure.

What beginners get wrong

• Believing one or two measures secure the session. The defences are independent; the session is only as secure as the weakest missing one.
• Encrypting the login only. The token travels with every request; HTTPS everywhere, with Secure, is required.
• Setting flags but keeping weak tokens or no regeneration. Cookie flags close sniffing, script theft and forgery, not prediction or fixation.
• Reading identity or role from the cookie. Authoritative data must live on the server and be looked up.
• Never expiring sessions. A token that lives forever turns a single theft into permanent access; apply inactivity and absolute timeouts and invalidate on logout server-side.
• Omitting re-authentication for sensitive actions. It is the control that limits the damage of any token compromise that slips through.

Quick revision

• Session security is a set, each measure closing one route: strong random tokens (prediction); HTTPS everywhere + Secure (sniffing); HttpOnly (script theft); regenerate at login/privilege change (fixation); SameSite + anti-forgery tokens (request forgery); server-side authoritative data, signed cookie values (manipulation); inactivity + absolute timeouts, logout invalidation, rotation (limit a stolen token); re-authentication for sensitive actions (limit damage); optional binding and anomaly monitoring for high-value sessions.
• The defences are independent: the session is only as secure as its weakest missing measure, so the complete checklist is the answer and an assessment reports which measures are absent, each mapped to its attack.

Test yourself

1. Give the full set of session defences, each mapped to the attack it prevents.

Strong high-entropy tokens prevent prediction; HTTPS everywhere with the Secure flag prevents sniffing; the HttpOnly flag prevents script theft of the token; regenerating the token at login and privilege change prevents fixation; SameSite cookies and anti-forgery tokens prevent cross-site request forgery; keeping authoritative data server-side and signing any cookie values prevents cookie manipulation; and expiry, inactivity timeout, logout invalidation and rotation, together with re-authentication for sensitive actions, limit the impact of any stolen token.

1. Why is the answer to "how do you secure a session" the whole checklist rather than a single measure?

Because the defences are independent, each closing a route the others do not, so the security of the session equals the security of its weakest missing measure. A site can have strong tokens and HTTPS and still be hijacked through a missing HttpOnly flag, a lack of token regeneration, or an absent cross-site request forgery defence, so only the complete set closes every route.

1. Why must the session token be regenerated at login even if all the cookie flags are set?

Because the cookie flags close sniffing, script theft and request forgery but not fixation, which exploits the server keeping the same token across the change from anonymous to authenticated. Regenerating the token at login issues a fresh token and abandons any that was planted beforehand, so a token an attacker fixed in the victim's browser becomes useless once the victim authenticates.

1. Why is an expiry and inactivity timeout important even with every other defence in place?

Because no set of preventive measures is perfect, and any token that is nonetheless compromised remains usable for as long as it is valid. Inactivity and absolute timeouts, together with server-side invalidation on logout and periodic rotation, ensure that a stolen token is useful only briefly rather than granting indefinite access, so they limit the impact of any compromise that slips through.

1. What does storing the user's role in the server-side session rather than in a cookie protect against, and why?

It protects against cookie manipulation, because a cookie is under the client's control and any trust-bearing value in it, such as a role, can be altered by the user to gain unauthorised access. Keeping the role and other authoritative data in the server-side session and looking them up means the client cannot change them, so the server's decisions rest on data the client cannot forge.