No. In twelve-factor, an app exports HTTP by binding to a port, but that only makes it listen. Who can reach it depends on the routing layer in front: published ports, services, load balancers and ingress rules. Exposure is a deployment decision, so review it at the routing layer.
What port binding means
The methodology says a twelve-factor app is self-contained. It does not rely on a webserver being injected into the environment. It exports its service by binding to a port and listening. In deployment, a routing layer sends requests from a public hostname to the port-bound processes. The methodology also notes that any server software can be exported this way, including protocols other than HTTP, and that one app can be the backing service for another by being named in the other's config.
That last point is the security one. Every port-bound process is a network service, whether you meant it as public or internal.
Three layers, three questions
Treat exposure as a stack and ask a question at each layer.
| Layer | Question to ask |
|---|---|
| The process | Which interface does it listen on, and does it need to listen on all of them |
| The platform | Is the port published to the host, a cluster internal address or a public load balancer |
| The routing layer | Which hostnames and paths does the ingress or gateway send to this service |
Listening on every interface inside a container is normal, because the container has its own network namespace. The risk appears when the platform publishes that port more widely than intended. A published database port on a compose file that binds all host interfaces is a classic example; see Docker Compose database ports.
Internal does not mean safe
Because port binding lets apps call each other, a flat network lets any workload reach any port. Two habits help.
- Default deny between workloads. Start from no allowed traffic and add the paths you need. The Kubernetes security checklist recommends default network policies that deny ingress and egress in every namespace and select all pods, so no workload is missed. Our how to guide shows the steps.
- Authenticate callers anyway. Network position is a weak identity. Use service tokens or mutual TLS between services; see mTLS or service tokens.
Admin and debug ports
Many frameworks bind a second port for health, metrics or debugging. These are port-bound services too. Keep them on a separate internal port, do not route them through the public ingress, and require authentication where the data is sensitive. The Kubernetes checklist also says the API server, kubelet API and etcd should not be exposed publicly on the internet, which is the same idea applied to the platform itself.
A quick audit
- List every Service and load balancer and the ports they publish.
- Compare each public route with the list of things you intend to be public.
- Look for ports that serve health, metrics or debug data.
- Confirm default deny policies exist in each namespace.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the API scan and look at which exposed endpoints are flagged, which is the same question you ask of every bound port.
Quick check
Should my container listen on 127.0.0.1 or 0.0.0.0?
Inside a container you usually need all interfaces for the platform to reach the process. Control exposure with port publishing, services and network policy instead.
Is a ClusterIP service private?
It is reachable only from inside the cluster network, but any workload there can call it unless a network policy says otherwise.
Where do health and metrics ports belong?
On an internal port that is not routed through the public ingress, with authentication if the data is sensitive.
Where Safeguard fits
Safeguard's asset discovery helps you build an inventory of what you run, and its dependency and image scanning flag known vulnerable components behind each exposed service. Start with a free scan.
Sources
Last reviewed: 19 October 2026.
