This is the 13th day of my participation in Gwen Challenge

introduce

This paragraph first quotes MDN’s description of this attribute. Click to view

Abstract:

Sub-resource integrity (SRI) is a security feature that allows the browser to check whether the resources it obtains, such as from a CDN, have been tampered with. It determines whether the resource has been tampered with by verifying that the hash value of the obtained file is the same as the hash value you provided.

Understanding: I give you a password, you want to take something to have to tell me the password, if not pass, I regard you as a fake

In the front-end development, usually for front-end performance optimization to do some processing, including some cacheable resources into the CDN, but this can not ensure the security of resources, and the application of this attribute in the parsing OF JS, the first password to ensure that resources are expected, safe content.

Generate the key

Now that MDN lists all of these, just move this section.

openssl:

cat filename.js | opensll dgst -sha384 -binary | openssl enc -base64 -A

shasum:

shasum -b -a 384 filename.js | xxd -r -p | base64

Generate value: sha384 oqVuAfXRKap7fdgcCY5uykM6 + R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC

use

<script src="from.cdn.js" crossorigin="anonymous" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"></script>
Copy the code

There is a problem though, even though it seems safe, compatibility is definitely a part of the equation as a new property.

As you can see in the figure above, this property is not the most compatible at present.

So how do we continue to constrain on this basis? That’s the server.

Require specified type files to comply with SRI (sub-resource integrity) by configuring content security policies on the server;

Content-Security-Policy: require-sri-for script; //script file for child resource integrity check.

Content-Security-Policy: require-sri-for style; // As above, check the style file.

Benefits and Limitations

This sub-resource integrity check has a good preservation effect on resource integrity.

But correspondingly, if the CDN server is hacked or HTTP is hijacked, this can lead to implementation.

In addition, most operators hijacking to add ads, if verifying the integrity of sub-resources, will result in JS not parsing, and then the whole page crash.

So that’s why you eat ashes in the corner.

Think of it as a different front-end world.