Reply to post: Re: Don't load third-party scripts

UK ICO, Thousands of websites hijacked by hidden crypto-mining code after popular plugin pwned

JLV Silver badge

Re: Don't load third-party scripts

>Code needs to be 'fit for purpose'.

+1. This.

We have a problem. We have a bunch of suggestions. I am not an expert but it seems like we need to tally up both the constraints and the issues. Anytime you veer on security extremes at the cost of usability, users go elsewhere or bypass your safeguards. This is a well known factor with security, nothing new to the web.

- it is not feasible to run websites built with only your own code. i.e. javascript as it is known to all browsers, without any code written by anyone else. That puts us in what, pre-2015 JS? No modules, no imports, just good ol'd <scripts src=myself>? Hey, no JS would be even safer.

- if you wish to do so, your competitors will eat you alive.

- complex code written by yourself is not necessarily the most secure code. Yeah, I know some of you will claim otherwise... I don't. I can do my best and then have other people review it, but that's about it.

- hosting JS libraries locally makes it easier for me to trust your site, rather than 20 JS domains, but doesn't change whether the original code is malicious or not. In a way, I'd tend to trust a well known CDN's version of Jquery more than yours, for example.

- Once you accept that some of your code will be based on someone else's code, that brings in security issues. Whether the script from a 3rd party domain or hosted on your server doesn't really matter. The little LPAD quip someone made is funny, but naive... do you really think that lpad is http'd in from the web? No it is merged in by some kinda of bundler. Whether the user sees it or not, it's still code coming from somewhere that was liable to be hijacked at some point.

So we need better ways to deal with potentially harmful code not written by the people running a website. That runs the gamut from the company running the website auditing its library stack for known vulnerabilities to npm checking uploaded code for hacks to your browser becoming even more paranoid than it is.

There are no easy solutions here, just hard problems. That's what collaborative development, based on merging different libraries together means. And that's been around for a long time and is not a web-only/JS-only issue - as soon as you don't control your compiler, you're already at risk - can't remember who demonstrated that, but it was at least 30-40 yrs ago.

Also, let's not confuse our dislikes with actual security risks. I have Google Analytics on perma-block in Noscript, but a _hacked_ Google Analytics slurping more crap than Google usually does - which can justifiably be totally unacceptable to many - is vanishingly unlikely.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019