Security

1. Reporting a vulnerability

2. What to include

• What you found, and why it matters — the impact, not only the technique.
• Precise steps to reproduce it, with the URL, the account used and the time.
• A proof of concept limited to what demonstrates the issue.
• How you would like to be credited, if you would.

3. Scope

• Out of scope: third-party services we use but do not operate — report those to their own programmes.
• Out of scope: findings from automated scanners with no demonstrated impact, missing hardening headers alone, or reports that a rate limit exists.
• Out of scope: social engineering of our team or our users, physical attacks, and anything that degrades the service for others.

4. Rules of engagement, and safe harbour

• Use only your own accounts and your own data. Stop at the first sign you can reach someone else's.
• Do not exfiltrate, modify or destroy data — a screenshot proving access is enough.
• No denial of service, no load testing, no spam.
• Give us reasonable time to fix an issue before publishing, and coordinate the timing with us.

5. What we do in return

• We acknowledge a report within 5 business days.
• We tell you our assessment and a fix timeline within 10 business days.
• We keep you informed until it is fixed, and we credit you if you want to be credited.

6. How the service is secured

• HTTPS everywhere, HSTS, and a content security policy that forbids inline event handlers.
• Passwords hashed with bcrypt at 12 rounds; sessions are signed JWTs, pinned to a single algorithm.
• Rate limiting on authentication, on the API, and separately on the unauthenticated endpoints.
• Cross-domain sign-in uses short-lived, single-use authorisation codes rather than tokens in URLs.
• Uploads are validated on their magic bytes, stripped of EXIF, and served from a sandboxed path; SVG is refused wherever a file could become a document.
• Paid asset files are stored outside the public tree, so payment is what unlocks them, not obscurity.

7. Data and privacy incidents