Vulnerabilities
Dockerfile vs package.json on Production Origins
June 30, 2023
Dockerfile vs package.json on production origins is two build manifests on a public object store. /package.json donates dependency names and versions — useful for OSV homework, not a pentest. A public /Dockerfile (or docker-compose.yml) donates base images, ports, COPY paths, and sometimes ENV with live-looking secrets someone baked in. Neither belongs next to index.html. A private GitHub repo may keep both. The CDN must not. RoastMyOpsec probes /package.json with a bounded GET. It does not currently score /Dockerfile, does not parse compose files, and does not pull images.
The practical difference
package.json is Node inventory. Dockerfile is how the image is built. docker-compose.yml is how services wire together — often with published ports and .env file references. .env.example is a cousin. .git is a third channel if the whole repo shipped.
A 200 on /Dockerfile is an information leak even when every ENV looks like a placeholder. Deny the names at the edge.
How to choose what to publish
CI: fail if Dockerfile, docker-compose*.yml, package.json, or lockfiles appear in a static marketing artifact. App origins that must serve package.json for a legitimate reason are rare — prefer not. CDN: deny those basenames. Keep Docker files in the private repo. Staging hostnames that are guessable get the same deny list.
| File | Typical leak | Roast today | Takeaway |
|---|---|---|---|
| /package.json | Names and versions | Bounded GET | See public package.json vs OSV |
| /Dockerfile | Base image, ports, ENV | Not scored; deny anyway | Same class |
| /docker-compose.yml | Services and ports | Not scored | Deny the name |
| /.env | Live secrets | Bounded signature GET | See .git vs .env |
When a Dockerfile still wins (off the public origin)
It wins in a private repo and in CI. It never wins as a downloadable object on the marketing bucket. Pair with exposed .svn vs .git if the same zip also shipped a working copy.
What the roast can prove
A reachable /package.json can surface. Dockerfile is not a scored path. Confirm a 404 yourself. Pair with OSV lockfile deepen on a repo you own — that is a different channel than a URL roast.
Common mistakes
The first mistake is copying the whole repo to S3 because 'static export' still had Docker files in the folder.
The second mistake is ARG passwords in a public Dockerfile 'because they are build-time.'
The third mistake is Disallow: /Dockerfile and calling it access control.
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 Dockerfile a vulnerability?
- It is an information leak. Remove it and deny the name. It is not always a credential dump, but it is not harmless.
- Does RoastMyOpsec fetch Dockerfile?
- Not as a scored path today. It does probe /package.json. Deny Docker filenames at the edge anyway.
- Should package.json stay public for npm?
- The registry is the public catalog. The marketing origin does not need to serve the file.
Sources
Related guides
Vulnerabilities
Public package.json vs Lockfile Advisories on ProductionVulnerabilities
firebase.json vs package.json on Production OriginsVulnerabilities
Exposed .git vs .env on Production Websites