Docker in production: 5 configurations that expose your data

Docker simplifies deployment. Not security.

Docker has become the deployment standard for web applications. But the ease of setup masks major security risks. In audits, we find these 5 configuration mistakes in most SMBs.

Configuration 1: Docker socket exposed on the network

The Docker socket (/var/run/docker.sock) gives total control over the Docker daemon. When mounted in a container or exposed on the network via the TCP API (port 2375/2376), an attacker can create containers, read volumes, and take complete control of the host server.

We regularly find Portainer interfaces or Docker APIs exposed without authentication on the internet. A Shodan scan reveals thousands of instances in France.

Configuration 2: Containers running as root

By default, processes in a Docker container run as root. If an attacker exploits an application flaw, they gain root privileges in the container — and potentially on the host if the container has elevated capabilities or sensitive mounted volumes.

The fix is simple: add USER nonroot in your Dockerfile and user: "1000:1000" in your docker-compose.

Configuration 3: Secrets in unprotected environment variables

Passing passwords and API keys via environment variables in docker-compose.yml or command line exposes them in Docker logs, container inspections (docker inspect), and processes (/proc/*/environ).

Use Docker Secrets or an external secrets manager (Vault, AWS Secrets Manager). Never commit .env files containing secrets.

Configuration 4: No network segmentation

All containers on the same default Docker network. Your PostgreSQL database is directly accessible from your frontend container. If the frontend container is compromised, the database is directly reachable.

Create separate Docker networks: a frontend network, a backend network, a database network. Only containers that need to communicate share a network.

Configuration 5: Outdated images with known CVEs

Docker images based on outdated versions of Node.js, Python, or Alpine with known vulnerabilities. Many SMBs build a Docker image once and never rebuild it.

Use docker scout or Trivy to scan your images. Automate weekly image rebuilds with the latest base versions.

How we detect these issues

Our external review identifies Docker interfaces exposed on the internet, open management ports, and headers revealing dangerous Docker configurations. For internal configurations (root, secrets, network), we recommend a targeted configuration audit.