If you believe you've found a security issue in Totals-Engine, please do not open a public GitHub issue. Instead, email:

spacedetached@gmail.com

Please include:

• A description of the issue and what an attacker could do with it.
• Steps to reproduce, including any sample requests, payloads, or configuration the issue depends on.
• Any prior disclosure context (e.g., if you've reported it elsewhere).

We aim to acknowledge new reports within 3 business days and to ship a fix or a documented mitigation within 30 days for high-severity issues. Lower-severity issues are batched with regular releases.

If you'd prefer GitHub's coordinated-disclosure flow, you can also report via GitHub Security Advisories on this repository.

Totals-Engine is designed around a zero-knowledge principle. The following claims are load-bearing — if you can break any of them, that's a security issue we want to hear about:

1. The server cannot read user content. Group names, member display names, shared expenses, recovery vaults — all are encrypted on-device before they reach the server. Compromise of the database alone should not expose plaintext user data.
2. Per-device identity is rooted in client-side Ed25519 keys. The server never holds private keys. All authenticated requests are verified against the device's public key via challenge-signature.
3. Push notifications are content-free doorbells. The body of an FCM or APNs message contains only routing hints (group ID, payload ID). Any content reaching Google or Apple is a finding.
4. Per-IP rate limits hold under realistic conditions. When the service is deployed behind a configured reverse proxy with TRUSTED_PROXY_IPS set, a single attacker should not be able to bypass per-IP limits by spoofing headers.
5. Recovery codes have ~80 bits of entropy (16-character Crockford base32). Brute-forcing one online should be infeasible within the configured per-IP rate limits.

• The HTTP gateway (apps/gateway)
• The background worker (apps/worker)
• The shared crypto, db, config, and types packages
• The migration history under packages/db/drizzle/

• The dashboard app (apps/dashboard). It is a developer / operator tool and is explicitly not intended for production deployment by self-hosters. Documented dashboard exposure is not a vulnerability.
• Vulnerabilities in third-party dependencies that have not yet been upstream-disclosed. Please report those to the dependency's maintainers first.
• Issues that require physical access to a user's unlocked device.
• Self-hosted deployments where the operator has intentionally weakened defaults (e.g., set ENABLE_AUTH_SIGN_UP=true and exposed the dashboard publicly). The defaults ship locked down; if you override them, that's on you.

We will not pursue legal action against researchers who:

• Make a good-faith effort to comply with this policy.
• Avoid accessing, modifying, or deleting other users' data.
• Avoid degrading service for other users (no DoS testing on the production instance — use pnpm dev locally or run your own deploy).
• Give us a reasonable window to ship a fix before public disclosure.

Thank you for helping keep Totals users safe.