I’ve written previously about both CSP (Content Security Policy) and SRI (Sub Resource Integrity), both of which are mechanisms that can be used to better secure your website.

CSP (or Content Security Policy) allows you to set a number of directives about what types of content can be loaded by your website, and what locations they can be loaded from.  This is great because it means that if someone was able to find a Cross-Site Scripts (XSS) attack vector, they wouldn’t  be able to use it to load additional javascript or stylesheets, or at least not from any domain that wasn’t already listed on your CSP, depending on how you’ve set it up.

SRI (or Sub Resource Integrity) allows you to specify the hash of an externally hosted javascript or stylesheet file, so despite the fact that it is coming from another server, it can’t be inadvertently or maliciously modified and still be loaded into your website, any changes would make it fail the SRI validation and therefore it would be excluded.  You may lose some functionality, but at least no one can inject malicious code into your site, and that has to be a higher priority.

There is an extra step that you can take in combining these two things though, and that’s to require SRI for certain asset types.  This can be done with the following CSP…

Content-Security-Policy: require-sri-for script style

In this example, I’ve listed both scripts and stylesheets, so now they would all require SRI, otherwise they would be excluded by default.  This means that if someone could inject a javascript or stylesheet file they would also need to add the SRI attributes for them to be included, which raises the difficulty level once again.

One thing to note however, server push and SRI are not compatible, so if you’re locally hosting files so that you can get the performance benefits of server pushing them, then you wouldn’t be able to use this directive, as the local files could not have SRI attributes included.