Security & vulnerability disclosure

1. How we protect your data

• Encrypted transport: every page and API is served over HTTPS (TLS) only.
• Encryption at rest: access tokens of connected accounts, two-factor secrets and Slack/Teams webhook addresses are stored encrypted with AES-256-GCM; passwords only as scrypt hashes.
• Sign-in: passkeys (Touch ID, Face ID, security keys), a Google or Microsoft account, or a password with TOTP two-factor authentication.
• Isolated workspaces: all data belongs to one workspace and every query is bound to it – one customer cannot see another’s data.
• Backups: the database is operated by Neon in the EU (Frankfurt), with continuous backups and point-in-time restore.
• Logging: the workspace activity log records who approved, connected or deleted what; unexpected errors are logged for 30 days.
• Least privilege: integrations are mostly read-only and we only request the permissions we need; operator functions require re-authentication.
• Secure development: code review, automated tests, regular dependency updates, security HTTP headers.

2. What you can do

• Use a passkey or switch on two-factor authentication.
• Only give workspace access to people who need it, and remove team members who leave.
• Share review links (/r/…) only with the client concerned.

3. Reporting a vulnerability

If you find a security vulnerability in Sayweek, please write to hello@sayweek.com with the subject “Security”. Our contact details are also available in machine-readable form in /.well-known/security.txt.

Please include:

• the affected address, feature or app version;
• a description of the issue and its possible impact;
• steps to reproduce it (request and response, a screenshot or a short video);
• how to reach you, if you would like a reply.

4. Good-faith research – the ground rules

If you follow the rules below, we will treat your good-faith research as authorised, will not take legal action against you and will not ask anyone else to. If a third party takes action against you, we will make it known that your activity complied with this policy.

• Only test with your own accounts created for the purpose; do not access, modify or delete other customers’ data. If you do come across such data, stop and tell us.
• Access only as much data as strictly needed to demonstrate the issue, and do not keep or share it.
• Do not overload the service (DoS), send spam, use social engineering or attempt physical access.
• Do not publish anything on social accounts through Sayweek on anyone else’s behalf.
• Do not disclose the issue publicly until it is fixed, or for at least 90 days; let us agree the timing together.

5. Scope

In scope: sayweek.com, app.sayweek.com, the public Sayweek API and the Sayweek iOS and Android apps.

Out of scope:

• third-party services (e.g. Vercel, Neon, Stripe, PayPal, Postiz, the social platforms) – please report to their own programmes;
• denial-of-service attacks, spam, social engineering;
• findings without an exploitable impact: missing headers, SPF/DMARC settings, version numbers, output of automated scanners;
• self-XSS, clickjacking on pages without sensitive actions, logout CSRF;
• attacks that require a rooted or jailbroken device.

6. What we do with your report

• We acknowledge receipt: [time limit, e.g. within 3 business days].
• We investigate and share our first assessment: [time limit, e.g. within 10 business days].
• We fix the issue according to its severity and tell you when it is done.
• If you wish, we thank you by name after the fix.

We do not currently pay bounties, unless we have agreed to in writing in advance for a specific case.

7. If something goes wrong

We notify the workspace owner of a personal data breach without undue delay, at the latest within 48 hours (see section 10 of the Data Processing Agreement). How we handle data: Privacy Policy.