SessionIdInUrl [anti-pattern] v0.1.0

Carrying the session identifier in the URL — query string, path segment, or fragment — instead of in a cookie. Variants include ;jsessionid=… URL rewriting and 'magic link' flows that include a long-lived session token in a shared link.

Label

Putting the session id in the URL (?sid=…, /sessions//…)

Why Bad

URLs leak. They land in browser history, server access logs, proxy logs, Referer headers sent to every linked-to third party, screen captures, copy-pasted into Slack, and bookmarks. Each of those is a session-hijack vector. Cookies have HttpOnly and Secure flags; URLs do not.

Instead Do

    Carry the session id in a Set-Cookie with Secure + HttpOnly +
    SameSite, never in the URL. If you need a one-time token in a link
    (password reset, email verification), make it:

      • single-use (consumed on first redemption),
      • short-lived (15 min for reset, 24 h for verify),
      • bound to one user and one purpose,
      • cryptographically random (≥ 128 bits),
      • exchanged for a real session cookie on the server, then invalidated.
  

SessionIdInUrl [anti-pattern] v0.1.0

Carrying the session identifier in the URL — query string, path segment, or fragment — instead of in a cookie. Variants include ;jsessionid=… URL rewriting and 'magic link' flows that include a long-lived session token in a shared link.

Label

Putting the session id in the URL (?sid=…, /sessions//…)

Why Bad

URLs leak. They land in browser history, server access logs, proxy logs, Referer headers sent to every linked-to third party, screen captures, copy-pasted into Slack, and bookmarks. Each of those is a session-hijack vector. Cookies have HttpOnly and Secure flags; URLs do not.

Instead Do

    Carry the session id in a Set-Cookie with Secure + HttpOnly +
    SameSite, never in the URL. If you need a one-time token in a link
    (password reset, email verification), make it:

      • single-use (consumed on first redemption),
      • short-lived (15 min for reset, 24 h for verify),
      • bound to one user and one purpose,
      • cryptographically random (≥ 128 bits),
      • exchanged for a real session cookie on the server, then invalidated.
  

Label

Putting the session id in the URL (?sid=…, /sessions//…)

Why Bad

URLs leak. They land in browser history, server access logs, proxy logs, Referer headers sent to every linked-to third party, screen captures, copy-pasted into Slack, and bookmarks. Each of those is a session-hijack vector. Cookies have HttpOnly and Secure flags; URLs do not.

Instead Do

    Carry the session id in a Set-Cookie with Secure + HttpOnly +
    SameSite, never in the URL. If you need a one-time token in a link
    (password reset, email verification), make it:

      • single-use (consumed on first redemption),
      • short-lived (15 min for reset, 24 h for verify),
      • bound to one user and one purpose,
      • cryptographically random (≥ 128 bits),
      • exchanged for a real session cookie on the server, then invalidated.