ADD https://example.com/tool.tar.gz /tmp/ downloads whatever the URL returns at build time and puts it in the image, with nothing checking that it is the file you expect. If the server, domain or CDN is compromised, or the file is replaced, your image changes silently. Add --checksum=sha256:… so the build fails on a mismatch, or download with curl and verify with sha256sum.
openrouting — dockerfile explainer
$ explain Dockerfile! ADD fetches a remote URL mediumline 2fix: see below$
What the free Dockerfile explainer reports on the risky example below.
Why it matters
A URL is not a pinned artifact. The same ADD line can produce different images on different days, and the image does not record the file's hash for you.
Downloads usually feed straight into binaries the container will run, so a tampered file becomes code running in your production image.
The explainer skips ADD lines that use --checksum, which is Docker's built-in verified download. Note that ADD does not unpack archives fetched from a URL; only local tar archives are extracted.
Risky and safer Dockerfile
RiskyDockerfile
FROM debian:12-slim
ADD https://example.com/releases/tool-2.3.1-linux-amd64 /usr/local/bin/tool
RUN chmod 0755 /usr/local/bin/tool
USER 10001
HEALTHCHECK CMD ["tool", "--version"]
CMD ["tool", "serve"]
SaferDockerfile
FROM debian:12-slim
ADD --checksum=sha256:<published sha256 for this file> \
https://example.com/releases/tool-2.3.1-linux-amd64 /usr/local/bin/tool
RUN chmod 0755 /usr/local/bin/tool
USER 10001
HEALTHCHECK CMD ["tool", "--version"]
CMD ["tool", "serve"]
How to fix it
Pin a specific release URL rather than a latest or nightly link.
Add --checksum=sha256:<hash> with the hash the project publishes, so the build fails if the file changes.
Alternatively, download with curl and check it with sha256sum -c in the same RUN, which also lets you extract and clean up in one layer.
When it's acceptable
Files from a source you control that is itself content-addressed (for example an artifact store URL that includes the file's hash), though --checksum is still cheap insurance.
Check your own Dockerfile
The risky example is loaded below. Paste your own file to check it for this and every other Dockerfile rule. It runs in your browser; nothing is uploaded.
Adds https://example.com/releases/tool-2.3.1-linux-amd64 to /usr/local/bin/tool in the image. One source is a URL, which is downloaded at build time. Prefer COPY plus a checked download for anything you do not control.
ADD downloads whatever the URL returns at build time with nothing checking it is the file you expect.
Safer: Download a pinned version with curl, verify its published checksum (sha256sum -c), then install it in the same RUN.
Sets the default command to tool serve. It runs when the container starts, and anything passed to docker run replaces it.
Questions
Is ADD with a URL safe in a Dockerfile?
Not on its own: it downloads whatever the URL serves with no integrity check. Adding --checksum=sha256:… makes Docker verify the file and fail the build on a mismatch.
Does Dockerfile ADD extract a tar.gz downloaded from a URL?
No. ADD only auto-extracts local tar archives. A remote archive is saved as a file, so you still need a RUN tar step.
Should I use ADD or curl to download files in a Dockerfile?
Either can be safe if the download is verified. ADD --checksum is concise; curl plus sha256sum -c in one RUN lets you extract and delete the archive in the same layer.