I recently sat down to chat about Gatsby and security with Mike Gualtieri, our Staff Security Engineer. For about a decade, Mike ran an independent software and security consultancy before he came on board to lead security efforts here at Gatsby.
Topics we covered: why Gatsby’s static architecture boosts security, how we should think about security in the JavaScript ecosystem, securing npm packages vs marketing scripts, and how website security fits into a company’s overall security strategy.
- Register Today! Join us for GatsbyConf on March 2nd and 3rd, 2022
Why Static Architecture is More Secure Than Running Servers
Sam: So could you walk through the security difference between Gatsby and something like WordPress?
Mike: One big difference between a CMS running WordPress and a Gatsby website is server-side vs client-side code execution. Let’s say there is a vulnerability affecting the WordPress ecosystem. Maybe a plugin that was modified maliciously as part of a supply-chain attack, or a plugin with a security hole.
With server-side rendered code the vulnerability affects you twenty-four hours a day. Because your CMS hits the application server and the database for every user request, each time a visitor loads a page on your site, the affected plugin is executed. Which could be a problem if malicious code is also executing.
When users are visiting a Gatsby website, they are typically only retrieving statically prepared assets served from a CDN, greatly reducing the attack surface for both the visitor and the developer.
How Gatsby Protects Against Supply Chain Attacks
Sam: Okay, I want to dive in here, but let’s start by backing up a bit. The whole idea of vulnerable code in your dependencies is known as a “supply chain” vulnerability. Can you talk a bit about supply chain in general?
Mike: One of the biggest recent examples of a supply chain vulnerability is the Solar Winds attack from the end of 2020. Nation-state actors, presumably Russia, breached a major IT vendor. They then published malicious packages, which were used by US government agencies like the State Department, Treasury, and so on.
Sam: Great. So if you compare JavaScript to other ecosystems, how secure would you say it is? There have only been a couple of known “supply chain” attacks, and they were detected fairly quickly. But maybe that’s just because not a lot of attractive targets use Node.js relative to C# or Java. At least right now.
Like growing up in the 90s, my parents had Macs. Macs were pretty secure then, partially because it just wasn’t worth hackers’ time writing viruses for Macs when there were 30x as many Windows machines out there.
Mike: First off, the structure of the NPM ecosystem is similar to the Python ecosystem with pip, or the PHP ecosystem with composer. These are ecosystems that tend to rely on a lot of third-party code, and where anyone can publish code. And that model bakes in some level of inherent risk.
That said, I’m a big fan of open source. And the nice part of open source is that when the code is out there, somebody might look into it. And not just people using the code, but maybe like a security engineering team at Github, say, who are scanning for issues.
Sam: Yeah. We’ve talked before about Dan Abramov’s article, which we both agreed with. Let me recap briefly. Basically, the most-used tool to detect supply chain vulnerabilities is npm audit, but Dan Abramov argued, pretty persuasively, that npm audit is broken because it cries wolf way too much.
How should we think about the risk of a supply chain attack in the JavaScript ecosystem? Specifically if you are building a Gatsby site?
Mike: So here’s where I think Gatsby’s architecture comes in handy. Let’s say the worst case scenario happens, and you’re using some third-party npm package that gets compromised, or there’s some critical security vulnerability.
With Gatsby, that code is only going to get executed at build time. It’s not going to get executed when users visit that site. It’s probably not going to have access to user input. Whereas, again, in the WordPress server-side rendering world, twenty-four hours a day, you have that vulnerable code running.
Sam: That’s a really interesting and important distinction to call out – so, if you do have a supply chain vulnerability, it will only happen at build time rather than on an ongoing basis.
Mike: Yes. And the attack surface is greatly reduced there because you don’t have user input at build-time.
Sam: Okay, that makes sense for npm packages you’re importing. How does that change when you’re thinking about marketing scripts you drop on your page?
Third-party script security: using SRI and CSP
Mike: Since marketing scripts are executed on every page load, they are probably the biggest attack surface for a static website, Gatsby or otherwise. The good news is that the risk can be mitigated with a Content Security Policy (CSP) and Sub-Resource Integrity (SRI), which is basically a SHA hash that you put in JavaScript.
Sam: Let’s say I’ve heard those terms before, but I don’t know what they mean. Can you explain them to me?
Mike: Sure. Let’s start with Sub-Resource Integrity. Let’s say I’m including an analytics script or some third-party resource in my website. SRI provides a SHA256 hash of that resource. If it doesn’t match, the browser won’t load it.
Sam: So the hash is on the code. You check it in, when you check in the code and then it has to, it will not load if it doesn’t pull.
Mike: Yes, but SRI is only half of the solution. The other half of the solution is called the Content Security Policy.
Mike: A Content Security Policy specifies where your browser is allowed to send third-party requests. In the case pictured here, the browser is allowed to load Google Analytics and Bootstrap CDNs. If I included JavaScript on the webpage, that’s not included in these handful of domains, then it won’t load. It won’t load even if it’s a legitimate resource and has a proper SRI check, like for example maxcdn2.bootstrap.com.
CSP and SRI are another way to prevent Magecart-style attacks, where someone takes over a common third-party script and it sends your credit card data to an unknown third-party. It’s a built-in browser feature websites can take advantage of.
Sam: So if I’m understanding this, what the Content Security Policy will do is say, the thing that you’re trying to send a post request to is not in this list of approved URLs. So the browser is just going to block the requests.
Mike: Yes.
Sam: So there are multiple levels of security here. Sub-Resource Integrity is saying, “you know exactly what the script that I want is, and it has this hash.” And then Content Security Policy is saying, well, if somehow we have loaded a malicious third party script, or if there’s something weird going on in our code, we can only send resources to these URLs. You close off the main door, and then you close off the side hatches.
Website security as a link in your overall company security
Sam: Okay, let’s zoom a little bit out now. Many companies think about security at a holistic level through their entire technology stack. And their website is one piece of their technology stack, which is only as secure as its weakest link.
I had a really interesting conversation with a CTO of a healthcare related startup a while ago. They’re HIPAA compliant, their app is quite secure. They take patient privacy incredibly seriously. And the CTO was looking to use Gatsby. He was pretty worried because the marketing folks had built a WordPress website.
He was like, “I’ve locked down our infrastructure super tight. I’m confident about that. But if the marketing team is using WordPress, how do I know that it’s not going to get hacked? You know, I don’t. And then what are customers going to think if our marketing site gets hacked?
Are we going to be able to communicate, ‘Don’t worry, it was just a marketing site, it just had content and it didn’t have any patient data.’
Will the customer really understand that? Probably not. They’ll be like, ‘Oh, my health data got hacked. I’m totally screwed.’”
Mike: And that will be the headline, WXYZhealth.com Breached.That’s a really great example for why a static site is good.
I’ll add one more thing. In the past, I’ve done consulting gigs as a penetration tester, where I have breached WordPress sites and then retrieved passwords that are reused on the corporate network.
As a penetration tester, we don’t often need to exploit a lot of vulnerabilities. Looking for passwords, and misconfigurations that expose passwords, often helps more to gain access to systems. People tend to reuse website passwords elsewhere.
WordPress also tends to leak usernames; usernames that double as corporate usernames. If access can be gained to the website, password hashes can be gathered either directly from the database, which are slow to crack, but also the website source code can be backdoored to intercept passwords on login. These passwords can then be tested to access the corporate network.
Sam: Huh, I would never have thought about that. That makes total sense. So the lesson is, don’t let your website be the least secure part of your stack – use Gatsby.
Mike: I think that’s a compelling argument.
Sam: This is awesome. Super helpful. Thank you so much for letting me pick your brain.
Mike: My pleasure!