Using remote artifacts without integrity checks can lead to the unexpected execution of malicious code in the application.

On the client side, where front-end code is executed, malicious code could:

- impersonate users' identities and take advantage of their privileges on the application.
- add quiet malware that monitors users' session and capture sensitive secrets.
- gain access to sensitive clients' personal data.
- deface, or otherwise affect the general availability of the application.
- mine cryptocurrencies in the background.

Likewise, a compromised software piece that would be deployed on a server-side application could badly affect the application’s security. For example, server-side malware could:

- access and modify sensitive technical and business data.
- elevate its privileges on the underlying operating system.
- Use the compromised application as a pivot to attack the local network.

By ensuring that a remote artifact is exactly what it is supposed to be before using it, the application is protected from unexpected changes applied to it before it is downloaded.
Especially, integrity checks will allow for identifying an artifact replaced by malware on the publication website or that was legitimately changed by its author, in a more benign scenario.

Important note: downloading an artifact over HTTPS only protects it while in transit from one host to another. It provides authenticity and integrity checks for the network stream only. It does not ensure the authenticity or security of the artifact itself.

## Ask Yourself Whether

- The artifact is a file intended to execute code.
- The artifact is a file that is intended to configure or affect running code in some way.

There is a risk if you answered yes to any of these questions.

## Recommended Secure Coding Practices

To check the integrity of a remote artifact, hash verification is the most reliable solution. It does ensure that the file has not been modified since the fingerprint was computed.

In this case, the artifact’s hash must:

- Be computed with a secure hash algorithm such as `SHA512`, `SHA384` or `SHA256`.
- Be compared with a secure hash that was not downloaded from the same source.

To do so, the best option is to add the hash in the code explicitly, by following Mozilla’s official documentation on how to generate integrity strings.

Note: Use this fix together with version binding on the remote file. Avoid downloading files named "latest" or similar, so that the front-end pages do not break when the code of the latest remote artifact changes.

## Sensitive Code Example

The following code sample uses neither integrity checks nor version pinning:

    <script
        src="https://cdn.example.com/latest/script.js"
    ></script> <!-- Sensitive -->

## Compliant Solution

    <script
        src="https://cdn.example.com/v5.3.6/script.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    ></script>

## See

- OWASP - Top 10 2021 Category A8 - Software and Data Integrity Failures
- CWE - CWE-353 - Missing Support for Integrity Check
- OWASP - Top 10 2017 Category A6 - Security Misconfiguration
- developer.mozilla.org - Subresource Integrity
- Wikipedia, Watering Hole Attacks