Known fallback PRELOOP_SYSTEM_TOKEN makes direct server launches insecure by default

[Bnjoroge1]

Severity

P1 / high security configuration

Review baseline

0bd0e314696e520aa47620cbe8f008d010e01e57

Summary

Direct AppState initialization falls back to the constant preloop-system-token when PRELOOP_SYSTEM_TOKEN is unset. That token grants highly privileged server operations.

The installer may generate a token for managed installs, but the server/library behavior itself remains predictable. A directly launched or misconfigured instance that is reachable outside localhost can therefore expose a known administrative credential.

Impact

• Anyone who knows the default can authenticate to system-token protected surfaces on an exposed instance.
• Local development defaults can accidentally escape into staging/production.
• Documentation can give a false sense that the token is generated when the core server still has a fixed fallback.

Recommended remediation

• Remove the constant fallback outside tests.
• Either require PRELOOP_SYSTEM_TOKEN at startup or generate a cryptographically random token and persist it securely on first initialization.
• Refuse to bind non-loopback interfaces when running with an insecure development token.
• Emit an explicit startup error rather than a warning for production-like binds.
• Add a test proving production server startup fails without an explicit/generated secret.

Acceptance criteria

• A production server never uses a hard-coded administrator token.
• Unset configuration either causes startup failure or creates a unique persisted secret.
• Tests/dev fixtures can still opt into a deterministic token explicitly.
• Documentation exactly matches runtime behavior.