SRI: checking that an external file is the expected version

Useful to know

A page can use a program file or a style from an external provider. The address shows where the resource is downloaded from, but sometimes it is also necessary to check its exact content. Subresource Integrity, abbreviated SRI, allows an expected cryptographic hash to be added to the resource inclusion. The browser compares the data received with this value. The goal is not to use a file whose content does not match what was previously expected. [1]

A hash can be viewed as a value calculated from the specific bytes. In HTML, it is placed in the integrity attribute for supported inclusions. The syntax also denotes the algorithm used, for example SHA-384. [1] This mechanism should not be confused with the file name. Two different versions can have the same visible name, and the same file can be renamed. Verification refers to the content, not the convenience of the chosen name.

Let's imagine a fictional gallery that uses an external library to zoom in on photos. The team chose a particular version and experienced the buttons, keyboard controls and image closures. The documentation can record which version was approved and where it came from. SRI adds a technical check to this solution. Thus the choice of version and the verification mechanism have different, clearly described roles in the preparation of the page.

In the case of resources of other origin, SRI is also associated with CORS. The crossorigin attribute with a anonymous, value is often used, but it is also necessary for the resource's server to allow the appropriate access. [1, 2] The attribute determines the query behavior with respect to CORS and the identification data. The anonymous value is not a promise of general visitor anonymity. This is a specific query setting, the meaning of which must be read in the context of the item included. [2]

When renovating the library, it is not mechanical enough to change the address and keep the old hash. New content must have a corresponding expected value. [1] The practical process can be arranged like this: a version is selected, its origin is checked, the function is tested, and the inclusion is updated. The page is then re-opened to determine if the resource has actually been accepted. This sequence makes the update traceable.

A useful result for maintenance is a short entry that links a component, a version, an address, and a check. It also helps in reverting to a previous state: the team knows which combination worked instead of collecting individual values from memory. SRI has a narrow but straightforward task in this process. It checks the compliance of a specific file, while deciding whether that file is suitable for the site remains part of the technical and product evaluation.