Inspectable controls for private, authorized activity analytics.

Security model

StatStoat separates public content, authenticated web access, and privileged desktop functionality. The public website cannot call the Electron bridge. In production, the edge verifies dashboard sessions through the authentication service, and the dashboard checks the session again before rendering web content.

Account and session controls

• Passwords are processed with per-user salts and Node.js scrypt. Plaintext passwords are not persisted.
• When Google sign-in is enabled, StatStoat uses the OAuth authorization-code flow and stores the provider subject and verified account email—not a Google password or access token.
• When password-account verification is enabled, only the SHA-256 hash of the random verification token is persisted. Raw tokens are not logged or written to the account data file.
• Verification tokens expire, are single-use, and are replaced by a resend. The link keeps its token in the URL fragment, which is not included in the initial page request; changing account state requires an explicit confirmation request.
• Never-verified accounts are pruned after a configurable pending-account period so abandoned registrations do not remain indefinitely.
• Session values are cryptographically random and delivered in an HttpOnly, SameSite=Lax cookie. Production cookies are Secure.
• Only SHA-256 hashes of session values are written to the data file. Raw session tokens are not logged.
• Sessions expire and are pruned. Signing out removes the presented session and clears its cookie.
• Registration and login have per-address fixed-window limits. Request bodies and HTTP headers are bounded.
• When APP_ORIGIN is configured, state-changing authentication requests require an exact matching Origin.
• Account and session changes are serialized and written through a same-directory temporary file plus atomic rename.

The consent step gates authentication options but does not give the public website or account service access to local WhatsApp contact activity. Optional verification mail is enabled only with explicit server configuration; its link should be treated as a temporary bearer secret.

Desktop and local-data boundary

The Electron application loads its exported interface through the private trackwapp:// application protocol. The renderer is sandboxed and context isolated; a preload script exposes a narrow allowlist instead of unrestricted Node.js access.

Live WhatsApp behavior depends on the local desktop runtime and the user’s signed-in WhatsApp Web session. Marketing and authentication pages are not given that bridge. Navigations outside the private application origin are not treated as privileged application pages.

Contact history, preferences, and diagnostics remain local unless the user explicitly exports data or enables an external notification destination.

Operate StatStoat safely

• Use a unique passphrase and keep your operating system and desktop application current.
• Sign out of shared browsers and protect the device account that holds local contact history.
• Use HTTPS webhook destinations you control, and avoid placing secrets in webhook URLs.
• Review exported files before sharing them and delete them when they are no longer needed.
• Revoke a session and rotate affected credentials immediately if exposure is suspected.

Request a private reporting path

The project does not currently advertise a verified public or private reporting address. Authorized repository collaborators should request a private path through their existing project access. Other users should not publish vulnerability details and should wait for a verified reporting channel to be added to this page.

Once a private path is established, include the affected component, reproducible redacted steps, likely impact, and a suggested remediation if available. The project does not currently advertise a paid bug-bounty program.