No. HTTPS protects a script while it travels, so nobody can change it on the way. It says nothing about whether the file at the source is the one you reviewed. If the CDN, the package publisher or the domain is compromised, the script arrives over HTTPS and runs anyway.
Myth versus fact
| Myth | Fact |
|---|---|
| HTTPS means the script is safe | HTTPS secures delivery. The content can still be wrong at the source |
| A big CDN means no risk | The CDN serves what the publisher uploads, so a publisher account compromise is served at scale |
| SRI is only for paranoid teams | MDN describes SRI as a defense against supply chain attacks where a host is compromised, and it is cheap for static files |
| A CSP allowlist covers third parties | MDN says allowlists are hard to get right and often permit unsafe domains |
| The script is small, so it is harmless | A short script can read form fields and send them out |
Myth 1 in detail
Transport security answers one question: did the bytes change between the server and the browser? Supply chain trouble happens before the server, or at the server. OWASP lists loss of control over changes as a core risk of third party JavaScript, because the vendor can change the file whenever it wants.
Myth 4 in detail
MDN cites research showing allowlists often let in unsafe domains, and notes one developer needed 187 Google domains on an allowlist to integrate Google Analytics. Hosts on an allowlist can include places that serve user content or old libraries with known bypasses. MDN recommends nonce or hash based policies instead. See CSP nonce vs hash vs host allowlist.
What actually helps
- Pin exact versions so the file cannot silently change, see floating versions in CDN URLs.
- Add integrity hashes for static files, see how to add SRI.
- Self-host when you can, see self-host or CDN.
- Limit what scripts can reach with CSP, see CSP and data exfiltration.
- Monitor changes to dynamic scripts, see detecting changes.
- Remove scripts you no longer need.
A fair summary
None of this means CDNs are bad. They are fast and well run. The point is that your trust decision should rest on controls you hold, not on the reputation of the place the file sits. For deeper history of what goes wrong, read CDN supply chain security risks.
Safeguard's dependency scanning and SBOM generation cover the packages that you bundle, and the free scan is at gold.safeguard.sh/scan.
Quick check
Is HTTPS still necessary?
Yes. It stops tampering in transit and is a baseline. It is just not enough on its own.
Does SRI work for every script?
No. It fits static files you pin. Scripts that must change need other controls such as CSP and monitoring.
Sources
- MDN, Subresource Integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity
- MDN, Content Security Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
- OWASP, Third Party JavaScript Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
Last reviewed: 19 October 2026.
