# SRI + CSP: How to Reduce the Risk of Third-Party JavaScript Without Breaking Your Site

Canonical: https://vulnify.app/blog/sri-csp-third-party-javascript-security

Combine Subresource Integrity with Content Security Policy to pin stable third-party assets, constrain script sources, and reduce supply-chain risk without blindly breaking integrations.

Third-party JavaScript runs with the privileges of the page that loads it. If a trusted CDN file is replaced, a compromised vendor changes its bundle, or a tag manager injects unexpected code, the impact can include credential theft, payment-page manipulation, data exfiltration, or account actions performed in the user's session. Subresource Integrity and Content Security Policy address different parts of that risk. SRI checks whether a specific external file has the exact bytes you expected. CSP restricts where scripts and other resources may come from and, in stronger designs, which scripts are trusted to execute. Used together, they can reduce exposure without pretending that either mechanism is a complete third-party risk program. What Subresource Integrity does SRI adds an integrity attribute containing a cryptographic hash to a script or stylesheet reference. The browser downloads the resource, calculates its hash, and refuses to use it if it does not match. <script src="https://cdn.example.com/library.min.js" integrity="sha384-BASE64_HASH_HERE" crossorigin="anonymous"></script> This is well suited to static versioned assets whose contents should not change unexpectedly. What SRI does not do SRI does not tell you whether the expected file is safe. If you pin a vulnerable or malicious version, the hash will faithfully allow it. SRI protects integrity against unexpected modification, not software quality. It also does not fit resources that legitimately change on every request or are dynamically generated unless the delivery model is redesigned. Cross-origin SRI has CORS requirements MDN notes that cross-origin resources checked with SRI also require appropriate CORS behavior from the resource origin. Test the exact CDN configuration rather than adding an integrity attribute and assuming it will work. What CSP contributes CSP can restrict script sources to approved origins and can be built around nonces or hashes for stronger control of first-party scripts. A simple origin allowlist can reduce accidental third-party loading, while a strict CSP can significantly reduce the impact of injected markup. Vulnify's CSP Builder can help draft a policy, and the CSP Checker can inspect what the live site actually serves. Origin allowlists do not protect a compromised approved host If CSP says script-src https://trusted-cdn.example and that CDN serves malicious JavaScript at an allowed URL, an origin-based policy may still allow it. SRI can add a file-content check for stable direct includes. This is where the two mechanisms complement each other. Start with a third-party script inventory List what actually loads on important routes: analytics; tag managers; payments; chat and support; consent management; A/B testing; advertising; maps and media; fraud and identity services. Record the owner and business reason for each one. Removing an unnecessary script is stronger than adding another security control around it. Use SRI for stable direct includes Versioned libraries loaded directly from a CDN are good SRI candidates because their content should be immutable. Pin an explicit version rather than a moving URL such as /latest/ . When upgrading, update the URL and hash together after testing the new version. Dynamic vendor loaders are harder Many tag managers and SaaS integrations load a small bootstrap script that then loads additional code dynamically. SRI on the bootstrap file does not automatically pin everything it later imports. For these systems, vendor governance, CSP, sandboxing where available, route-level isolation, and minimizing permissions can matter more than SRI. Use CSP Report-Only before enforcement A complex site may depend on scripts that developers have forgotten. Deploying a strict policy immediately can break checkout, authentication, analytics, or support tools. Use Content-Security-Policy-Report-Only to observe violations, classify legitimate dependencies, and fix application behavior before enforcing. Do not respond to every report by widening the allowlist. Avoid unsafe-inline as a shortcut Adding 'unsafe-inline' can weaken the script policy significantly. Prefer nonces or hashes for inline scripts where practical. A mature policy should express which code is trusted, not simply which domain served the HTML. Be stricter around sensitive routes Third-party scripts that are acceptable on a marketing page may be unnecessary on account, login, checkout, or payment routes. Reduce the number of external parties present where users enter credentials or make sensitive decisions. If the application architecture supports route-specific loading and CSP, use it. Tag managers need governance A tag manager effectively delegates script execution to whoever can publish tags. Protect the tag-manager account with strong authentication, role restrictions, approval workflows, and audit logs. Review old tags and templates. A strict application policy is undermined if a broad tag-management workflow can add new script origins without security review. Self-hosting is not automatically safer Copying a library onto your own domain removes one CDN dependency, but you now own patching and distribution. If the self-hosted copy becomes stale, risk can increase. Choose the deployment model you can maintain. SRI, version pinning, dependency review, and patch management solve different problems. Test what happens when SRI blocks a file If an integrity check fails, the browser refuses the resource. Make sure the application fails safely. A checkout should not silently skip fraud controls or form validation because a vendor script failed to load. Security controls should not create a dangerous fail-open path. How Vulnify fits SRI and CSP review Vulnify's CSP tools and Security Headers Analyzer can inspect the policy delivered by the public site, while the JS Library Vulnerability Checker can help identify supported public library/version evidence. These views complement SRI. Vulnify does not approve third-party vendors or decide which business integrations are necessary. Those decisions belong to the site owner. SRI and CSP checklist Inventory third-party scripts by route and owner. Remove integrations that no longer have a business purpose. Use versioned immutable URLs where possible. Add SRI to stable cross-origin scripts and stylesheets. Confirm the CDN provides the CORS behavior SRI requires. Draft a narrow CSP and observe it in Report-Only mode. Avoid broad wildcards and unsafe-inline shortcuts. Protect tag-manager publishing access. Test failure behavior when a dependency is blocked. Review third-party code around login and checkout more strictly. SRI needs a maintenance owner An integrity hash intentionally breaks when the file changes. That is the security feature, but it also creates operational work. Assign ownership for updating hashes during dependency upgrades and make the failure visible in monitoring. Otherwise teams may remove SRI after the first unexpected breakage. Version pinning and automated dependency updates can make this workflow predictable. A change should arrive as a reviewed code update, not as an invisible modification at a third-party URL. Multiple valid hashes can support controlled rollouts SRI can include more than one valid hash. That can help during a planned transition where two exact asset versions are acceptable, although the deployment should not leave obsolete hashes indefinitely. The important point is that each allowed hash represents content you deliberately reviewed and accepted. CSP hashes and SRI hashes solve related but different problems CSP can authorize inline or external script content using hashes, while SRI validates the fetched resource declared by a script or link element. The syntax and browser behavior interact in specific ways, so test the complete policy rather than assuming one hash declaration automatically satisfies both mechanisms. For complex strict CSP deployments, follow current browser guidance and keep the policy generated from the actual build where possible. Remember what an approved third-party script can see A script allowed to execute in the page can often read DOM content, interact with forms, make requests using the page's origin permissions, and observe user behavior. CSP does not sandbox an approved script merely because its origin is listed. Reduce data exposure through application design. Keep sensitive values out of the DOM when scripts do not need them, and avoid loading unnecessary vendors on account and payment pages. Plan for a compromised vendor Know how to disable a third-party script quickly without waiting for a full application release. Tag-manager controls, feature flags, CDN configuration, or an emergency CSP update may help depending on the architecture. After removal, investigate what data the script could access, which routes loaded it, and how long the compromised version was served. SRI can prevent an unexpected file change from executing, but not every integration can be pinned. Generate hashes from the exact artifact you deploy Do not copy an SRI hash from an unrelated blog post or assume two CDN URLs contain identical bytes. Generate the hash from the exact file version and URL that production will load, then test it in a browser. When build tooling fingerprints assets, automate integrity generation as part of the same pipeline so the HTML and asset hash cannot drift apart. Use CSP reporting to find unplanned third parties Report-Only violations can reveal scripts injected by old plugins, tag managers, browser extensions, or new vendor integrations. Group reports by route and blocked origin. Investigate why the resource appears before adding it to the policy. This turns CSP deployment into an inventory exercise instead of an allowlist-expansion exercise. Use each control for the problem it solves SRI answers whether this file changed. CSP answers whether this resource or script execution is allowed. Dependency scanning answers whether a known version has known vulnerabilities. Vendor review answers whether the supplier should be trusted at all. Strong third-party JavaScript security comes from combining those controls rather than asking one of them to do everything.