Link Search Menu Expand Document

Insecure Functionality Exposed in Docker

Docker’s architecture is complex, with many configurations and controls that require careful scrutiny to keep secure.

Exposure of the Docker Daemon

The Docker daemon is the pivotal point in Docker architecture. Only trusted users should be allowed to interact with it since it mostly runs with root privileges (even if an experimental rootless mode is available in the latest versions). It does not actively limit the containers’ access rights to the host, meaning containers can be launched to access the host operating system’s resources, such as its file system or network stack.

For this reason, giving someone access to the Docker daemon is equivalent to giving them root access to the host operating system, and it is a decision that must be made with utmost caution.

Docker provides a REST API, called the Docker Engine API, to facilitate interaction with the Docker daemon via a UNIX socket or a TCP port. It is commonly used by the Docker CLI to communicate with the Docker daemon.

UNIX socket

Utilizing the non-networked /var/run/docker.sock UNIX socket is the default method of accessing the Docker Engine API locally. In the default Docker configuration in Linux, only “root” and users in the “docker” group can access the socket.

TCP socket

The Docker Engine API can be optionally exposed on the network, meaning everyone who can access the TCP port also has full access to the Docker daemon.

Avoiding the exposure of the Docker Engine API to the network is strongly recommended. Even if the TCP port is not reachable from the network, the daemon is still prone to Server-Side Request Forgery attacks, Privilege Escalation, and Container Breakout attacks staged from within compromised containers.

If exposing Docker is absolutely necessary for the network configuration, securing the API endpoints with HTTPS and certificates and ensuring it is reachable only from trusted networks is crucial.

Using port 2375 is conventional for unencrypted communication and port 2376 for encrypted communication with the daemon.

Build process

The build phase involves building Docker images from a Dockerfile and a set of files (called context).


Avoid using ADD in Dockerfile to copy files from the context into the image at build time.

Unlike COPY, the Dockerfile ADD command can fetch remote resources via URL at build time. This could be abused in systems that dynamically generate Dockerfiles, such as Docker-based Continuous Integration or Platform Management systems, to download and install malicious code at build time.


Docker builds and runs the container with the privileges declared in the last USER command in the Dockerfile. If this is not set, it defaults to the high-privileged “root” user. As mitigation, follow the principle of “least privilege”, and drop the container privileges as soon as possible in the build process by adding the USER command to your Dockerfiles.


OWASP Top 10 - Security Misconfiguration

MITRE - CWE 749 Exposed Dangerous Method or Function

Docker - Security

Docker - Protect The Daemon Socket

OWASP - Docker Security Cheat Sheet