T08 · Insecure Dependencies
Warning
- Location
SNIPPETS.md:7- Finding
Third-Party CDN Script Loaded Without Subresource Integrity
- Content
View full analysis
``` ### Technical Analysis The example instructs users to load and execute JavaScript directly from a third-party CDN. Although the dependency version is pinned to `1.1.18`, the script element does not provide a Subresource Integrity (`integrity`) hash. Version pinning prevents ordinary version drift but does not independently verify that the returned artifact matches a trusted, reviewed file. If the package publication, CDN infrastructure, or delivery mechanism is compromised, the remote response could contain modified JavaScript. A browser using this snippet would execute that code in the security context of the consuming website. The project itself is documentation rather than an executable application, so exploitation requires a user to copy or deploy the example. ### Attack Path 1. A developer copies the documented script element into a website. 2. An attacker compromises the relevant package publication or CDN delivery path. 3. The CDN returns an altered `lenis.min.js` artifact for the referenced URL. 4. Because no integrity hash is present, the browser cannot detect that the response differs from the expected artifact. 5. The altered JavaScript executes with the same origin-level browser access as other scripts on the consuming page. 6. Depending on the website and its controls, the payload could read accessible page data, alter content, capture user input, make authenticated requests, or transmit data to an attacker-controlled endpoint. ### Impact Assessment Successful exploitation could compromise users of any website that deploys the snippet. The injected code would receive the normal client-side privileges of JavaScript running on that page, including DOM access, access to non ...[truncated 540 chars]- Remediation
View remediation
``` 3. Generate the hash from an independently obtained and reviewed release artifact; do not copy an unverified hash from the same potentially compromised delivery channel. 4. Continue pinning the exact dependency version and update the integrity hash only after reviewing each upgrade. 5. Apply a restrictive Content Security Policy that limits script sources and outbound connections. 6. Where a package manager and build pipeline are used, enforce lockfiles, dependency review, checksum verification, and automated supply-chain scanning. 7. Document that the placeholder integrity value must be replaced with the verified hash before deployment. ]]>