What Is Session Fixation?

Session fixation is a flaw in which an application authenticates a user without replacing the session identifier the browser already holds, so an identifier in the attacker's possession ends up carrying the privileges granted at login. MITRE records the weakness as CWE-384, where the fault is a step the application omits at the moment a session changes status.

CWE-384 is recorded as a composite, a form reserved for a vulnerability that needs several distinct weaknesses present at the same time. Three such weaknesses are named on the entry.

Why the Catalog Files It as a Composite

An origin validation error is one component, where a product fails to verify that data or a communication came from a valid source. Another is the unintended proxy or intermediary, carrying confused deputy in its title. The third is external control of an assumed-immutable web parameter, which covers a web application trusting values it believes cannot be altered, cookies among them. All three are ordinary CWE entries with lives of their own outside this composite.

Removing any one of the component weaknesses eliminates the risk or sharply reduces it, by the catalog's own definition of the structure. That arithmetic gives three independent points at which a session fixation attack can be broken.

Mapping guidance on the entry points in two directions at once. The ID itself is allowed for mapping real vulnerabilities. The comment attached to it still asks for root-cause analysis so a finding lands on whichever weakness permitted the fixation. A predictable identifier is the example given, better described as a randomness problem.

Research has not concentrated on attack-oriented composites, by MITRE's own account, with the same note allowing that later work may change or deprecate them. Both ordinalities appear on the entry as well, since the weakness can stand alone or follow from another.

Session Fixation vs Session Hijacking

Timing separates the two, specifically the point at which the attacker comes to hold the identifier. Fixation runs forward, because the attacker holds the identifier before the victim ever authenticates. Session hijacking runs the other way, starting from an identifier already issued to somebody else.

Seven attack patterns are mapped to the entry, not all of them describing fixation. Reusing session identifiers, listed under the name session replay, sits in that set beside session fixation itself. The catalog therefore does not treat the two as rival routes to one session, which puts the real difference in what each one costs the attacker. For fixation, the main obstacle is recorded as inducing the victim to authenticate with an identifier the attacker knows in advance.

How the Identifier Reaches the Victim's Browser

Setting a cookie in somebody else's browser is the step that makes the rest work. The technique recorded as most common runs through HTTP response splitting or cross-site scripting in the target site. Either flaw reflects code back to the browser, and the reflected code writes the cookie holding the chosen identifier. Both are cataloged among the types of web application attacks.

Cookie scope widens, opening well past the vulnerable page. The example given puts a recipes site and a bank under one parent domain. A flaw in the minor one lets an attacker set a cookie that every application sharing that domain will use.

Where the identifier travels in the URL, no scripting flaw is needed at all. Session management that accepts an identifier in the URL as well as in a cookie lets an attacker fix the value by sending a link. It is the cheapest of the routes recorded.

Network-level routes are recorded on the entry too, DNS poisoning among them. Those typically need the attacker physically present on the victim's network, or in control of a machine already compromised there, which the note says makes them harder to run remotely.

Impact Recorded Against CWE-384

One consequence is recorded against CWE-384, the gain of privileges or assumption of an identity, under access control. The single row fits the mechanism, since the weakness grants an identity rather than exposing or altering data by itself. What the attacker ends up holding is a session the application believes belongs to the person who logged in.

The entry's public terminal scenario names three conditions the attacker needs, an unmonitored machine, a session kept alive, and a victim who happens to want that site. The write-up presents them as limits on the attack. The curated example list carries a single CVE record, CVE-2022-2820, against web software built for game servers that did not terminate user sessions properly.

How Is Session Fixation Prevented?

Federal digital identity guidance states the fix as a requirement rather than advice. Section 5 of NIST SP 800-63B-4 is marked normative and has been final since July 2025. It holds that the secret binding a session "SHALL be generated by the session host in direct response to an authentication event." An identifier that predates that event fails the requirement on its face.

Session secrets have to be set at authentication or immediately after it, drawn from an approved random bit generator, and no shorter than 64 bits. That length requirement answers the predictability route, recorded on the page as one way session fixation becomes possible.

Invalidating the identifier already in play is what the catalog's own mitigation asks for, before a new user session is authorized. The federal requirement governs the other half of that same transition, how the replacement gets generated. An application firewall appears as a third option, rated moderate, with the caution that it may miss input vectors and may be bypassed.

When the login path belongs to a framework, the omission is not in application code. Example 2 on the page is a direct POST to a container login endpoint that typically handles the login request without first invalidating the session already open. The defect therefore sits outside what a review of the application's own code would see.

Authentication changes what a session is allowed to do, so the identifier carried across that change decides who holds the result. Raven Runtime Prevention watches what a session does while the application runs, catching a request that arrives on an identifier the application never issued at login. Book a demo to see that on a running application.