views:

107

answers:

5

I'm a new developer at my company and I do mostly front-end web development. Our team is frequently asked by our Sales and Marketing people to incorporate 3rd party javascripts on our site.

"Here's a 'little code snippet'. Our vendor asked if you could put this in our home page"

This makes me very nervous.

I know these scripts can slow down our pages, and I've found in a number of cases I've had to surround some code with try/catch blocks to ensure that these 3rd party errors do not impact other scripts on the page.

These scripts come to me in a variety of forms ...

some are vendor supplied scripts that we host ...

<script src="http://www.mycompany.com/js/vendor-file.js" type="text/javascript">

... some are reference in our code, but hosted externally

<script src="http://www.vendor.com/js/file.js" type="text/javascript">

... and some are scripts are appear inline on our site, which insert tags into our head by writing to the DOM

var a = document.createElement("script"); a.type = "text/javascript" ... etc.

A lesser concern, but still important is cookie writing -- and exceeding the IE6's 20 cookie limit (yes, an important client base is still on IE6 and they represent real $$$) -- so we require (hope) that no javascripts hosted on our domain drops any additional cookies.

But, aside from the cookie issue -- what additional risks/scenarios/dangers exist that I need to know about or should be looking out for -- so I can keep our site and our customers happy.

Thanks

-Rich

+1  A: 

There is always the possibility that a vendors server is compromised and they do some kind of XSS.

Jud Stephenson
+2  A: 

It sounds like you are already aware of the main ones: Slowing down the page, and the chance of 3rd party non-hosted scripts could break or not be present, causing issues.

It also depends on the reliability of these 3rd parties. There's always the change their script could get replaced with something malicious.

GSto
To me...that's the real issue...the OP links to an external script, the vendor's site gets hacked and now he's including malware in his page(s)...
w4ik
+5  A: 

No is a big word with a lot of power. Wield it well.

You are under NO obligation (barring legal and contractual agreements) to include any code snippets from sources you do not know and fully trust. If you are nervous, and you're responsible for the stability and security of your site, JUST SAY NO.

JavaScript can be a wild beast to tame. It's very easy for one small, seemingly innocuous script to bring the whole house crashing down. Never treat any simple script like its "just a silly little thing." All it takes is for one script to replace a key function that, say, JQuery, or AJAX, or some other library relies on, and your site will go down in a blaze of glory.

Mike Hofer
+1 for the "No" essay :)
Jas
Well said. Once you have a remote script on your page, it OWNS your page. It can monitor and re-write (or accidentally break) anything it wants.
Diodeus
A: 

Why carry the burden of responsibility for code that you did not write? If anything goes wrong, I bet your manager won't hold the vendors responsible - they'll hold you. So say no to this one, even if it means changing your job.

Jas
A: 

IE 8+ has a new feature named In Private Filtering, which basically states if it finds the same javascript file from N (configureable) number of domains it just blocks it after reaching the limit. That would be bad if it was jquery for example. This is disabled by default but it's still a problem if users are using it.

dstarh