Security
How to report a vulnerability, what we do about it, and how this service is built to contain one.
Last updated 19 August 2026 · Kodar Tarkvara OÜ · Tallinn, Estonia
01Reporting a vulnerability
Email privacy@kodar.io with the subject line starting SECURITY. Reports are welcome from anyone — you do not need an account, and you do not need to ask permission first.
Please include, as far as you can:
- what you found, and the affected URL, endpoint or parameter;
- the steps to reproduce it, ideally with the exact request;
- what an attacker could do with it;
- any account or workspace id you used, so we can find it in our logs.
We aim to acknowledge a report within three working days and to tell you what we decided and when a fix shipped. We do not run a paid bug-bounty programme, and we will say so up front rather than leave you waiting on one; we are glad to credit you when a fix goes out, if you want that.
02Safe harbour
If you make a good-faith effort to follow the rules below, we will not pursue legal action against you, and we will not ask your hosting provider to. If a third party brings a claim about research that stayed inside these rules, we will make clear that it was authorised.
- Test only against accounts and data you control. Never access, modify, or retain another customer's data or another recipient's email — if you stumble into it, stop and tell us what you saw.
- No denial of service, no volumetric or load testing, and no automated scanning that sends mail through the platform: that lands in real inboxes and costs our sending reputation.
- No social engineering of our staff, customers or providers, and no physical attempts.
- Give us a reasonable chance to fix it before publishing, and do not exfiltrate more data than is needed to demonstrate the issue.
Our upstream providers have their own rules that we cannot waive for you — testing Amazon SES, Neon, Vercel, Railway or Montonio infrastructure is out of scope here and is governed by their programmes.
03How the service is built to contain a compromise
- Secrets are one-way
- An API key is shown to you once and then stored only as a SHA-256 digest, as are the one-time tokens we issue — a leak of our database yields nothing that can be replayed as a credential. Your account password we never hold at all: the identity service does.
- Signing keys are encrypted
- DKIM private keys and webhook signing secrets are encrypted at rest with a key that lives in the environment, not in the database.
- Tenant isolation
- Every query is scoped by project or tenant at the data layer rather than by a filter in a route, so a missing check fails closed instead of returning a neighbour's rows.
- Transport & browser hardening
- HSTS with preload, a Content-Security-Policy on every route, frame-ancestors none, nosniff, and a strict referrer policy. No third-party scripts, analytics or embeds anywhere, and the webfonts are served from our own origin.
- Rate limiting
- Per-API-key limits on the public API, and per-IP limits on registration, email verification and account deletion. Sign-in and password reset are handled by the identity service, under its own limits.
- Least data
- Message bodies and attachments are erased on a fixed window, and log rows on your plan's window, by an automated pass — see the Privacy Policy. Data we no longer hold cannot leak.
04If personal data is breached
A confirmed breach of personal data starts a documented procedure, not an improvisation. As a processor for the mail our customers send, we notify affected customers without undue delay after becoming aware of it (Art. 33(2) GDPR and our Data Processing Agreement), with what we know at that point: what happened, which data and roughly how many people are affected, the likely consequences, and what we are doing about it. Where we are the controller — account and billing data — we notify the Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon) within 72 hours unless the breach is unlikely to be a risk, and we tell affected people directly when the risk to them is high.
The runbook that drives this — roles, the 72-hour clock, the notification contents, and the post-incident review — is kept in the repository at docs/gdpr/breach-response.md and is available to customers on request as part of a security review.
05Not a vulnerability report?
Spam or abuse sent through the platform: abuse@kodar.io (see our Acceptable Use Policy). Privacy and data-subject requests: privacy@kodar.io. Everything else: support@kodar.io.
This page is also published in machine-readable form at /.well-known/security.txt (RFC 9116).