CWE-6 covers a J2EE application configured with a session ID that is too short. A session ID is the token that tells the server which logged-in user a request belongs to. If an attacker can guess or steal it, they become that user.
MITRE puts the logic plainly: the number of possible session IDs grows with the ID length, so longer IDs are harder to guess or steal. Shrink the ID and you shrink the search space.
How it happens
Session ID generation in a Java web stack is handled by the container, and its length is a setting. A team might lower it to save a few bytes in cookies, copy an old configuration forward, or accept a default without checking whether it still meets current guidance.
The weakness is in the configuration, not in the application logic. The login code can be perfect and the session still falls to guessing if the token space is small.
What an attacker gains
The consequence MITRE lists is access control: gain privileges or assume identity. If an attacker guesses an authenticated user's session identifier, they take over that session. For an administrator account that means administrator access.
How to find it
Review the container or framework setting that controls session ID generation. Then look at real values. Collect a sample of session cookies from your own test environment and check that they are long and show no obvious pattern. A short or sequential token is a red flag worth escalating.
How to fix it
- Use the container's default secure random generator and do not shorten the ID.
- Confirm the length against current guidance from your framework vendor.
- Rotate the session ID at login so a pre-login token cannot be reused.
- Set cookie flags so the ID is not easily stolen in transit or by script.
Length protects against guessing. Theft needs separate controls, which is why the cookie flags matter.
Quick check
Does a longer ID stop session theft?
It stops guessing. Theft through a network sniffer or a script injection is a different problem, handled with transport encryption and cookie flags.