I'm applying for a program through organization X's website. I logged in, and was astounded to find a URL like this:


80 characters in [0-9a-f] gives 1680 =~ 2.14 × 1096 combinations.

So I deleted the hash and reloaded the page, lo and behold, I got a 403 Unauthorized response. Changing the hash also causes a 403. Lastly the hash changes on re-login, so I think it's safe to assume that a hash is generated, stored in the database for the user, and then appended to the querystring and checked on page load to find the correct user record in the database.

All pages inside user-specific pages require the session parameter to be correct. I don't know if/when login expires, I haven't sat around idle to find out.

To verify that this is a problem, I opened a new incognito window, copy/pasted the URL, and I had access to my account and application information.

Some problems that I can think of:

  1. Copy/pasting your live session through URL sharing
  2. The URL could be bruteforced (though it would be pretty hard to stumble across a valid hash)
  3. The URL is in various logs (firewall, server, 3rd party aggregating services, etc.)

What are the risks of storing a user's session in querystring parameters?

  • 1
    It's worth heading over to stack overflow and reading this post security.stackexchange.com/questions/14093/…
    – iainpb
    Jan 11, 2017 at 16:18
  • Not the best but: 1. would only work for session lifetime. 2. probably not a problem,given the length and how easy it is to rate limit. 3. the details would only appear in the site's own logs, https hides the queryString.
    – dandavis
    Jan 11, 2017 at 18:13

3 Answers 3


This used to be a common usage in the old time when clients did trust neither web sites nor web browser for their security and privacy and consistently refused javascript and cookies. As HTTP is a non connected protocol, the session must use some piece of data to pass the session id between the client and the server. That means the if you cannot use cookies for GET requests, you are just left with an URL parameter. That was implemented in many web applications as session through URL rewriting.

It is now seldom used, because browsing most site while disabling cookies is simply impossible. So users have been educated to consistently allow cookies in their browsers.

On a security point of view, passing the session id in the URL is not worse than passing it in a cookie: if someone (except for the user itself) can intercept the URL, he can as well intercept the cookie. And session fixation is not easier with URL than with cookies: it is the problem of the server than should invalidate old session ids, and create a new one after a successful authentication. Logs is not a problem either: a session id make sense only for the duration of the session and is not a long term sensitive information. The only place that could cause problems is cross site requests of redirections. In that case, the REFERER header could contain the session id. So a well designed application using URL rewriting for its sessions, should consistently store the client IP in the session server side, and control that the session ID and client IP match.

TL/DR: That usage is known as session through URL rewriting. It is now seldom used because session through cookies are much more common. The problem is not security because the security of an URL parameter is not different than the one of a cookie, but that extra parameter is displayed in the browser bar, and can intrigate a user, or require removal for storing an clean URL as a bookmark.


Between your own list of potential issues and iain's link, there's not much left to be said. The fact that the session worked in an incognito window would mean that cookies are not involved in authentication. This leaves a hefty chance for session fixation. If nothing else, the kind of fixation where the bad guy crafts a link with HIS OWN session token and tricks the victim into visiting that and saving sensitive info.

Additionally, this would mean that the application is either using GET for all its update transactions or is using POST with URL parameters. Neither of them are considered great practices (see this link for more details). Odds are the application is violating method idempotence.

Summary of possible ill-effects:

  • Logs of all kinds potentially recording session tokens
  • Potential violation of HTTP method idempotence
  • Session fixation

Playing devil's advocate, it seemed to me that one temptation behind this design could be CSRF protection. Without cookies involved and traffic being SSL-protected, this might have an effect that is akin to CSRF protection. The attacker doesn't have the long hash needed to craft the right URL and no cookies involved.


As long as the site is secured using HTTPS, all queries in the URL are sent encrypted aswell - so there shouldn't be anything that could expose the query between your PC and the server. The only problem I can think of here, is, that you could accidentally send it to other people via copy/paste or screensharing.

  • 1
    That was point #1 in the problems I mentioned. Jan 11, 2017 at 21:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .