No, not for production. A floating version such as latest or a major only range lets the file behind the URL change without any commit from you. Pin an exact version and add an integrity hash, so a new or tampered file is refused instead of run.
What floating looks like
Public npm CDNs let you request a package file by name. jsDelivr's documentation shows the options:
| URL form | What you get |
|---|---|
| An exact version, for example jquery@3.1.0 | That version only |
| A range, for example jquery@3 or jquery@3.1 | The newest matching version |
| No version or latest | The newest published version |
The jsDelivr docs say requesting latest is not recommended for production and call it dangerous because major versions usually come with breaking changes. That is the stability argument. The security argument is the same: content you never reviewed can arrive on your pages.
Why ranges are a supply chain issue
If a maintainer account is compromised and a new version is published, a range URL can serve it to your visitors the next time the CDN cache refreshes. The jsDelivr docs say version aliases, including latest, are cached for 7 days, while exact versions are cached for a year and cannot be updated.
That cache note matters for incident response too. Purging aliases clears the alias cache, but the docs say purging does not affect exact version links, which stay stable.
How to fix a floating URL
- Find every CDN script and stylesheet tag. See how to list every third-party script.
- Replace each range with the exact version you have tested.
- Compute the hash of that exact file and add integrity with crossorigin set to anonymous. This guide shows the commands.
- Record the version in a file your team reviews, so upgrades become pull requests.
- Better still, move the library into your own build, see self-host or CDN.
A pull request check
A tiny script can fail the build when a script URL contains latest, a bare package name or a version without all three numbers. It takes a few lines and prevents drift.
Common objections
- "We want automatic security fixes." Then bump the pinned version through a reviewed change, ideally prompted by a dependency alert. Automatic is the problem, not the fix.
- "The CDN is reputable." The risk is the package publisher account, not just the CDN.
- "SRI is a hassle." Generate hashes in the build and the hassle goes away.
Safeguard's dependency scanning can tell you which versions in your repositories have known advisories, and the free scan at gold.safeguard.sh/scan is a quick way to see your own. For the related incident pattern, read CDN supply chain security risks.
Quick check
Is a major version range like @3 acceptable?
It is better than latest, but it still lets unreviewed minor and patch releases through. Pin all three numbers for production.
Will an integrity hash work with a range URL?
It will break the first time the file changes, which is the point of the hash. Use exact versions so the hash stays valid.
Sources
- jsDelivr documentation (README): https://github.com/jsdelivr/jsdelivr/blob/master/README.md
- MDN, Subresource Integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity
Last reviewed: 19 October 2026.
