Updated 2 November 2026
Security
A disclosure policy with a real scope, rather than a promise that everything is safe.
Reporting
Send a description, the URL or endpoint, and the smallest reproduction you can manage. Please do not include personal data from other users in a report.
Security contact: no address is configured for this deployment yet — set NEXT_PUBLIC_CONTACT_EMAIL before launch.
/.well-known/security.txt carries the same address in machine-readable form.
In scope
- Authentication, sessions and the account pages.
- The operator console and its APIs, including anything that bypasses a login.
- The public API: key handling, authorization between keys, rate-limit bypass.
- Injection, SSRF, path traversal, or any endpoint that reaches the database.
- Exposure of secrets — environment values, API keys, licence tokens.
- Access control on contributions and saved views (one account reading another).
Out of scope
- Denial of service, load testing, or automated scanning against the live service.
- Reports that require a compromised device, a rooted phone, or physical access.
- Missing headers with no demonstrated impact, or a score from a scanner alone.
- Social engineering of the operator.
How this is handled
Acknowledgement within a few working days is the aim, not a contract. Fixes are prioritised by impact; there is no paid bounty programme. Reporters are credited if they want to be, and not otherwise.
Please give a reasonable window before publishing. Anything that turns out to expose user data will be disclosed with the fix, because a quiet patch is not the same as a resolved problem.
What is already in place
- Per-address rate limits on every write and on the API, counted in Postgres.
- Passwords hashed with scrypt; session tokens stored only as SHA-256 hashes.
- Operator console fails closed without
ADMIN_TOKEN. - CSP with a per-request nonce and no
unsafe-inline. - Secrets never rendered: the console shows fingerprints, not values.