My website pages reference some JavaScript code from a third-party CDN (analytics, etc). So I don't control what code is there - the third party may change those scripts at any moment and introduce something bad into those scripts - maybe accidentally, maybe deliberately. Once those scripts are changed, the users start receiving and running new code in their browsers.

What risks are raised by this uncontrolled code? What's the worst thing that can happen? How do I get started with managing the risk?

  • 3
    The worst thing that can happen is that your customers have malicious code injected into their pages, and they get hacked/tracked/etc. It always comes down to your customers/visitors. Commented Feb 18, 2016 at 14:04
  • 39
    If you run someone else's JavaScript on your site, it ain't your site no more.
    – AviD
    Commented Feb 18, 2016 at 14:07
  • 6
    @AviD true to a point but I'm not sure I've ever heard of any site that doesn't have some third party javascript on it. Google Analytics is practically everywhere as an example. If not that then adsense. If not that then some alternative to those.
    – trallgorm
    Commented Feb 18, 2016 at 14:22
  • 8
    Perhaps I am too lenient, but I am voting to keep this post open. Basic security concepts are often lost on many people, and I don't think it's fair to assume everyone is going to know everything. Plus, it offers somewhat of a guideline to those starting out, and a warning about what could happen. Commented Feb 18, 2016 at 14:37
  • 9
    Related: Forbes says no to adblockers..., and then serves up Malware... Why is it related? because third party software (in this case, advertisements) got hijacked to server malware (password stealing). I highly doubt Forbes did it on purpose, but it happened none the less.
    – WernerCD
    Commented Feb 18, 2016 at 19:27

5 Answers 5



In the worst scenario, it could render website completely inaccessible for the users, it could perform particular actions as them (for example, requesting account removal, spending money) or it could steal confidential data.


Can't be done. If you run someone else's JavaScript on your website, it becomes no more secure than that third-party. You have to host it yourself.

You can get closer to the target, however.

  1. One thing may be Content Security Policy. The example setting of header Content-Security-Policy to script-src 'self' www.google-analytics.com;, would prevent execution of scripts served from other domains than your own or www.google-analytics.com. That way if someone would find some cross-site scripting vulnerability (XSS) that would allow them to add their own inline JavaScript code to your website - it would not run.
  2. Other really cool thing is so called Subresource Integrity. It's essentially adding hash sum of JS you expect to run to the integrity parameter you give to the script tag.
<script src="https://example.com/example-framework.js"

You can generate those hashes online at https://www.srihash.org/ or with command:

openssl dgst -sha384 -binary FILENAME.js | openssl base64 -A 

This of course has downsides, e.g. analytics providers may change their scripts and you will have to change integrity parameter to keep them running. It's also pretty new feature (Chrome 45.0+, Firefox 43+, Opera 32+, no IE, Edge or Safari support at the moment), so you lay your client's security on their own software.

See also 3rd Party Javascript Management Cheat Sheet from OWASP.

  • I thought about csp as well, but removed it from my answer, because I don't think it's a viable solution. The OP is worried that the external script (eg at google-analytics.com) is malicious, so your example wouldn't help. It would also not help in the case of most XSS, as inline js comes from self and would thus run (it makes XSS a bit more obvious as the whole payload must be included though). csp also does not really prevent the sending of data to external servers (for that to work, all requests must be forbidden, including things like images, which restricts usability).
    – tim
    Commented Feb 18, 2016 at 14:38
  • It wouldn't help to prevent execution of script from the source that OP intends to include, but it would prevent, as OP called it in the title of this question, "some random out of [my] control javascript". I don't agree on inline JS, however. To run that, you would have to add unsafe-inline to your CSP. Without it, inline JS won't run.
    – Przemek
    Commented Feb 18, 2016 at 14:45
  • You are right about inline js. Still, I don't think that it solves the OPs problem. And most websites have at least some inline js, so in most cases, it's not a viable solution to XSS either.
    – tim
    Commented Feb 18, 2016 at 14:51
  • If google's javascript were to become malicious, or be intercepted through a man-in-the-middle attack, then that's bad-news bears. Commented Feb 18, 2016 at 14:51
  • @MarkBuffalo I don't think so. If the script becomes malicious, it still comes from google-analytics.com, which is allowed by the csp. And a man-in-the-middle doesn't change the origin either, it would still appear to come from google-analytics.com, which is still allowed by the csp and would thus execute.
    – tim
    Commented Feb 18, 2016 at 14:54

What's the worst thing that can happen?

The third party can do anything that you could do with JavaScript - or anything an attacker could do with XSS.

This includes stealing cookies, injecting a JavaScript keylogger, bypassing CSRF protection and thus executing any request you could execute - eg adding a new admin user -, or changing the content of your webpage (eg to inject ads or for phishing attacks).

How do I get started with dealing with the risk?

If you do not trust the intentions or security of the third party, the only proper solution would be to host the script yourself (after you made sure that it does only what you want it to do).

