Yes. In Docker Compose, a ports entry such as 5432:5432 with no host IP binds to all interfaces. Docker's documentation warns this bypasses host firewall rules and can expose the container to the internet if the host has a public IP. Bind to 127.0.0.1, or do not publish the port.
What the documentation says
The Compose reference states that if you do not specify a host IP, Docker binds to all interfaces, 0.0.0.0, bypassing host firewall rules. It adds that this can expose the container directly to the internet if the host has a public IP address.
The Docker networking documentation agrees. It says publishing container ports is insecure by default: the port becomes available not only to the Docker host but to the outside world. If you include the localhost address with the publish flag, only the Docker host can access the port.
Three ways to write it
services:
db:
image: postgres:17
ports:
- "5432:5432" # all interfaces
- "127.0.0.1:5432:5432" # host only
And a third option, which is often the right one, is to publish nothing:
services:
db:
image: postgres:17
expose:
- "5432"
| Option | Who can connect | When to use |
|---|---|---|
| 5432:5432 | Anyone who can route to the host | Rarely, and with a firewall you have tested |
| 127.0.0.1:5432:5432 | Processes on the host | Local tools such as a SQL client |
| No published port | Containers on the same network | App and database in one Compose project |
The Compose reference lists the loopback forms as valid examples, including an IPv6 form written as ::1 in brackets.
Why developers get caught
A laptop on a coffee shop network or a cloud VM with a public address makes the risk real. The mapping looks harmless in a tutorial, the database starts with a default password, and the port is open. Even a short lived dev box can be reached while it is up, so treat it as exposed.
A related risk is a development database with weak authentication. See what trust means in pg_hba.conf for why an unauthenticated login plus an exposed port is a bad pairing.
A checklist for Compose files
- Search every compose file for ports entries that start with a bare number.
- Add the loopback address to each one that needs host access.
- Remove the mapping where only other containers need the database, and use the service name on the shared network.
- Check for override files and profiles that add ports back.
- Set a real password through a secret, not a default in the file. See Compose secrets or environment variables.
- After starting, run a port check from another machine to confirm the port is closed.
The OWASP database cheat sheet gives the same direction in general terms: bind the database to localhost where possible and restrict network access to specific hosts. Our summary is in what OWASP says about securing a backend database.
Do not forget cloud dev environments
Remote development environments can forward ports and set visibility. See cloud dev environment port forwarding visibility for that case.
Safeguard scans container images and dependencies and can gate pull requests with policies. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Run the container scan and look at what it reports about the image. It shows what is inside the image, which is separate from how its ports are published.
Click through it at your own pace, or open it full screen.
Quick check
Does Docker respect my host firewall for published ports?
The Compose docs warn that without a host IP, Docker binds to all interfaces and bypasses host firewall rules.
How do I publish only to my machine?
Include 127.0.0.1 in the mapping, as in 127.0.0.1:5432:5432.
Do containers on the same network need a published port?
No. They reach the service by name over the network without publishing it to the host.
Sources
- Docker Compose: services reference
- Docker: Port publishing and mapping
- OWASP: Database Security Cheat Sheet
Last reviewed: 19 October 2026.
