Please report vulnerabilities privately — do not open a public issue for security problems.

• Open a private security advisory on this repository.

You should receive an initial response within 7 days. Please include reproduction steps and the affected version.

DreamLoop is a local-first, single-user application. Its security posture is intentionally simple:

• Trust boundary is the machine, not the app. All data (SQLite database, config, generated images, exports) lives in .dreamloop/ under the directory where DreamLoop runs. Anyone with filesystem access to that directory can read every dream.
• Loopback is unauthenticated; non-loopback binds require a token. dreamloop web binds to 127.0.0.1 by default with no authentication. Binding to a non-loopback host (e.g. --host 0.0.0.0, which the Docker image does) automatically enables token auth: a token is generated into .dreamloop/web_token (or taken from DREAMLOOP_TOKEN) and the startup log prints the access URL containing ?token=... — in Docker, read it via docker logs. Passing --no-auth or setting DREAMLOOP_NO_AUTH=1 disables this and exposes the full journal, unauthenticated, to anyone who can reach the address; only do that when the port is published on loopback (as the bundled docker-compose.yml does) or on a network you fully trust.
• API keys are stored in plaintext in .dreamloop/secrets.env. DreamLoop calls os.chmod(0o600) on the file, but on Windows this only affects the read-only flag — it does not restrict other users' access the way POSIX permissions do. Rely on full-disk encryption (BitLocker, FileVault, LUKS) and OS account isolation to protect secrets and dream data at rest.
• Cloud AI is opt-in. Dream text only leaves the machine after you explicitly configure a cloud provider. Ollama keeps analysis local.

Reports about hardening within this model (path traversal, injection via dream text, secret leakage into logs or rendered pages) are very welcome. Reports assuming a hostile local user on the same OS account are outside the model.