Architecture Decision Record: Session and Token Boundaries for Browser Apps
A reference security ADR for browser sessions, server-side authorization, CSRF controls, logout behavior and separately scoped API credentials.
On this page +
Status: Proposed reference decision. This record considers a first-party browser application with a backend under the same organization's control. It is a design example, not a security certification or a claim about every BRIVOX application.
Context#
The browser needs a way to maintain an authenticated session. The backend needs to enforce access to business records and respond to logout, membership changes and account restrictions.
The design should distinguish a browser session from credentials used by mobile clients or service integrations. Copying one token strategy across all clients can obscure their different threats and revocation requirements.
Decision#
For this scenario, use an opaque session identifier in a cookie, with session state controlled on the server. Keep long-lived integration credentials out of browser JavaScript.
Set cookie attributes appropriate to the deployment, including Secure and HttpOnly, and choose SameSite behavior with the actual login and cross-site flows in mind. Limit cookie scope. HttpOnly reduces direct JavaScript access to the cookie; it does not prevent malicious script from making authorized requests through a compromised page.
Protect state-changing requests against CSRF using controls suitable for the application's framework and origin model. Do not rely on a cookie attribute as the entire CSRF design. Review CORS separately; allowing an origin is not a substitute for authenticating and authorizing a request.
OWASP's session management guidance is a baseline for reviewing cookie handling, session lifecycle and timeout behavior. The specific controls still need implementation-level verification.
Authorization remains a server responsibility#
After identifying the session, check the actor's current access to the selected organization and operation. A hidden interface button is not an access control.
Rotate session identity at appropriate authentication transitions and define idle and absolute expiry. Logout should invalidate the server-side session, not only remove a local interface flag. Decide explicitly how “sign out everywhere” differs from ending one session.
For separate API clients, define narrowly scoped credentials and revocation behavior appropriate to those clients. A signed token still needs audience, expiry and authorization checks; its format does not establish a complete security model.
Alternatives and trade-offs#
Stateless access tokens can be useful across independently operated APIs, but prompt revocation may require additional state or short lifetimes. Server sessions centralize lifecycle control but require reliable session storage and careful scaling.
This scenario favors operational clarity over assuming one mechanism is correct for every architecture. Reconsider the choice when origin boundaries, identity-provider requirements or supported clients change.
Proposed verification#
Test session expiry, logout followed by reuse, concurrent sessions, membership removal, requests from an unapproved origin and a state-changing request without the expected CSRF proof. Inspect cookie settings in the actual deployment rather than only in local development.
Check that logs and error messages do not expose session identifiers or credentials. Document recovery and incident ownership in the handover.
BRIVOX's application security review and web application development service can assess these boundaries against a specific product.
