Security
Last updated September 28, 2026
How Taktoria is built and run, and what to do if you find a hole in it. This describes what the software actually does today, not what we intend to do later.
1. Reporting a vulnerability
Write to security@taktoria.com with enough detail to reproduce the problem. We will acknowledge within 7 days, which is the window ISO/IEC 29147 recommends for a first response, and keep you posted while we fix it.
Please give us a reasonable chance to ship a fix before telling anybody else. We will not pursue anyone who reports a genuine finding in good faith, stays within their own workspace's data, and does not degrade the service for other customers.
2. Where it runs
The application is hosted on Vercel and the database is a managed MySQL database on PlanetScale, both in the United States. Email is sent through Cloudflare, and uploaded pictures are stored in Cloudflare R2. Payments are handled by Stripe, and background jobs are delivered by Inngest. Workspaces' own hostnames are added to the Vercel project through Vercel's API.
The Data Processing Addendum lists every sub-processor and what each one does.
3. Encryption
Traffic is encrypted with TLS. Data at rest is encrypted by the providers above. Certificates for workspace hostnames are issued automatically once DNS resolves.
4. Accounts and sign-in
- Passwords are stored only as hashes, never in a form we could read.
- Two-factor authentication is available on every account, using a time-based code with single-use backup codes. Repeated failures lock the second factor for a period rather than allowing an unlimited guess.
- Single sign-on, through OpenID Connect or SAML, is available once a DNS record proves the workspace controls its email domain, so naming a domain you do not own achieves nothing.
- A workspace can require its members to sign in with Google. A session made any other way is sent to sign in with Google before it can open the workspace, and the API refuses it. An admin who is not signed in with Google cannot turn the requirement on, so nobody locks themselves out.
- Sessions are listed in account settings with the device and address that created them, and any of them can be revoked.
- A password reset link works once and for an hour. The page that asks for one answers the same whether or not the address has an account, and setting the new password signs the account out everywhere else.
- The sign-in, sign-up, single sign-on, two-step and password reset pages, and a Dory event's join box and attendee actions, on our domain and on workspaces' own hostnames, are checked by Google reCAPTCHA Enterprise. A request that scores as a script is refused, on the forms and on the sign-in endpoints behind them alike, and so is a token made on any other site. If the check cannot be made, the request is refused rather than let through.
5. Keeping workspaces apart
Every query in the product is scoped to one workspace. A missing scope is treated as a data leak rather than a display bug, and the rule is enforced in review.
Opening an app needs two things: membership of the workspace and a seat on that app's subscription. Both are checked on the server for every request, including the ones behind a form, and never from a workspace identifier supplied by the browser.
The one deliberate exception is a Go Links hostname a workspace gives itself, such as go.acme.com: anybody who can reach it can follow its links without signing in, which is what it is for, and the settings page warns of it.
6. API keys
An API key is shown once, at creation, and stored as a SHA-256 hash. We keep the first few characters so a key can be recognised in a list, and nothing else. A lost key cannot be recovered, only replaced.
Keys carry scopes, so a key issued for one kind of work cannot be used for another.
7. Incoming webhooks
Requests from Stripe and Slack are verified against their signing secrets before anything is read from them, using the raw request body. An unsigned or missigned request is refused.
8. Uploaded files
Profile pictures, workspace icons and uploaded Memegen templates are served from a public bucket address. The URL contains a random key and changes whenever the picture changes, but anybody holding it can fetch the file. Treat those fields as public.
9. Backups and deletion
Deleting a workspace, which only its owner can do, removes its data from live systems immediately and from backups within 30 days. Export anything you need first.
10. How changes reach production
- Every change is reviewed before it merges.
- Linting, type checking and the full test suite run on every pull request, including tests that exercise workspace scoping against a real database.
- Database migrations are committed alongside the code that needs them and are never edited once applied.
11. What we do not claim
We hold no third-party security certification at this time, and we would rather say so than imply one. Independent penetration testing is carried out annually.
If your procurement process needs something we have not listed here, ask: security@taktoria.com.