No Docker Health Check
Without a HEALTHCHECK instruction, Docker and orchestrators can't detect when your container is running but broken — routing traffic to a dead app.
How It Works
A container can be in 'running' state while the application inside has crashed or deadlocked. Without a HEALTHCHECK, Docker marks the container healthy by default. Kubernetes and Docker Swarm continue sending traffic to it. Users get errors while the orchestrator thinks everything is fine.
# BAD: no HEALTHCHECK — container is 'healthy' even when app crashes
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci
EXPOSE 3000
CMD ["node", "server.js"]# GOOD: HEALTHCHECK tells orchestrators when the app is actually ready
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
CMD wget -qO- http://localhost:3000/health || exit 1
CMD ["node", "server.js"]Real-World Example
Several high-traffic deployments have experienced silent outages where containers showed as healthy in Kubernetes dashboards while serving 500 errors to all users — because the app had locked up but the container process was still alive.
How to Prevent It
- Add a HEALTHCHECK to every production Dockerfile that hits a /health endpoint
- Implement a /health endpoint in your app that checks critical dependencies (DB connection, cache)
- Set realistic --interval, --timeout, and --retries values based on your app's startup time
- Test health check behavior by intentionally crashing the app and verifying the container becomes 'unhealthy'
Affected Technologies
Data Hogo detects this vulnerability automatically.
Scan Your Repo FreeRelated Vulnerabilities
Running as Root in Docker
mediumContainers that run as root give any code execution vulnerability immediate root access to the container — and potentially the host.
Docker Latest Tag
lowUsing FROM image:latest means a new pull can silently change your base image, breaking reproducibility and potentially introducing vulnerabilities.
Secrets in Dockerfile
criticalSecrets added via ENV, ARG, or COPY .env in a Dockerfile are baked into the image layers and readable by anyone who pulls the image.
Unnecessary Exposed Ports
lowEXPOSE-ing ports your application doesn't actually use increases the attack surface without any benefit.