Remove hardcoded MongoDB root credentials from docker-compose.yaml (CWE-798)

[sebastiondev]

Summary

docker-compose.yaml ships with hardcoded MongoDB root credentials (admin / memsys123) and publishes the database on 27017:27017 to the host. Anyone who clones the repo and runs docker compose up without manually editing the file ends up exposing a MongoDB instance with publicly-known root credentials — which is trivially discoverable by Shodan-style scanners and search-engine indexing of the repository.

This PR removes the hardcoded password and forces the operator to supply one via environment / .env.

Vulnerability details

• CWE-798: Use of Hard-coded Credentials
• Severity: High (full unauthenticated DB root access from the network)
• Affected file: docker-compose.yaml (the mongodb service block), with the same secret mirrored as a default in env.template
• Exposure: the same compose file maps 27017:27017, so the credentials are reachable on any interface the Docker host listens on

Exploit sketch

On any host where an operator has run docker compose up from an unmodified clone:

mongosh "mongodb://admin:memsys123@victim-host:27017/admin"
# → full read/write access to every database, including the ability to
#   create users, drop collections, and read application data.

The credentials are publicly visible in the repo, so no guessing is required.

Fix

# docker-compose.yaml
environment:
  MONGO_INITDB_ROOT_USERNAME: ${MONGODB_USERNAME:-admin}
  MONGO_INITDB_ROOT_PASSWORD: ${MONGODB_PASSWORD:?MONGODB_PASSWORD must be set in .env – see env.template}

# env.template
-MONGODB_PASSWORD=memsys123
+MONGODB_PASSWORD=  # REQUIRED: set a strong password before running docker compose

Rationale:

• The ${VAR:?error} form makes Compose fail fast if MONGODB_PASSWORD is unset or empty, so operators can't silently inherit a known-bad default.
• The username default (admin) is preserved because it is not the secret material; the password is.
• env.template no longer carries a working credential — it carries a clear REQUIRED marker so that a copy-paste-and-forget workflow surfaces the missing value immediately.

What I tested

• docker compose config with no MONGODB_PASSWORD set → fails with the configured error message, as intended.
• docker compose config with MONGODB_PASSWORD=somevalue exported → renders correctly with the supplied value.
• Diff is minimal: only the two lines that contained / mirrored the hardcoded secret are touched, plus a short comment explaining the contract. No service behaviour changes for operators who already configure the env var.

Adversarial review

Before submitting I tried to talk myself out of this one. The compose file is the actual runtime artifact a self-hoster uses, port 27017 is mapped to the host with no reverse-proxy in front of it, and there is no application-layer guard that would prevent direct connections — so neither network position nor framework protections mitigate the issue in the default deployment. The credentials are also already public in the repo, which removes any "attacker needs prior access" caveat. The docs under docs/installation/ still mention memsys123 in examples; that's poor hygiene worth a follow-up sweep, but those are documentation strings, not executable defaults, so this PR focuses on closing the runtime exposure.

References

• CWE-798: Use of Hard-coded Credentials
• OWASP Secrets Management Cheat Sheet
• Compose file reference – variable substitution :?

cc @lewiswigmore