Unexpected external access to Karate mock endpoints during test execution

Question

Symptom
When executing Karate tests that utilize the built‑in mock server, there is uncertainty about whether the mock endpoints are bound only to the intended interface (e.g., localhost) or could become reachable from external networks.
The goal is to confirm that the mock service remains isolated to the test environment and to identify any configuration options that control its network exposure.
What steps can be taken to verify the binding address of Karate mock endpoints? Are there specific Karate configuration properties that restrict the mock server to localhost or a private subnet? Are there known scenarios where accidental public exposure might occur despite default settings?

Tasadduq Burney · Answer

Answering the Core Question

Karate’s built‑in mock server is intended to run only for the current test run. By default it binds to 0.0.0.0, which means it is reachable on every network interface unless you override the host. The following steps let you confirm the binding address, restrict it to 127.0.0.1 or a private subnet, and detect accidental public exposure.

Default Binding Behavior

When no host is configured, the mock server listens on 0.0.0.0 at the port defined by karate.server.port (default 8080).
In a container or CI environment the host may be overridden by the runtime network configuration, making the server visible from the host machine or even the internet if ports are published.

Explicitly Bind to Localhost

Run Karate with the system property:
```
karate -Dkarate.server.host=127.0.0.1
```

Optionally set a random port to avoid clashes:

karate -Dkarate.server.host=127.0.0.1 -Dkarate.server.port=0

In the test code, read the allocated port with karate.server.port so that URLs are constructed dynamically.

Verification Steps

After the test starts, run:
```
netstat -tuln | grep <port>
```
and confirm the output shows 127.0.0.1:<port> (or the private subnet you chose) only.
From an external machine or a different container, attempt:
```
curl http://<host>:<port>/
```
and verify it fails or times out.
If running inside Docker, inspect the container’s network:
```
docker inspect <container> | grep HostPort
```
and ensure the mock port is not mapped to the host (no HostPort entry or it is 0).

Known Accidental Exposure Scenarios

Docker or CI pipelines that automatically publish container ports to the host.
Using karate.env to share a mock instance across tests; the instance may persist beyond the intended test scope.
Firewalls or network bridge rules that forward the mock port to external interfaces.

What to Check Next?

Does your test run inside a container that publishes the mock port, or does your CI system expose the port to the host network? Knowing this will decide whether you need to adjust Docker run flags (e.g., --publish 0) or add firewall rules.

Unexpected external access to Karate mock endpoints during test execution

Symptom

1 answer

Answering the Core Question

Default Binding Behavior

Explicitly Bind to Localhost

Verification Steps

Known Accidental Exposure Scenarios

What to Check Next?

Your perspective belongs here.

1 question comment