Incorporating a third-party JavaScript library or external CSS into your website has become incredibly straightforward. Simply add <script src=”https://example.com/whatever.js”> within the <head> section of your HTML, and you’re good to go, correct? Discovered a visually appealing CSS? Easily integrate it into your site using <link rel=”stylesheet” href=”…”>.
What are the potential risks? Quite a bit, as it happens. Within this article, I’ll delve into the security consequences of integrating third-party resources and offer ways to safeguard your site and its users.
Challenges Associated with Dependence on Your CDN
A Content Delivery Network (CDN) consists of a network of servers, typically distributed globally, that enhance the speed of content delivery on your website. Rather than hosting a widely used library on your server, you instruct your site’s visitors to retrieve it from the nearest CDN server, thereby accelerating page loading.
Nevertheless, there’s a downside. By incorporating external services into your website, you grant someone else complete authority over your site. You might believe you’re merely importing impressive JavaScript for displaying sparkles whenever a link is clicked on your site, but that library could potentially be compromised by a malicious actor. Consequently, your site’s visitors could fall victim to hijacking. In case the CSS is compromised, visitors might be exposed to disturbing images.
How can you safeguard yourself from such a catastrophe?
What does SRI entail, and how does it offer a solution to this issue?
This is why SubResource Integrity was invented. It’s a bit of a mouthful, so we’ll call it SRI for short. SRI allows you to say “I want exactly this specific version of the imported code and if even a single byte of it changes, don’t run it.” When you use SRI, you’re protecting your site and your users from compromised code. Even if a person with malicious intentions hacks the server hosting the third-party code, they will not be able to take over your site. Pretty cool, huh?
Utilizing SRI: A Guide
Let’s take a look at how SRI works. Imagine that you want to include jQuery on your site. Here’s the SRI code that you can use:
HTML
<script src="https://code.jquery.com/jquery-3.7.0.slim.min.js" integrity="sha256-tG5mcZUtJsZvyKAxYLVXrmjKBVLd6VpVccqz/r4ypFE=" crossorigin="anonymous" ></script>
And for CSS, it is pretty similar:
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/picnic" integrity="sha384-v1z6igsPTyRDbi5o+gRfebiF45laQTyfvucMlEmzfyalawh17iTvBbICU08I7ksb" crossorigin="anonymous" />
You’ll observe two new attributes distinct from a standard <script> or <link> element. These are crossorigin and integrity.
The crossorigin attribute is straightforward. It instructs your browser to request the resource from the server anonymously, without transmitting any personal identifying information like usernames or passwords.
On the other hand, the integrity attribute is a bit more intricate. It holds a mathematical representation, known as a “hash,” of the requested code. The prefix sha384 denotes the algorithm, specifically SHA384, prompting the browser to employ that algorithm to assess the requested code. This process generates a lengthy character string. If the code on the remote website undergoes alteration, the SHA384 function will produce a hash that won’t correspond with the second part of the integrity value.
In essence, should the code on the remote server change, your browser will reject its execution.
Obtaining the SRI Hash
Many libraries provide the SRI hash directly, allowing you to copy and paste it. If a site doesn’t provide this hash, you can compute it yourself. The simplest method involves using the SRI Hash Generator: paste the URL of the code, and it swiftly generates the hash for your use.
Constraints of Employing SRI
Naturally, employing SRI does present certain drawbacks. Given that the SHA384 hash necessitates the preservation of the original file, specifying the version becomes crucial. Utilizing SRI doesn’t guarantee access to the latest version of a library—it forces a decision between ensuring site security or constantly having the newest features.
Consider the scenario where a remote site is compromised, replacing the library with a malicious file. In this case, the browser will refuse to execute it. However, what if your site heavily relies on a critical JavaScript library? If it fails to function without it, users might encounter a dysfunctional website. While preferable to a compromised one, this highlights the importance of employing progressive enhancement to ensure site functionality even in the absence of JavaScript and CSS.
Fortunately, SRI has been supported by all modern web browsers since 2016. However, older browsers may disregard the crossorigin and integrity attributes, potentially exposing users to risks if the libraries used are compromised.
Recap
SRI is the best defense you have against third-party JavaScript and CSS being compromised. It’s fairly easy to use, but if something does go wrong, you’ll need to make sure your site works without external resources.