Vulnerabilities
.dockerignore vs Dockerfile on Production Origins
July 8, 2023
.dockerignore vs Dockerfile on a production origin is two build-context files that must not be public objects. /Dockerfile is the image recipe. /.dockerignore is the list of paths you kept out of the context — often the same family as .env, keys, and node_modules. Serving either next to index.html is the same class of miss as /package.json. RoastMyOpsec probes /package.json with a bounded GET. It does not currently score /Dockerfile or /.dockerignore. Still deny those names at the edge. Do not advertise them in robots.txt.
The practical difference
Dockerfile tells the builder how to assemble the image. .dockerignore tells the builder what not to send. Together they describe your private tree more clearly than a marketing page ever should.
A public ignore file is not 'safe because it only lists exclusions.' It is a map of names you considered sensitive. Keep both files in the private repo. The CDN is not a build context.
How to choose based on what you shipped
CI should fail if Docker files appear in a static marketing artifact. CDN rules should deny those basenames even when CI is clean. If you already published them, take the objects off the origin and stop copying the repo root into the bucket. Pair with /package.json if the same export shipped Node inventory.
| Option | When it wins | Watch-out | Takeaway |
|---|---|---|---|
| Dockerfile in a private repo | CI image builds you control | ENV and ARG can still look live | Never as a CDN object |
| .dockerignore in a private repo | Keeps secrets out of the image context | Public copy names what you hid | Deny the name at the edge |
| Either file on the origin | Never | Same class as /package.json | Strip from the publish artifact |
| /package.json on the origin | Almost never | Inventory gift | Roast signatures this path today |
When each file still wins (off the public origin)
Dockerfile wins in private CI. .dockerignore wins in that same private context so local secrets never enter the image. Neither wins as a downloadable object on the brochure site.
Guessable staging hosts need the same deny list. A 404 on one path is not proof the other file is gone.
Common mistakes
The first mistake is copying the whole git working tree to the static bucket because 'the site is just HTML.'
The second mistake is treating .dockerignore as harmless metadata while it names .env and key files.
The third mistake is Disallowing Docker filenames in robots.txt instead of denying them at the CDN.
What a URL roast can prove
The roast signatures /package.json today. Dockerfile and .dockerignore are not scored paths. Confirm in the bucket that they are absent, then deny the names so a future sync cannot republish them. Bounded GETs only. No image pull, no context parse.
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 .dockerignore a vulnerability?
- It is an information leak. It often names the files you tried to keep private. Remove it from the origin and deny the basename.
- Does RoastMyOpsec fetch .dockerignore or Dockerfile?
- Not as scored paths today. It does probe /package.json. Deny Docker filenames at the edge anyway. Same class of miss.
- If the Dockerfile has no secrets, can it stay public?
- Not on the marketing origin. Base images, ports, and COPY paths are still a map. Keep it in the private repo.
Sources
Related guides
Vulnerabilities
Dockerfile vs package.json on Production OriginsVulnerabilities
Public package.json vs Lockfile Advisories on ProductionVulnerabilities
Exposed .git vs .env on Production Websites