FREE LESSON · Security & cryptography · 3 OF 6

Sessions, browser trust, and request forgery

Sessions, browser trust, and request forgery: Follow credentials through login, requests, and logout.

Prerequisites: HTTP, cookies, and authorization.

Learning objectives

Describe the session lifecycle.
Distinguish XSS from CSRF.
Explain server-side revocation.

After authentication, a server commonly issues an unpredictable session identifier in a cookie. Subsequent requests present that identifier, and the server maps it to an account and session state. Treat the identifier as a credential. Rotate it when privilege changes, expire it according to policy, and invalidate it on logout or revocation as the architecture requires.

The Secure cookie attribute restricts transmission to secure contexts according to browser rules. HttpOnly prevents ordinary page JavaScript from reading the cookie. SameSite controls some cross-site sending behavior. These attributes solve different problems and must be combined with correct server checks. HttpOnly does not prevent a script running in the page from making authorized requests on the user's behalf.

Two attacks cross different boundaries

Cross-site scripting occurs when attacker-controlled content executes as script in a trusted origin. Rendering a note as HTML instead of text can turn stored content into executable authority. Use safe rendering APIs, context-appropriate encoding, and carefully reviewed sanitization when HTML is genuinely required. A content security policy can provide additional defense, but it does not make unsafe rendering correct.

Cross-site request forgery exploits credentials that a browser attaches automatically to a request initiated from another site. If a state-changing endpoint accepts such a request without validating its origin or a suitable anti-CSRF mechanism, the browser may act with the user's authority. SameSite cookies can reduce exposure, but endpoint behavior, navigation rules, and supported clients still matter.

Trace a forged transfer request

Assume a bank session cookie is sent on a cross-site form submission and the transfer endpoint accepts a POST without a CSRF token or origin validation. A malicious page can submit a transfer form. The bank recognizes the session, but that proves only which credential arrived, not that the user intended this transfer. A validated anti-CSRF token binds the request to a context the attacker cannot ordinarily read. XSS in the bank origin can undermine that protection, showing why defenses must be considered together.

Logout is a state transition

Deleting a cookie in one browser removes that browser's copy. It does not invalidate a stolen credential unless the server also rejects it or it expires. Stateless tokens make immediate revocation a design question involving short lifetimes, revocation state, or another mechanism.

Test expired, revoked, malformed, and cross-account sessions. Ensure caches do not serve one user's private content to another. Authentication is a protocol spanning browser storage, transport, server validation, and account state, not merely a login form that succeeds once.

Practice problem

A site stores user notes and renders them using raw HTML. Its session cookie is HttpOnly. Explain why account actions remain at risk. Then specify the expected behavior when a user logs out on all devices.

Worked solution

HttpOnly prevents direct cookie reading by ordinary JavaScript, but injected script executing in the site can still issue same-origin requests with the browser’s attached credentials, read accessible responses, and perform account actions. Render notes as text or use an appropriate reviewed sanitizer for supported markup. Logout on all devices should revoke all relevant server-side sessions or otherwise cause their credentials to fail validation. Merely removing the current browser cookie is insufficient. Verify that an old credential fails on a separate client and that private responses are not exposed through shared caches.

Check your understanding

Does HttpOnly stop all harm from XSS?

Yes, because no request can carry cookies.
No, injected script may still act through authenticated requests.
Yes, because HTML becomes plain text.
Only when the user is logged out.

Explanation

Cookie confidentiality is narrower than preventing script from using the origin’s authority.

What is missing when a server accepts a forged cross-site action with a valid session?

Validation of the request’s trusted context through appropriate CSRF protections.
A longer HTML page.
A different database engine.
A public session identifier.