CSRF & Session Management Testing

Functional testing never catches these, because the application behaves perfectly for an honest user. The session works, logout appears to log you out, and everything looks fine. The bugs only surface when someone asks the awkward questions: is this token still valid on the server after logout, does this action check a CSRF token, can I set a victim’s session before they log in. Those questions are what session management in security testing is for, and they take a tester who thinks like an attacker rather than a user.

These two belong together because they attack the same thing from opposite directions. Session flaws let an attacker steal or forge the key. CSRF lets an attacker use the victim’s real key without holding it. Test them separately and you can miss the interaction, so we cover both in one engagement and report how they combine.

We collect many session tokens and examine them for structure and predictability. A token with visible patterns, a short random component, or anything derived from the username or a timestamp is a candidate for prediction. We also check whether the same token is issued before and after login, which is the setup for session fixation.

We drive the session through its whole life and test each transition.

Login and fixation

We confirm the application issues a fresh session on authentication and does not carry the pre-login identifier forward. Where it does, an attacker who plants a known session in a victim’s browser can hijack the account once the victim logs in.

Timeout and logout

We test whether idle and absolute timeouts exist and are enforced on the server, and, most importantly, whether logout genuinely invalidates the token server-side. A logout that only clears the cookie in the browser, while the token stays valid on the server, is a common and dangerous finding.

Replay and concurrency

We capture a token, sign out, and try to reuse it. We open several sessions for one account and see how the application handles them. Tokens that outlive their session, or unlimited concurrent logins with no visibility, both widen the window an attacker has.

We verify the Secure flag so the cookie never travels over plain HTTP, HttpOnly so a script cannot read it, and a sensible SameSite value that limits when the browser sends it cross-site. These flags are cheap to set and frequently missing on the one cookie that matters, and SameSite in particular is a strong first line against CSRF.

We check that each state-changing request carries an anti-CSRF token, and then that the server actually validates it. A surprising number of applications include a token, decorative, and accept the request whether or not it is correct. We remove the token, alter it, and reuse another user’s token to see what the server truly enforces.

Any action that changes data over a GET request is trivially forgeable with an image tag or a link. We look for state changes hiding behind GET, a classic that survives in older and hastily built features.

Even logout can be a target: forcing a victim to log out is a nuisance and sometimes a setup for a fixation attack. We also test whether method-override headers or parameters let an attacker turn a protected POST into an unprotected request the CSRF check does not cover.

A predictable or non-expiring session token, or a fixation flaw, lets an attacker occupy a victim’s authenticated session and do whatever that user can, from reading private data to changing the account’s email and locking the owner out.

A working CSRF against a sensitive action means an attacker can make a victim change their email, transfer funds, alter settings or approve a request, all from a page the victim merely visited. The victim’s own valid session does the damage.

A plain-language read on whether authenticated sessions can be stolen, forged or abused, and what that would mean for your users and your obligations.

Each finding lists the affected mechanism, a CVSS score, business impact, reproduction with request and response evidence, and a specific fix, whether that is rotating tokens on login, enforcing server-side invalidation, setting cookie flags or adding validated CSRF tokens.

After your team applies the fixes we re-test each finding at no charge and confirm the session behaves correctly through every transition.

Session management has a dedicated chapter in the OWASP Application Security Verification Standard, and CSRF maps to the OWASP Top 10. We test against these so your developers get a recognised checklist alongside the findings.

Session and access controls underpin all of these. The report and attestation letter support ISO 27001, SOC 2, PCI DSS and GDPR expectations for protecting authenticated access to personal and payment data. Name your framework and we align the deliverables.

The traditional model, where the cookie holds an opaque identifier and the state lives on the server. Here the risks cluster around token strength, fixation and whether logout actually clears the server record. This is where a “logout does nothing on the server” finding usually lives.

Where the session is a self-contained token carried by the client, logout is harder, because the server holds nothing to invalidate. We test whether short expiry and a revocation mechanism exist, or whether a stolen token stays usable until it expires no matter what the user does. SameSite behaviour and where the token is stored both feed directly into the CSRF and theft picture.

When a session spans several applications behind one login, we test how signing out of one affects the others and whether a session established at the identity provider can be replayed against a service that should have refused it. Shared sessions multiply the blast radius of any single flaw.