Security

Accounts and sessions

• Passwords are at least 12 characters and are stored only as a hash.
• Email verification is required before sign-in. Verification and password recovery use six-digit codes that are hashed at rest, expire after five minutes, allow three attempts, and cannot be replayed once used.
• Resetting a password revokes existing sessions.
• Every request is authorized against a database-validated session. Identity headers and URL parameters are never trusted, in any environment.
• Registration, sign-in, reset, and verification endpoints are rate limited.

Data handling

• Account references are minimized: at most the last four digits are kept, enforced in the form, the API, and the database.
• The database is reachable only on a private network and is not published to the public internet. The application connects with a least-privilege role that cannot alter schema.
• Backups are encrypted on the client before being written to off-site storage, and restores are exercised on a schedule rather than assumed to work.
• Traffic is served over HTTPS, with HTTP redirected.

Release process

Every change must pass linting, a dependency audit, unit tests, an isolated database migration replay, a full authentication lifecycle check, a production build, and a container smoke test before it can be released. Releases deploy the exact artifact that passed those checks, pinned to a commit, and a release is not exposed until its matching database migration has succeeded.

Reporting a vulnerability

Please report suspected vulnerabilities privately to [email protected], with enough detail to reproduce the issue. Do not post it publicly, and do not access or modify data belonging to anyone else while investigating. You will get an acknowledgement, and we will tell you when the issue is resolved.