I have a webpage that returns raw script code with the headerContent-Type: text/javascript. However I found that there is a reflective xss in one of the parameters passed to the url which is copied into the returned javascript. This is the setup.





Now the XSS I've come up with goes like this





To make it clear, the values of parameter p2, is used unsanitized in the returned script, as the function name.

The HTTP response does have Content-Type: text/javascript, in it. And the script is not embedded within an html document.

Is there any chance that the code can be executed in a browser? I'm worried about old browsers and such basically. Assume that X-Content-Type-Options: nosniff is not set, is there any browser which will actually render it? If so can I get a PoC or a browser version to test?

Edit: The question is, will any version of any browser, sniff a raw script code with Content-Type: text/javascript header set, given that X-Content-Type-Options: nosniff is not set.

  • It depends how the file is used on your website. If you are using the file as an external script, then assuming there are no other vulnerabilities on your website, it should be safe. But, in that case, why would you not just link to a complete file without the parameters.
    – Anonymous
    Commented Jan 3, 2016 at 18:16
  • I'm not worried about self XSS. My issue is if a raw script code be rendered in the absence of X-Content-Type-Options: nosniff. If so which browsers may be facing such an issue. Commented Jan 3, 2016 at 18:21

3 Answers 3


First of all, text/javascript is outdated and, consequently, less reliable. The accepted official MIME type for JavaScript is application/javascript. Any of the major modern browsers should know how to handle the latter by not executing it when visited directly.

With regard to the security vulnerabilities present in Internet Explorer, JavaScript MIME types seem to be unaffected. In an article by Microsoft about MIME type detection, there are clearly defined recognized types, where JavaScript is nowhere present. This means that Internet Explorer will automatically use whatever is returned from the server:

If the "suggested" (server-provided) MIME type is unknown (not known and not ambiguous), FindMimeFromData immediately returns this MIME type as the final determination. The reason for this is that new MIME types are continually emerging, and these MIME types might have formats that are difficult to distinguish from the set of hard-coded MIME types for which tests exist.

Google Chrome tends to emphasize forward compatibility as well, so presumably, a similar process would occur.

Therefore, a script sent with Content-Type: application/javascript should not be vulnerable to type sniffing, but this does not mean that necessary precautions should not be taken to make sure that this does not happen. People may be using less reliable browsers or may view a file in a context other than a browser that does not correctly recognize MIME types.

It would be best to always use X-Content-Type-Options: nosniff since this case is exactly what it was designed for.

  • wouldn't using application/javascript create an issue? ie. outdated browsers won't understand application/javascript right? so they'll go ahead and sniff and execute the javascript right? Commented Jan 5, 2016 at 18:34
  • 1
    @mystupidstory Browsers are designed to be forward compatible. If they don't understand something, they should take precautions to make sure that something reasonable happens. As mentioned above, lower versions of Internet Explorer don't sniff when the MIME type received is parsable for this very reason. It is likely that the "precautions" would be to ignore any attempt to execute the file, which I imagine would be fine. It is more important that modern browsers know exactly how to treat the file: text/javascript is not future-proof.
    – Anonymous
    Commented Jan 5, 2016 at 19:18

The question is, will any version of any browser, sniff a raw script code with Content-Type: text/javascript header set, given that X-Content-Type-Options: nosniff is not set.

For executing the script inside the browser it will not matter if the type is sniffed or not. If only the script itself is given to the browser, that is it is not embedded somehow into HTML, then the browser does not have a document where the script can run. That means the script will be displayed or downloaded but not executed within the context of an HTML document. If you use Internet Explorer it might also offer the script for execution, similar to other executable content. Some tests with IE11 show that it does not matter what the Content-Type is in this case, because either the data will be shown inline (text/plain, images) or it will be offered for download and maybe execute. If execution is offered seems to depend solely on the file extension and X-Content-Type-Options: nosniff seems to have no effect on this decision.

If the script is embedded or referenced from inside a HTML document the content-type mostly does not matter at all because the browser "knows" what the content must be (i.e. Javascript) and will usually ignore the Content-type set by the server anyway. Thus you can successfully deliver a Javascript file with a content-type of text/plain, application/octet-stream and even image/gif to most browsers. From the browsers I've checked a while ago only newer versions of Chrome will exclude some content-types, i.e. it is no longer possible to include script with a content-type of image/whatever into Chrome. It still works with other browsers.


Old versions of IE will treat it , if you embeded it in a script tag it will be rendered and executed

  • Why do they require the script tags? Commented Jul 9, 2016 at 3:24
  • @mystupidstory: As other answers stated, raw JavaScript will just be displayed, and not run by the browser. I think that this answer author's idea is to add <script> tags around your injection in order to trick the browser into thinking this is some HTML code (and not raw JavaScript anymore) and therefore interpret it as HTML and run your injected code (the rest of the JavaScript raw file will still be displayed though, not interpreted). Commented Jul 9, 2016 at 15:59
  • that makes sense. any way to emulate the same in a safe way? i'm not going to install an old version in my os and do not have any windows vm lying around. Commented Jul 12, 2016 at 6:12

You must log in to answer this question.

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