Network exposure in code and service config

Why this area matters

Databases and caches exposed to the internet without authentication are a steady source of data leaks; services bound to 0.0.0.0 or published from a compose file are often reachable far beyond where the developer intended. Cleartext transport (CWE-319) and disabled certificate validation (CWE-295) let anyone on the path read or change traffic.

Scanners flag 0.0.0.0 and HTTP URLs everywhere, including local development and health checks. The network agent checks which environment the config is for, whether the service requires authentication and whether traffic leaves a private network.

What goes wrong in real applications

• Datastores exposed without authentication

  Redis, MongoDB, Elasticsearch and similar services published on all interfaces with auth disabled can be read or wiped by anyone who can reach them.

• Cleartext protocols

  HTTP, FTP, telnet and unencrypted database connections expose credentials and data in transit.

• Disabled certificate validation

  Skipping TLS verification makes encrypted connections open to interception.

• Over-broad binding

  Services bound to 0.0.0.0 when they only need localhost or a private network are reachable from more places than intended.

Sample: the risky pattern and the fix

services:
  redis:
    image: redis:7
    command: redis-server --protected-mode no
    ports:
      - "6379:6379"
  mongo:
    image: mongo:8.2
    ports:
      - "27017:27017"

services:
  redis:
    image: redis:7
    command: redis-server /run/secrets/redis_conf   # requirepass, protected-mode yes
    secrets: [redis_conf]
    networks: [backend]                             # no published ports
  mongo:
    image: mongo:8.2
    environment:
      MONGO_INITDB_ROOT_PASSWORD_FILE: /run/secrets/mongo_root_password
    secrets: [mongo_root_password]
    networks: [backend]
networks:
  backend:
    internal: true
secrets:
  redis_conf:
    file: ./secrets/redis.conf
  mongo_root_password:
    file: ./secrets/mongo_root_password

The production compose file publishes Redis with protection disabled and MongoDB without credentials on every interface of the host. The fix keeps both on an internal network with no published ports and enables authentication with credentials supplied as secrets rather than in the file.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Ports and bind addresses in compose files, Kubernetes services and application config
• Datastore and cache settings: authentication, protected mode, TLS
• HTTP, FTP and telnet URLs and clients for non-local traffic
• TLS verification flags in HTTP clients and database drivers
• Whether a config is for local development or production (the main false-positive signal)

Scope and limits

• It doesn't scan networks, ports or hosts and never sends traffic — it reviews the configuration and code that define your services.
• Firewalls, cloud network rules and load balancers outside the repository may already block a flagged port; the finding says what the repo alone allows.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Network & transport security — Checks that data in transit is encrypted and certificates are actually verified.
• Infrastructure & IaC — Reviews Terraform, Helm, Ansible and server config for insecure defaults and exposure.
• Container & Kubernetes — Checks Dockerfiles and Kubernetes manifests for root, privileged and host-level access.