# Session Security > Session Security - Skill: `handsomeboy990/session-security` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add handsomeboy990/session-security` - Raw SKILL.md: https://api.skillmd.com/api/skills/handsomeboy990/session-security/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: Handsomeboy990 (https://skillmd.com/u/handsomeboy990) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/handsomeboy990/session-security --- # Session Security Authentication proves who a user is once. A session carries that proof across every subsequent request. Between the correct login and the protected operation, the session is what an attacker steals, fixes or replays, and this skill owns that span. ## 1. What the session is, and where it lives ``` identifier a high-entropy, unguessable session id, or a signed token the server can verify and revoke server state for stateful sessions, the record the id points to: user, issued time, last-seen, expiry, revoked flag storage server-side session store, or a signed token whose revocation list the server keeps; never trust the client's copy of the user's role or permissions client side the id or token in an HttpOnly cookie, unreadable by script ``` A session whose only representation is a self-contained token with no server-side revocation cannot be logged out before it expires. Decide revocation before choosing the representation. ## 2. Cookie attributes A session cookie carries a fixed set of attributes. Each closes a specific attack. ``` HttpOnly script cannot read it -> an XSS cannot steal the session cookie Secure sent over HTTPS only -> not exposed on a downgraded connection SameSite Lax or Strict -> the cookie is not sent on a cross-site request, which closes most CSRF at the transport layer Path/Domain scoped as narrowly as the app allows -> not shared with siblings Max-Age bounded -> the cookie does not outlive the session it names __Host- prefix where applicable -> binds the cookie to the exact host ``` A session cookie missing HttpOnly or Secure is a finding. Missing SameSite raises the CSRF requirement in section 5. ## 3. Fixation and rotation ``` on login issue a new session id; never keep the id the user arrived with, which an attacker may have set (session fixation) on privilege change rotate the id when the user authenticates a second factor or elevates, so a pre-elevation id cannot ride the new privilege never accept a session id supplied in a URL or a request the server did not issue ``` ## 4. Timeout and concurrency ``` idle timeout the session expires after inactivity; the window matches the asset, minutes for a bank, longer for a forum absolute timeout the session expires at a fixed age regardless of activity, so a stolen long-lived session has a ceiling remember-me a separate, revocable, long-lived token, not an extended session; it re-establishes a fresh session, it is not one concurrent decide whether multiple sessions are allowed; if the asset justifies it, show them to the user and allow revoking one ``` ## 5. CSRF If the session is carried in a cookie the browser attaches automatically, a cross-site request rides it unless defended. ``` SameSite Lax or Strict on the session cookie closes most of it token a per-session or per-request anti-CSRF token on state-changing requests, verified server side, for defence in depth and for the cases SameSite does not cover check state-changing operations are POST/PUT/PATCH/DELETE, never GET; a GET must never change state, so a cross-site image cannot trigger it origin verify the Origin or Referer on sensitive state changes ``` An API authenticated by a bearer token in a header, not a cookie, is not CSRF-exposed in the same way; state the auth model before deciding the defence. ## 6. Revocation ``` logout invalidates the session server side, not only the client cookie password change invalidates every session for the account password reset the same, per authentication-security compromise an administrator can revoke a user's sessions mechanism a self-contained token needs a server-side revocation list or a short lifetime, or logout is a lie ``` ## 7. Prohibitions - Never store a session id or token in a place script can read when a cookie with HttpOnly is possible. - Never keep the session id a user arrived with across a login. - Never issue a session cookie without HttpOnly and Secure. - Never let a GET request change state. - Never make logout a client-only action for a token the server cannot revoke. - Never treat remember-me as an indefinitely extended session. - Never accept a session identifier from a URL. ## 8. Protocol 1. Establish the session representation and whether the server can revoke it. 2. Set the cookie attributes: HttpOnly, Secure, SameSite, scope, Max-Age. 3. Rotate the id on login and on privilege elevation; reject supplied ids. 4. Set idle and absolute timeouts to the asset; design remember-me separately. 5. Decide the CSRF defence from the auth model: SameSite plus a token for cookie-based sessions. 6. Implement revocation on logout, password change, reset and by an admin. 7. Rank findings on the `security-core` scale; fix and verify each. 8. Hand any infrastructure action (a shared session store, TLS config) over. ## 9. Auto-critique Score from 0 to 5: session id high-entropy and server-revocable, cookie carries HttpOnly/Secure/SameSite, id rotates on login and elevation, idle and absolute timeouts set to the asset, CSRF defended for the actual auth model, logout and password change revoke server side, remember-me is a separate revocable token. Threshold: no axis below 3, average at least 4. A session cookie without HttpOnly, or a logout that does not revoke server side, caps the score until fixed. ## 10. Interfaces - Upstream: `security-core`, `authentication-security` issues the identity this skill carries, `security-architecture` for how identity propagates. - Downstream: `authorization-design` reads the session's identity to decide access, `security-audit` verifies cookie attributes and revocation, `security-headers` sets the transport protections around it. - Lateral: `secrets-management` for the signing key, `caching-strategy` when the session store is a shared cache.