If you do not want to do that, you could add Subresource Integrity to somewhat mitigate the risk:

You add a hash of the script to the include and modern browsers will compare the hash to the hash of the included file. If it doesn't match, the code will not be executed: <script src="https://example.com/script.js" integrity="[hash]" crossorigin="anonymous"></script>. This way, you can make sure that the script will not change. Of course, if it does change, you need to re-check the script and change the hash, as otherwise your website will be broken.


What risks are raised by this uncontrolled code? What's the worst thing that can happen?

Generally, the attacker gains access to anything your authentication methods are meant to protect.

Worst case, assume the code is custom designed for your site. Actions the user takes can be prompted to input security credentials, giving the attacker access to that user's account long after they log out. For a bank account, a bitcoin wallet, or other sites controlling access to assets the attacker will have access to irreversible, high value actions. If there isn't value at the time but they get the credentials to access the account, they can wait until there is enough value in the account to make it worth while.

How do I get started with dealing with the risk?

Good: Set Content Security Policy and Subresource-Integrity on the scripts you host yourself. See @Przemek's answer for more information about those. Not sure if this needs to be said, but all JavaScript should be served over HTTPs; this at least raises the cost of MITM for those resources.

Better: Host the code yourself. But, don't forget to update it regularly. These vendors release security fixes of their own. Don't get left behind.

Best: Review all the source code. Most of the time you can find un-minified versions of the JS which you can read yourself(and eventually just diffs), and then minify and bundle it up with the rest of your sites JS. Obviously this is high cost, weight it appropriately against your site's needs.


What's the worst thing that can happen?

The technical term is arbitrary code execution. In this context, "arbitrary" means "any," as in "anything that it's possible to code in JavaScript could end up running on your site."

Is it possible to use JavaScript to read values from form fields? Yes. Is it possible to use JavaScript to load something from a URL? Yes. Then arbitrary code execution means someone could read a user's username and password as they log in, and transmit them to their own server, encoded as parameters in a GET request. (This provides a neat end-run around HTTPS encryption of your users' login data, BTW.)

Is it possible to use JavaScript to read data on a page? Yes. Then arbitrary code execution means that someone could read a user's private profile data when they access the page that contains it. (And use a HTTP request to report it back to the attacker's server.)

...and so on. An arbitrary code execution vulnerability is considered the worst thing possible from a cybersecurity perspective, because exploiting it means that literally any bad thing that is possible can be performed on your system.

  • JavaScript can be used to transform the page just as well, not only read from it.
    – sharptooth
    Commented Feb 20, 2016 at 7:48

All of the above are worth considering, but to be fair, there are well-accepted development practices as well as built-in protections in modern browsers that protect against the most severe cases noted.

It's also worth noting that there are three ways that third-party code can run in the context (that is, sharing the same browser DOM) as your web pages: 1) JS that you include and render along with your page, e.g. Google Analytics, or 2) Bookmarklets that the user controls (e.g. Spritzlet or Pinterest), and 3) browser extensions or toolbars. The latter two are almost completely out of your control; the first is something you can audit to some degree.

By far the most important thing to ensure is that the web servers you do control that serve and respond to the client (browser, bot, malware) are locked down. XSS, CSRF, SQL Injection and multiple other attack vectors are within your control on the server side. You would have to explicitly allow CORS on your server side, but if you do, make sure you know what you're doing, and be particularly vigilant. This is not to say this stuff is all easy or obvious or anything, but it's entirely independent of whether it the vulnerability is breached via JS or any other method.

Assuming you have protected your web server and locked down the endpoints that can be called, the rest of what goes wrong falls into a different class. JS (and plugins/extensions/toolbars/bookmarklets) can do a wide range of bad things -- keystroke loggers, injection of harmless looking elements that actually send data elsewhere, and so on. All of these are executed by the browser.

If you're serving the JS on behalf of a third party, you should be careful to trust and verify the source. A Google Analytics snippet is probably safe. A third-party ad-serving widget might be worth looking into more carefully. In all cases, the code behind these can be inspected: if the browser can run it, you can see the JS code and decide: is this something you want on your site?

JavaScript is a powerful tool. But in the end, JS is software that the browser execute and so we put a lot of faith in browsers and operating systems that run them to ensure safety. JS is not software that has particular magical abilities to breach your server or make your server do stuff it's not designed to do.

There's little to nothing your site can do that allows JS to arbitrarily execute code on a the user's computer -- it is the user that must have recent updates to browsers and OS, etc. You could detect old versions and post warnings to be a nice guy, but that's about it.

Secure your server, install updates, make sure your code is safe, avoid serving JS from unknown third parties. And then, make sure your site is registered with Google Webmaster Tools which will notify you if your site is hacked in many cases, and if you can afford it, get a service that scans your site for vulnerabilities.

You must log in to answer this question.

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