Today I've found interesting site that output your cookie value directly to the page, so if I modify the cookie value I can XSS myself.

e.g <span id=statistics>Last visit: Cookie_Value_Of_Something</span>

So my question is, do you think this is vulnerable or can I exploit this?

It looks like useless to me so far.

  • What kind of cookie is that?
    – Gumbo
    Commented May 19, 2013 at 6:16

7 Answers 7


To exploit this flaw, the attacker would need to manipulate the user’s cookie. And this is only possible if he is able to exploit another vulnerability that allows him to set the cookie with the XSS payload as one can only set cookies within the domain the Set-Cookie originated from:

The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server. For example, the user agent will accept a cookie with a Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com".

And besides compromising the server, there are two possible attack vectors for manipulating the cookie value: Either the attacker manages to inject the exploit into the value that gets set as the cookie value by the site author’s script, e.g., some user provided values are used for the cookie value. Or the attacker has access to a sub-domain and he is able to set a cookie for the super-domain in which vulnerable script that prints the cookie value resides. Both vectors can be executed by using Cross-Site Request Forgery.


It's not exploitable in itself, but it's a potential escalation path for an attacker to go from cookie fixation to full XSS.


  1. If the site is running on a hostname that has neighbour domains, any XSS attack on those neighbours means a cookie can be written to the shared parent domain, escalating to an XSS attack on the site. eg. from untrusted-uploads.example.com they can write a cookie with domain example.com, which will be read by trusted-www.example.com.

  2. If the site is running on https://www.example.com/, an attacker can still spoof a site at http://www.example.com/. Any cookie set from there will be readable from https - script at https would not detect that the cookie was not created with secure. So cookie-XSS makes HTTPS ineffective (except where foiled by Strict Transport Security, but that's not a complete defence).

It's not really possible(*) for a script (either server or client side) to detect that the domain, path, secure or httponly flags on the cookie match the values expected, which means you can't reliably detect injection of cookies from outside your site.

(*: there are potential hacks where you attempt to override a cookie by setting a new one with the flags you want, but ultimately it's not completely reliable as the attacker script could be running at the same time.)


Once upon a time flash was vulnerable to CRLF injection (IE was also vulnerable), and this could have been used to set the Cookie: HTTP request header to exploit cookie-based XSS. But this is no longer the case. It is not possible to set a Cookie on another domain. If you could set cookies for other domains it would make session fixation very difficult to prevent (if not impossible).


It's useless. Due to the same-origin policy, text on a page cannot be read by other sites, just like cookies.

It is readable by an attacker running an MITM attack, but so are the cookies (unless the connection is HTTPS).

  • HTTPS connections are readable as well. crypto.stanford.edu/ssl-mitm Commented May 19, 2013 at 17:07
  • @AbsoluteERØ: Yes, but that involves a certain degree of stupidity on the victim's behalf. At one point security boild sown to the user, it's hard to make any efforts beyond that. Commented May 20, 2013 at 3:23

The only real attack vector would exist in a situation where there is another vulnerability. For example if you could upload an executable script such as some PHP code you could manipulate the cookie using that script to inject some JavaScript into the users session. You would also need to perform the usual social engineering to get the user to visit your uploaded script.

  • 1
    If it were possible to upload a PHP or HTML file, the attacker could print out the JavaScript directly without the need to exploit the XSS vulnerability via cookie. And in case of PHP, he could certainly prepare any file on the site to deliver his exploit.
    – Gumbo
    Commented May 19, 2013 at 6:07

It depends on which cookie is been output.

Some sites write 3rd party data into cookie values (have a look at Facebook's reg_ext_ref cookie for anonymous user, it's full referrer). Can believe some sites do store last search query that user typed in or something like that (and sometimes you can forge that last query with GET-params). So, if at least one of that-like cookies is being output, you should try to exploit this.

I'm not saying your case is a good attack vector, it's just worth some investigation.


Nota bene: I'm commenting on this ticket after all this time as this is still one of the top answers on google for is cookie xss exploitable.

The answer is that depending on context, then cookie XSS can often be exploited. Some routes to achieve this are (doesn't pretend to be fully comprehensive):

  • injecting the payload into whatever sets the cookie in the first place;
  • injecting the payload directly into the vulnerable endpoint via request header injection;
  • injecting the payload directly into the vulnerable endpoint and poisoning the response (shared cache poisoning or cache deception);
  • injecting the payload indirectly into the vulnerable endpoint via response header injection (this can be via any peer domain which can set a TLD cookie);
  • Hey schroeder, can you please back out your edit? It hasn't added anything, and has instead removed context, and also broken the grammar. Not a winner. ;)
    – Buffoonism
    Commented Aug 25, 2023 at 11:04

You must log in to answer this question.

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