SRI is a valuable tool for ensuring externally loaded resources have not been tampered with. However, we view security as a multi-layered "defense in depth" strategy. In our specific environment, we use several other robust controls to manage third-party risks effectively:
How We Secure Our Resources
Rigorous Vendor Vetting: We don’t just link to any script. Every third-party provider (including fastcdn.co and Google, which are authorized and expected) undergoes an internal security assessment and risk evaluation before approval.
Content Security Policy (CSP): We use a strong CSP to restrict script execution to only our trusted sources. This is a highly effective way to prevent unauthorized script execution. If you’d like, we can even help configure a CSP for your specific pages.
Constant Monitoring: Between our annual third-party penetration tests and our regular dependency audits, we keep a very close watch on client-side risks like script injection.
Why SRI isn't always the best fit
While SRI is a great "best practice," it isn't always feasible for every script. For example:
Dynamic Content: Some of the scripts we use change frequently to provide updated functionality. If we used a static SRI hash for these, the feature would break the moment the provider updated their code.
Internal Controls: For resources hosted on our own infrastructure, we ensure integrity through our internal deployment and versioning processes rather than SRI.
A Note on Automated Scanners
We're aware that tools like security-scoring 3rd-party services often flag missing SRI tags. While these scanners are helpful for a high-level overview, they sometimes prioritize "checkbox" fixes over the actual risk context.
Our security roadmap is focused on addressing high-impact, real-world risks. Rest assured, the absence of SRI on these specific scripts doesn’t represent a security gap; the risks are already well-mitigated through our vendor governance and CSP enforcement.