🍪 Session Security, Browser State, and AuthZ Review Patterns

Intro: This page captures the most useful architecture and review ideas from the uploaded web application security material and translates them into practical product-review checks.

What this page includes

• session and cookie review patterns for modern web products
• how to separate authentication from authorization in browser-heavy systems
• browser state, storage, and token-placement decisions
• defensive notes on CSRF, session fixation, and trust-by-default mistakes

Authentication is not authorization

A recurring engineering mistake is to let frontend state imply authority. Login success proves identity. It does not prove that a user may read another tenant object, approve a sensitive action, or call an administrative workflow.

A safer design bias is:

• the frontend can suggest intent;
• the backend must re-check authority;
• object ownership, tenant boundaries, and workflow state remain server-authoritative.

Session patterns that scale better

For higher-value products, prefer a server-held session or a BFF-mediated pattern when practical. This reduces browser exposure to tokens and centralizes upstream policy.

A browser token model can still work, but it deserves stricter review:

• why must the browser hold this token;
• what is its audience and scope;
• what is its lifetime;
• what happens on revocation, logout, and device loss.

Cookie and browser-state defaults

A practical baseline:

• Secure for session cookies;
• HttpOnly unless JavaScript truly needs cookie access;
• explicit SameSite instead of relying on defaults;
• short idle timeout and separate absolute timeout for higher-risk sessions;
• rotation on privilege change, password reset, or major risk events.

Also review whether important state leaks into localStorage, sessionStorage, URLs, cached HTML bootstraps, or client-side feature-flag payloads.

CSRF protection in modern apps

A pragmatic stack for browser flows:

• stricter cookie posture first;
• CSRF tokens for state-changing browser actions;
• Origin verification where possible and careful fallback to Referer handling;
• GET requests that stay safe and side-effect free.

Do not assume “we are JSON-only” automatically removes CSRF risk.

Trust-by-default anti-patterns

• trusting frontend routing guards as authorization;
• boilerplate auth middleware that authenticates but does not perform object-level checks;
• role-only decisions where activity, tenant, and workflow state matter more;
• client/server separation mistakes where a browser-visible value becomes implicitly trusted server input.

Review questions

• What browser state represents logged-in authority?
• Where is session material stored?
• Which pages or origins can trigger state-changing requests?
• Is authorization checked per action and per object?
• Can the user terminate active sessions after compromise?

Release criteria

• cookie flags reviewed in production responses
• login, logout, reset, and session rotation tested end to end
• object-level authorization tested with foreign identifiers
• browser storage inspected for sensitive material
• CSRF posture documented for every state-changing browser endpoint

Historical vs current notes

• Historical frontend guidance often leaned too heavily on browser-held authority. Current practice should bias toward tighter PKCE use, minimized browser-held secrets, and stronger server-side authorization.
• Older guidance often treated role checks as sufficient. Current product security work needs explicit attention to object-level, tenant-level, and workflow-state authorization.

Related pages

• Browser Security Foundations: CSP, CORS, Cookies, and Sessions
• OAuth for SPA, BFF, and Frontend Secret Anti-Patterns
• Frontend Security Review Playbook
• API Authentication and Authorization

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.