It's known that the secure practice of setting a session cookie is using Set-Cookie header with Secure and HttpOnly flags. But is there any security issues with sending cookie inside the HTTP response (and request) body? For instance, like this:

HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 09:23:37 GMT


And what if I set cookie using Set-cookie AND also send in the HTTP response body in the same HTTP response, would that lower security somehow?

  • Why would you want to do this?
    – Anders
    Commented Sep 26, 2016 at 14:09
  • 2
    I don't, but I identified website which does that and would like to know if that's insecure. Commented Sep 26, 2016 at 14:16
  • One disadvantage is that you can not use HTTP-only, which means that the session ID can be stolen in an XSS attack (if there is an XSS vulnerability). Perhaps there are more downsides. I can see no upsides.
    – Anders
    Commented Sep 26, 2016 at 14:21
  • @Anders if what you said is true, then it's obvious vulnerability, but I couldn't find a way to get a HTTP body using Javascript (like document.cookie does). I am also not a Javascript programmer so maybe I am missing how to. Commented Sep 26, 2016 at 14:28
  • 1
    How to do it depends on where in the response it is - is it in the HTML, in JS, or is this perhaps not a webpage at all? What you can always do, though, is making an AJAX request for any page containing the session ID and then read it from the response.
    – Anders
    Commented Sep 26, 2016 at 14:42

1 Answer 1


Setting cookies in the body

You cannot set cookies in the response body (browsers don't look there for cookies), nor can your browser present cookies in the request body (the server won't look there). Cookies by definition are carried in the HTTP header (see RFC 6265).

Putting secure data in the body

You can certainly send other session data or tokens in the request or response body (e.g. it is common to pass a CSRF token in the body), but if you do so they are not cookies. Whether this is a good idea is a different question.

Most data is OK in the body, after all that is the only part that the user can see and sometimes the user needs to be shown sensitive data.

However, some data is not OK in the body. Anything that you wish to make unavailable to an XSS attack, for example, must not be in the body, and should only be contained in an Http-only cookie so that it cannot be read from the DOM.

That being said, some data is better off in the body! For example, anything that you don't want to show up default IIS logs should be placed in the body. Anything you do not want included in a session riding forged request (a.k.a. CSRF) should be included in the body and not as a cookie.

Setting data in both

It is not necessarily a security problem to set a token in both a cookie and the body. In fact this is exactly the pattern required by the Double Submit Cookie CSRF mitigation.

On the other hand, if you are just passing the session ID in the body for the heck of it, and it is a duplicate of an HttpOnly cookie, then you have just nullified any benefit of using the HttpOnly flag, since the same value can be read from the DOM.

Also, here's something really fun: If the site sets an HttpOnly cookie from the server side, and the same cookie value is passed via the page body and set via client script, your browser will end up with two cookies with the same name! This condition should be avoided because there is no HTTP specification that states which cookie should be presented in this case, and browser behavior will vary.

  • 1
    Well you can set cookie normally, and then just send a copy of a cookie inside the HTTP body, can't you? :) Commented Sep 26, 2016 at 14:54
  • While you are completely correct, I feel that this would have been better as a clarifying comment than as an answer. Perhaps repost it as a comment instead?
    – Anders
    Commented Sep 26, 2016 at 17:56

You must log in to answer this question.

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