Vulnerabilities
yarn.lock vs package.json on Production Origins
August 31, 2026
yarn.lock vs package.json on a production origin is two Node inventory files that must not sit next to index.html. /package.json donates names and versions — the roast signatures a JSON body with a name field. yarn.lock donates the exact pins, richer for advisory homework. Neither is a pentest, both are maps. RoastMyOpsec may not fetch yarn.lock today. Still deny it at the edge. Do not Disallow lockfiles in robots.txt; deny the objects, do not advertise them.
The practical difference
package.json is the brochure of declared dependencies. yarn.lock is the receipt. Attackers use either as a shopping list. Defenders use lockfiles in private CI and Dependabot — not as CDN files.
Removing /package.json does not patch CVEs. Publishing yarn.lock does not replace a private advisory scan. Fix the public file the same day; schedule the upgrade work separately.
How to choose based on what you shipped
Fail CI if package.json or yarn.lock appear in a static marketing artifact. Deny those basenames at the CDN. Deepen a repo you own for lockfile advisories — that is a different channel than a URL roast. See public package.json vs lockfile advisories.
| Option | When it wins | Watch-out | Takeaway |
|---|---|---|---|
| /package.json | Almost never on the CDN | Declared names and scripts | Roast signatures this path today |
| /yarn.lock | Never on the CDN | Exact pins, richer map | Same class of miss; deny the name |
| Lockfile in private git / CI | Reproducible installs and alerts | Do not export it with the site | Dependabot belongs on the repo |
| robots.txt Disallow | Not for lockfiles | Publishes the path | Edge deny instead |
When each inventory file wins (off the public origin)
package.json wins in the private repo and on the npm registry, not on your brochure host. yarn.lock wins in that same private repo so installs and alerts stay honest. Neither wins as a public object beside index.html.
If Dockerfile shipped in the same export, fix the publish root once. See Dockerfile vs package.json.
Common mistakes
The first mistake is blocking package.json and still serving yarn.lock.
The second mistake is treating a public lockfile as proof you already ran a complete advisory review.
The third mistake is listing yarn.lock in robots.txt Disallow instead of denying it at the CDN.
What a URL roast can prove
Bounded GET to /package.json with a name-field signature. yarn.lock is not a scored path today. Still deny it. No npm install from your site, no exploit of a listed package. A missing package.json is not a claim your lockfile is clean.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is a public yarn.lock a vulnerability?
- It is an information leak. Block it. It is not remote code execution, and it is not harmless inventory on a marketing origin.
- Does RoastMyOpsec fetch yarn.lock?
- Not as a scored path today. It does probe /package.json. Deny yarn.lock at the CDN anyway. Same class of miss.
- Should I keep lockfiles public so users can audit me?
- Publish a security page or a public repo if you want that. The CDN next to index.html is the wrong channel.
Sources
Related guides
Vulnerabilities
Public package.json vs Lockfile Advisories on ProductionVulnerabilities
Dockerfile vs package.json on Production OriginsVulnerabilities
.env.example vs .env on Production Origins