Session fixation persists mainly where the framework leaves session id rotation to the developer

Hypothesis

In a session fixation attack the attacker sets a session identifier in the victim's browser before login (through a link, a cookie on a sibling domain, or an injection), waits for the victim to authenticate under it, and then uses the same identifier. The OWASP Session Management cheat sheet (cited) states that regenerating the session id after any privilege change, above all at authentication, is mandatory to prevent the attack, and lists the framework calls that do it. Frameworks differ in whether that call happens for you. Spring Security's reference (cited) says it protects against fixation automatically by creating a new session or changing the session id when a user logs in, with changeSessionId as the default on Servlet 3.1 and newer containers. In PHP the manual (cited) documents session_regenerate_id(), which replaces the current id and keeps the data, but the session extension knows nothing about "login"; the application must call it at the right moment, and the manual's own examples show that doing so robustly (delayed destruction of the old id, races on unstable networks) is not trivial. The hypothesis: the prevalence of session fixation is governed by that default, not by developer awareness, and hand-written login code on stacks without automatic rotation will keep producing the finding.

Prediction

Across a sample of applications tested with the same method (log in with a pre-set session cookie, check whether the identifier changes), the share with fixation findings is several times higher for applications whose login is built on a session API without automatic rotation than for those on frameworks that rotate by default; within the second group, the residual findings come from custom login paths that bypass the framework's authentication handler (SSO callbacks, API token exchange, "remember me").

Proposed test

1. Select open-source web applications across stacks; classify each by whether its framework's login helper rotates the session id by default (from the framework documentation) or whether rotation is a separate call.
2. For each, run the same fixation check against a local deployment; record whether the id changes at login, at privilege change and at logout.
3. Compare finding rates between groups; inspect the residual findings in the auto-rotating group for bypassed login paths.
4. Optionally repeat with penetration test report corpora that name the stack.

Status

No result claimed. Confounders: stacks differ in age, ecosystem maturity and the kind of application built on them; applications with token-based stateless sessions have no server-side id to fixate and must be excluded; a framework's default may have changed between versions, so the version in use must be recorded.