1

I've worked mostly with backend processing stuff.

I've been assigned to figure out how to secure external Javascript that we import from sources like Facebook, Twitter and Google.

One option is locally hosting them, which may not be possible due to updates of the said files:

Can I have any input on any other options that are possible in securing the external Javascript that we are linking in our website?

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 2
    I always recommend to not include external resources as you have no control over them. Instead, download these files and include them locally. – Jeroen Apr 23 '15 at 06:38
  • Hi @Jeroen-ITNerdbox, Thanks for the info but it seems that locally hosting them will not allow me to update the scripts, and this may break some of the content it has. I'm thinking this maybe a stalemate and we'll be on the mercy of the external publishers of the scripts. – rookiedev0706 Apr 23 '15 at 06:48
  • Well, that's a choice. In order for you to be more in control I suggest to download it locally and perform regular updates accordingly. Your content might also be broken by remotely including these scripts as you have no control over when these scripts are updated and are still compatible with your own code/content. – Jeroen Apr 23 '15 at 06:53
  • Hi @Jeroen-ITNerdbox, Got it, thanks i think i'll have to consult my seniors on how to approach this problem. Is it possible to do the js updates with a let's say 15min cron job ? I think it's a possible solution but needs confirmation. Again thanks for the help. – rookiedev0706 Apr 23 '15 at 09:25
  • Related (possibly a duplicate?): [External cross domain include script](http://security.stackexchange.com/q/81757/13146) – apsillers Apr 23 '15 at 13:54

4 Answers4

6

This has more to do with risk management. You do not have any contract with Facebook or Twitter. So you have a risk that they may change the contents of the JavaScript file without you knowing. This can be malicious or accidental, either way you have no control of this risk.

So unless you get a contract with the external party which moves the liability to them, there is nothing else you can do and you should store the sources locally.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • Hi Lucas, Thanks for the tip. I think i'll have to talk to the persons incharge on how to approach this currently problem. So it's either keep it external or do a manual update. Thanks !, – rookiedev0706 Apr 23 '15 at 09:21
  • No, it's either keep it external with a contract for liability or keep it locally and manually update. – Lucas Kauffman Apr 23 '15 at 11:34
1

Check https://www.owasp.org cheatsheet about that

https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html

About CPS if you want to get shortversion about it check MDN

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/base-uri

I personally recommend CPS for 3rd party as a must.

Remember that your header have a limit in size (https://stackoverflow.com/questions/686217/maximum-on-http-header-values) therefore remember that if you using 10 3rd party libraries this can be a pain sometimes (Like tracking different brokers)

fearis
  • 111
  • 2
0

Hosting locally will not prevent them from doing anything malicious. In this case, if you are importing a JavaScript file from external source, into your page, you will have to 100% trust the JavaScript as this script will be executed within your own origin.

Hosting them locally might provide some advantage in case the source you trusted is compromise. The maximum you can do is to manually review the external file, for bugs and backdoors, and then keep a check for updates to those scripts and review the changes. But this can be a real pain! The best solution is to trust the source and NEVER EVER include JavaScript from an unknown source into your application!

  • What do you mean by "The best solution is to trust the source"? How can you trust something that you have zero control over? – Jeroen Apr 23 '15 at 06:40
  • Yes, you're right! Edited my answer. But still, even if you are hosting it locally, without reviewing it, you're trusting the source. – NeverStopLearning Apr 23 '15 at 06:46
  • After downloading it and reviewing the code you are in control and only then you're trusting the code, not the source that released the code. – Jeroen Apr 23 '15 at 06:52
  • True. That's what I said in the answer. You'll need to review it. – NeverStopLearning Apr 23 '15 at 06:53
0

All of the above posts are correct in that you need to trust the third party in order to safely use external js resources. The only thing I would add on to that is make sure that you are accessing those resources over SSL and that it's an up-to-date implementation (proper cipher suite, TLS v1, etc). If you are going to trust the third party, SSL is needed to make sure that you're indeed pulling the resource from that same third party.

Dan Landberg
  • 3,312
  • 12
  • 17