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.
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?
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:
<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.
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.