Security

Last reviewed: 2026-07-25

What is actually in place

Only implemented, continuously operating controls are listed here. Cohesive is a one-person product, so this page states what is true rather than what sounds reassuring.

This website and the waitlist

Served over HTTPS only, as static files with no server-side rendering and no database query in the page path.
The signup endpoint accepts a single email address, caps the request body at 2 KB, and is rate-limited per client.
Your IP address is not stored with a signup.
Addresses are held under a uniqueness constraint, and the endpoint returns the same response whether or not an address is already on the list, so it cannot be used to enumerate who has signed up.
The site contains no third-party analytics, advertising, or session-recording script, which removes that entire class of exposure.

The backend

All database access is parameterised through a typed query layer; no query is assembled from string concatenation.
Every API route is declared behind an explicit trust boundary — public, authenticated user, provider webhook, or internal — and a route that reaches production without one is rejected at request time rather than silently defaulting to open.
Rate limits and request-body caps are applied per route, not globally.
Incoming provider webhooks are verified against the raw request body before it is parsed, and replay protection is persisted so a retried delivery cannot be processed twice.
Refresh tokens are rotated on use and tracked by family, so a stolen token that is reused invalidates the family instead of granting quiet long-term access.
Secrets are supplied as runtime configuration from a credential broker and are never committed to the repository. Access tokens, authorisation headers, and raw webhook bodies are excluded from logs.
Database backups are enabled and expire on a schedule.

What is not claimed

No independent penetration test or third-party security audit has been carried out. No certification — SOC 2, ISO 27001, or otherwise — is held or claimed.
There is no paid bug-bounty programme; there is no budget for one.
No system is “unbreachable”, and nothing on this page should be read as a guarantee. If a claim here ever stops being true, it will be removed from this page rather than quietly left standing.

Report a vulnerability

Email [email protected] with “security” in the subject line. Reports are read by a person, acknowledged within 3 working days, and you will be kept informed until the issue is closed. Credit is given if you want it.

Useful in a report: what you found, the steps to reproduce it, the affected URL or endpoint, and what an attacker could achieve. A proof of concept helps.

Please do not run automated scanners or load tests against the production site, attempt denial of service, brute-force the signup form, access or modify data belonging to anyone else, or use social engineering against anyone. If you find data belonging to another person, stop, do not download it, and tell us what you saw.

Do not include secrets, credentials, or unnecessary personal data in your report — not yours and not anyone else’s.

Research conducted in good faith and within those limits is welcome, and no legal action will be pursued over it. If you are unsure whether something is in scope, ask first.

Incidents

There is no public status page yet; if one is added it will be linked here. If a security incident affects your personal data, you will be told directly, along with what happened, what it means for you, and what has been done — within the 72-hour window the GDPR requires for notifying the supervisory authority, and without waiting for a complete post-mortem before telling you something.