As a response to the growing number breaches involving CDNs, the first release of the Subresource Integrity (SRI) was published hastily in late 2015. The W3C WebAppSec Working Group decided to leave certain features out, in favour of an early release. Although SRI already does the job, there is some room for improvement with regards to user experience. The good news is that some of these features will be added to the next iteration of SRI.
The following article gives a brief, speculative overview of the upcoming features of Subresource Integrity.
Fallback to Local Assets
Both URIs (remote and local) can be defined in the same
<script> tag as the following:
<script src="http://example.com/script.js" noncanonical-src="http://cdn.example.com/script.js" integrity=“sha256-..."></script>
SRI Integrity Policy
The policy would be related to the Content Security Policy (CSP) specification. The new SRI extension would function similar to CSP policies. The policy in the HTTP header would instruct the visitors’ browser to reject all assets without SRI protection.
One major shortcoming of the current specification is the lack of error reporting. Unfortunately, neither the end user nor the developer is notified properly, when a mismatch is found between the hashes. SRI violations are only logged to the visitors’ browser’s developer console.
On the other hand, Content Security Policy (CSP) handles policy violations differently. If CSP fails, the browser will send a JSON-formatted report to a remote server. A good example is report-uri where these error reports can be collected, indexed and analysed by the developer.
The SRI reporting scheme would operate similarly. Although plans for implementing the advanced reporting were abandoned earlier, it is now under consideration again for the next release.
There are other interesting features considered, such as:
- Images with
- Integrity on additional subresources loaded with fetch() from CSS assets
- Protection of
The new features of the SRI specification can be tracked at W3C Web Application Security Working Group’s repository on GitHub.
Image courtesy of Syncano