These third party libraries are a necessary part of modern websites. It’s worth trusting but verifying their security.
>Install Enchanted Security's tamper-resistant JavaScript snippet on your site. The inline snippet is designed to be small, adding only a few milliseconds to load time, and does not require active configuration on your end.
There's a lot of marketing copy on your site, but it doesn't really tell me what it's really doing, or even how Enchanted Security itself is secured.
If anyone wants to know more they can schedule a private demo.
It should have only showed up if you didn't complete the form though.
And security is hard, so defense in depth makes sense.
In general I agree that you should minimize unnecessary JS, especially simple libraries like the "left-pads" of the world.
I also found that some modern tooling for web apps doesn't seem to be built with CSPs in mind. For example CSS styling in JS like React Styled Components, I'm not sure it's even possible to create a CSP that covers CSS in this case.
Having a "security-ops meeting" to discuss whether we should really be using shiny new XYZ.js from another external provider isn't going to work either. It all seems like it's more of a mindset problem than a technical one. It's one hot mess.
You're absolutely right that CSP and SRI are good in theory but fail in practice.
For CSP, it's too difficult to implement a secure CSP, especially without breaking your site. I know companies where it took over a year to implement their CSP. And then, at the end of the day, it's really hard to do securely. Research has found most CSPs are insecure. For example, the posted blog's CSP is: default-src * data: 'unsafe-eval' 'unsafe-inline' But even CSPs that look like they're trying to be secure contain subtle insecurities.
Even trusted domains you might put in your CSP can be used in untrusted ways. For example, this blog post uses Gravatar. Did you know that Gravatar has an optional "default image URL" that can be used for data exfiltration even on sites with secure.gravatar.com in their CSP? It's because Gravatar will proxy the request to fetch the default image if it doesn't recognize the email. https://en.gravatar.com/site/implement/images/ So you may think you've done everything correctly and have a good CSP but in reality it's really hard to do securely.
SRI isn't practical for third party resources that are expected to change over time, which is actually most third party resources. For example, a chat script like Intercom will change when someone from marketing makes a change that affects its frontend settings. This may be changing some text or coloring. You can use SRI for something like a specific version of jQuery, but not for most of the products people are relying on that have more dynamic functionality.
a) seperates static hostic (js/css/images) from dynamic hosting, which require different tuning and traditionally may run better on separate machines
b) you used to get some parellism benefit from multiple hostnames, that might be gone with http/2, but then you may not want head of lime blocking interacting between html and css/js
c) a good CDN will get your js/css/images to your users faster than if they got them directly from your origin servers, if your assets are of significant enough size to overcome the overhead of connecting to the CDN, and the chance that the CDN has a cache miss (depends on usage). A good CDN is using geo aware DNS and/or anycast to get clients to a datacenter that's near to them, and chances are your origins are only in one to three locations. For one site I worked on, when we did a redesign that doubled the page weight, but also moved serving everything behind a CDN, the page load time ended up about the same, so the CDN basically let us double our page weight for free (I would have preferred that we just keep the page smaller and get a faster site, but I don't get to make those decisions)
d) some people claim there's a reasonable chance of browser caching if you use a public CDN path, although personally, I expect that's very small -- there are so many public CDNs and so many versions of all the libraries and most browsers have fairly small local caches.
The benefits of a CDN:
1) You don't pay for the bandwidth (in some cases)
2) If enough resources on the web request it, the client may have it cached locally already, causing faster load times.
3) If you request a lot of resources, you get more threading because the amount of simultaneous request to the same host is limited for most platforms (applicable when the source is not cached), but using HTTP/2 negates this issue as well.
4) Based on your location, the CDN can serve the content from a datacenter closest to the end-user (not all CDN's have this feature), resulting in faster transfers as well.
The question remains if this is worth it. For some stuff, it is (think Google Fonts for example), for most, you get version fragmentation, which makes the odds of someone having it cached a lot lower. Add all the other things that can go wrong, and using a CDN stops making sense in a lot of cases.
Note: having seen terribly rigid processes I'm very much an advocate for DevOps and welcomed this way of working. I think we threw out the baby with the bathwater when we embraced DevOps. A site that allows what is mentioned in this article doesn't have a functioning Operations unit.
- don't eval on the server side (this is a bad idea most of the time anyway);
- serve js bundles from your own domain and set an appropriate content security policy;
These hacks won't work then.
Imagine if running a native app on your computer would load random DLLs from servers. It boggles the mind.
I'm pretty sure you can't make a blanket statement like this without discounting a lot of developers who do take security into account when developing. These are just some interesting holes that were reported.
Is all your code perfect?
Tag managers are the worst. They shouldn’t even exist. When a website uses a tag manager, it means the web devs have been forced to give marketing and every other department a backdoor to insert whatever vile abominations they want.
So this has nothing to do with the third party JS library itself, but with how the website's backend stored the data generated by the frontend script. The developer could probably reproduce the hack with postman and doesn't need the CDN hosted library at all.
I'd probably trust a single CDN (like cloudflare) with my own copies of all things I include more than I'd want to serve directly but use code from lots of different sources, but for something incredibly high security, I'd want end users to be talking directly to a secure server (maybe with tcp/etc. layer proxies for ddos resistance and flow-level monitoring, but without decrypting).
