Database Port Published to Every Interface

Why it matters

Services in the same compose project reach each other by name on the internal network; they never need the port published. Publishing it is only for tools on your own machine, and binding to 127.0.0.1 gives you that without exposing it to the network.

What it looks like

This is the shape of code that triggers the rule. AI tools produce it because it works, and nothing tells them it is unsafe.

services:
  db:
    image: postgres:16
    ports:
      - "5432:5432"

The smallest fix

services:
  db:
    image: postgres:16
    # remove ports: entirely; the api reaches it as db:5432
# If you need a local client, bind to loopback only:
ports:
  - "127.0.0.1:5432:5432"

The better fix

If you have a few more minutes, this is the approach that holds up as the app grows.

# Keep a separate docker-compose.dev.yml for local tooling with the
# loopback binding, and no ports: on data services in the production
# file. Put admin UIs behind the reverse proxy with authentication.

Let your AI tool fix it

When the scanner finds this in your project, it fills in the file and line for you. This is the prompt it gives you to paste into Claude Code, Cursor or whatever you use.

How to check the fix worked

1. Run `docker compose ps` and confirm the data service shows no
   0.0.0.0 port mapping.
2. Confirm the application still connects to the database by service
   name.

Further reading

• https://cwe.mitre.org/data/definitions/668.html