2

I am researching about the 3rd party tools to use in a project, and I haven't found any conclusive evidence about this:

Is it better* to include 3rd party scripts with a <script> tag or to host them locally? Where better means it will likely affect to a smaller number of users.

I was able to find the best security practices for each case, but not information about which one is a better practice. These are the main pros/cons as a difference that I could find for an external script:

  • The 3rd party hacked: all their clients are vulnerable now.
  • Automatic security update: all the clients are secure now.

Setting up the integrity tag seems a lot more similar to self-hosting as you are locked to a specific version. Also, if the host is down then their script is down. So from a security point of view, an external script with a checksum seems to be equally secure, with more downtime.

So it really seems to boil down to how much you trust the 3rd party updates to be benign or malicious AND what is your company response time.

My thinking is, if you have a 24/7 security response team, actively monitor all your 3rd parties AND do a security assessment of any new code then it might make sense to actually host it yourself to reduce the risk of them being hacked (while increasing response time). Otherwise, it makes more sense to let the company host it, since their response time will be much lower than the combination of their response time + the company response time.

So, what is the industry standard? Is there any official recommendation?

Edit: I did find some alarmist blog posts urging not to use 3rd party <script> tags, but all of them invariably failed to acknowledge the security benefit of having your script hosted by its company creator.

Edit2: This is a nice write-up that indirectly touches on the advantages/disadvantages of 3rd party scripts: "If you are using 3rd party scripts make sure to examine them and their postMessage implementation" && "I reached out to Matt Abrams (AddThis CTO) who made sure a fix was quickly implemented and pushed to end users".

|improve this question|||||
  • "all of them invariably failed to acknowledge the security benefit of having your script hosted by its company creator" - probably because there is no such advantage. If you always want to have the latest version just copy it regularly over to your site. Then you have not only the latest version but you can also keep older version to find out what changes were made and how they impacted your site and users. This makes it much harder to temporarily slip some backdoor into the script undetected or maybe just target a few users with a backdoor. – Steffen Ullrich Mar 6 '18 at 6:57
  • That is an interesting concept! Thanks for sharing it. I can see it very useful for tracing incidents. Is it just automatic updating it or would it need a security review of each new version? – Me - Mar 6 '18 at 7:01
  • This depends and what you want to achieve. Both a pre-review and also later reviews (like after users complaining) have their use case. – Steffen Ullrich Mar 6 '18 at 7:20
  • If there is no pre-review, and security wise, wouldn't that be the very similar to using a script? (except for the Referer). Any malicious code would also be auto-updated. Of course it'd help with an audit, but not on prevention. Sorry for asking so many questions :'| – Me - Mar 6 '18 at 7:30
  • It depends on your relationship with the third party and how much you trust it. If the trust is weak you better review every changes before they get in production. If the trust is strong and you believe that they don't cause willingly or unwillingly harm it might be enough to keep an audit trail only for the rare case when you need to blame them for problems caused by script changes. – Steffen Ullrich Mar 6 '18 at 8:45
1

If the script is hosted by a third party

  • You have no control over the script. This includes both content and availability.
  • The script can be changed at any time, in a good way (security update), in a bad way (site hacked) or in an inconvenient way (bug fix which unfortunately breaks your use case). But, if you want always the latest version of the script you could also simply have a cronjob running which copies it to your own site and thus keep it available even if the third party goes down. And you could keep versions of the script in order to audit what changes they made and how these could impact your site and your users.
  • You fully rely on the security of the third party. This includes that you rely on their site not being hacked, their DNS provider not being hacked and that they never fail to renew their domain name (since others could hijack it otherwise). This also means that you have trust in their employees that they don't change your script willingly (like adding a back door) or break things accidentally.
  • By looking at the Referer HTTP header of the requests the third party can track where the script is embedded. These URL's might also contain sensitive information in the URL itself. Also the third party could track your users using cookies (obvious) or caching headers like Etag (less obvious since caching is probably expected).
  • If the script is not served from your own site another TCP connection has to be created by the browser to get the script and maybe another TLS session too (in case of https). The existing connection to your site cannot be re-used for this. This means embedded third party script can actually reduce the performance of your site, or at least the performance is outside of your control.

In summary: I see mainly problems when embedding third party scripts. You loose control, security, privacy and maybe even performance. Only if you can fully (i.e. 100%, not only 99%) trust the third party to not willingly or unwillingly harm you, you could think of embedding the scripts directly from the third party. Especially in case your own site is slow or bandwidth restricted compared to the third party hosting you might get some performance gain if the script is large.

|improve this answer|||||
  • Your first 3 points are basically the same, aren't they? No control == can be changed in a bad way == can be hacked. It is negative for sure, but isn't it part of the same security concern? – Me - Mar 6 '18 at 6:54
  • For the Referer, I forgot to mention that, while they might be hosted internally or externally, most of them are sending data to a 3rd party. So they could check the Referrer in that situation. – Me - Mar 6 '18 at 6:55
  • Finally, I had in mind that different domains is actually good for performance and even has a name, domain sharding: blog.stackpath.com/glossary/domain-sharding (but security-wise should not change anything). – Me - Mar 6 '18 at 6:57
  • @Me-: the first point is broad. The next points highlight what "no control" might mean in detail. – Steffen Ullrich Mar 6 '18 at 7:21
  • "For the Referer, I forgot to mention that,..." - your question is a general question about embedding third party scripts, not about embedding a specific script with a specific behavior. If you want to restrict it do this it should be made clearly in both title and body of the question. – Steffen Ullrich Mar 6 '18 at 7:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.