Is it correct to use form field(hidden) for storing Session Token instead of using Cookies? What is the security risk associated with it?

  • Do you mean session ID or anti-CSRF token? Both of these have different purposes. Commented Nov 23, 2011 at 11:05

4 Answers 4


To be protected against CSRF while also hardening against XSS, store your session IDs in cookies (with httpOnly flag) and use separate session-bound form tokens that you validate upon POST. By combining these methods, you prevent an attacker that has found XSS from stealing session IDs, while you still protect against CSRF in a meaningful way. Using the session ID as form token enables an attacker to steal the session ID through XSS.

  • If there is a XSS vulnerability, it’s also vulnerable to CSRF. Frankly, XSS would remove the cross-site from CSRF.
    – Gumbo
    Commented Nov 23, 2011 at 21:58
  • Yes, if there's XSS, all is lost. You should still harden against both though.
    – chris
    Commented Nov 24, 2011 at 6:19

IMHO, by far the biggest disadvantage is that you need to explicitly add code to repopulate the session identifier into each and every page, potentially in multiple places. Using a form field is only going to work where you've got a form and that's the only way to navigate off the page.

So you also need to add code to parse every href on the page and add the session id (since you don't want to send your session id to other sites).

What about ajax requests? Javascript driven navigation?

You should also be change the session id at authentication - so you've also broken the behaviour of the back button.

Yes, you can solve all these problems by throwing code and effort - but more code = more bugs = less security.

Another consideration is that some applications use multiple session identifiers - managing this outside of cookies would be an even bigger PITA.

  • You did not cover the inherent security risks of session tokens in HTML content. That is a serious problem. Session tokens can be protected from XSS attacks by being placed in HttpOnly Cookies. See Krzysztofs answer.
    – freddyb
    Commented Nov 22, 2011 at 17:12
  • @freddyb: see comment on Krzysztifs answer
    – symcbean
    Commented Nov 23, 2011 at 9:52

No, you should not use GET or POST parameters for session identifiers. Session ID should only be transmitted via HttpOnly cookies.

There are at least three reasons for doing so:

  • Session Fixation attacks. The attacker can entice victim user to visit a page with a form containing his session id in a hidden field. Submitting the form will have the victim being authenticated as attacker (and any actions he later on performs on the target website will be done with attackers' credentials)

  • any XSS flaw in your website will directly allow the attacker to hijack the session whereas storing session id in HttpOnly cookies prevents that from happening

  • content extraction attacks - there are a few UI redressing techniques for extracting the HTML content of a target website, therefore leading to hijacking user's session. One example of such attack requiring user interaction is Facebook token access extraction, which involves displaying the HTML source of a victim website in an invisible IFRAME and enticing the user to select it and drag it out to attacker's textarea; if the session ID is included in the HTML document, then this reveals the session ID to the attacker. Also, when the website allows cross domain communication (e.g. with using permissive crossdomain.xml), content can also be retrieved via Flash without user interaction. Therefore, the session ID should never be displayed within the HTML page source.

To stop CSRF, it is important to also include a CSRF token in a hidden form field or in the URL of every POST request. However, the CSRF token does not need to contain the session ID, and it is safer if it does not contain or reveal the session ID. A safer choice is to use a random nonce or a one-way hash of the session ID as the CSRF token.

  • 2
    Session fixation is not solved by using cookies - while it's easier to carry out an attack using a session id in a URL, just using cookies (regardless of the flags) does not help. But agreed that using httponly avoids XSS. I don't understand the point about content extraction (except that it is facilitated by XSS)
    – symcbean
    Commented Nov 23, 2011 at 9:57
  • 1
    Session fixation is fixed by using cookies (unless there's a XSS / Man in the middle) because the attacker cannot plant a cookie of known value to third-party domain (cross-site cooking was a browser vulnerability that is now fixed). See e.g. owasp.org/index.php/Session_fixation Content extraction is not about XSS, it's a UI redressing attack (e.g. entice user to select HTML source of victim website displayed in invisible IFRAME and drag it out to attacker's textarea, revealing session id displayed in source). You can also get the content with Flash if crossdomain.xml allows it. Commented Nov 23, 2011 at 11:12
  • @D.W. There are good reasons why session identifier should never appear in response body of a website, there are several attacks that may extract session id from that (XSS, content extraction and e.g. Cross Origin Resource Sharing or third-party Flash request if website allows this). I totally agree on the need of having CSRF protection using nonce tokens and these can be in URL/form, but nonces are not the same as session IDs, so I don't understand why you say that session_ID need to appear in form/URL when implementing CSRF tokens. Could you clarify that? Commented Nov 23, 2011 at 11:33
  • Krzysztof, you are right. I agree that it is better for the CSRF token to be a random nonce or something derived from the session ID, rather than the session ID itself. I didn't realize that was the point you were making -- now that I do, I completely agree with you. My fault. Sorry about that. I made an edit to try to incorporate your explanations into your answer itself.
    – D.W.
    Commented Nov 23, 2011 at 16:46
  • @Krzysztof: "unless there's a XSS / Man in the middle" - exactly. Another way to abuse this (other than 3rd party cookies) is to set the cookie normally set in HTTPS (regardless if its secure/httponly) over HTTP via MITM. The solution to session fixation is to change the session id when the server side data has expired / when (re-)authentication takes place.
    – symcbean
    Commented Nov 25, 2011 at 9:20

Three common approach for transfer of Session Identifier between Browser and Server

  1. Cookie
  2. Hidden Fields
  3. URL

All have their advantages and disadvantages, but since you asked about Hiddel Fields only here are few advantages and disadvantages

  • Adv: Less prone to CSRF as Session Identifier will not travel in Cookie and will not be implicitly sent by browser
  • DisAdv: If developer uses a GET method or appends parameter to URL your session identifier would be exposed in browser history, proxy logs, web server logs etc.
  • DisAdv: Session identifiers being cached along with the page if caching is not disabled
  • Adv: Dont have to worry about marking cookie secure or HTTPOnly etc or worrying about expiry of cookie
    • DisAdv: you have to send it back in all responses, increasing size of your response
    • Adv: Don't have to worry about Cookies being disabled on user browsers

Thats what I can think of right away, may be others can point more advantages and disadvantages

And yes I am assuming you have your Server Side Session Tracking and management code and logout logic written correctly

  • Another disadvantage/advantage, can't keep the seesion between browser restarts or even browsing somewhere else and back again. And as said, either way, to be secure the code does have to be written properly.
    – ewanm89
    Commented Nov 22, 2011 at 9:30
  • 2
    Session identifiers are not meant to protect from CSRF. Use unique tokens (nonces) for that. I also don't see how "Dont have to worry about marking cookie secure or HTTPOnly etc" is an advantage. HttpOnly was introduced to protect from Session Hijacking when XSSed, and POSTed session ids completely fail to secure against that. That's a disadvantage, and a big one. Commented Nov 22, 2011 at 12:43
  • 2
    Session Identifiers are not meant to protect from CSRF agreed, but I never said that it will protect you from CSRF what I said is that you are less prone to CSRF.Since there is no session identifier in cookie, a request to the domain from a new browser window or tab will not by default carry the user session id and hence server will not process the request. Since there are is no session identifier cookie you dont need to makr the particular cookie anything . Please also mention the reasons for Downvotes, would really help in clearing the understanding Commented Nov 23, 2011 at 7:14
  • @SachinKumar what you're saying is that you are less prone to CSRF and compare that to situation where session ids are in cookies and there are no separate CSRF tokens (no sane CSRF protection at all). That's not a fair comparison. There is a state-of-the-art protection from CSRF (id in cookie, unique token linked to the session in POST/GET) and it should be used as a comparison. Session ids in POST are not better for CSRF protection here. Commented Nov 23, 2011 at 11:44
  • 1
    I don't know about others, but you got my downvote for ignoring httponly benefits and puttting it as if it was a disadvantage. Commented Nov 23, 2011 at 11:52

You must log in to answer this question.

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