Why must session IDs be input-validated like any other user-supplied value?

Question

Accepted Answer

Because the session ID arrives from the network as a string the user controls — an attacker can put anything in it, including SQL-injection payloads or XSS scripts, to attack the code that processes it.
A naive backend might do:
SELECT * FROM sessions WHERE id = '<session-id-from-cookie>';

If the cookie value isn't validated, the attacker can set it to ' OR 1=1 --  and exfiltrate the entire session table. Same risk if the value is logged unsanitized into an HTML admin dashboard (stored XSS) or echoed in an error message (reflected XSS).
Mandatory checks:

Format — session IDs from your CSPRNG have a fixed length and alphabet (often hex, base64url, or alphanumeric). Reject anything that doesn't match: ^[A-Za-z0-9_-]{43}$ is a typical regex.
Existence — even if the format is valid, only accept IDs that exist in the server-side session store. Fabricated IDs should fail closed.
Binding — optionally bind sessions to other request signals (User-Agent, IP) so a hijacked cookie used from a different context fails.

The rule: "Session IDs must be validated like any received value." The corollary: never concatenate a raw cookie value into a SQL string, an HTML page, or a shell command.
Tip: Parameterised queries (PreparedStatement, $db->prepare, Django ORM) make this automatic — even if you forget to validate format, the value can't break out of the query string. Use them.